Semgrep rule mastg-android-sensitive-data-in-screenshot does not detect FLAG_SECURE in many APKs due to decompiler constant substitution

[cann3v]

Type: Bug / Rule Improvement
Area: Semgrep rules (Android)
Rule: mastg-android-sensitive-data-in-screenshot

---

Problem Description

The current Semgrep rule intended to detect the usage of WindowManager.LayoutParams.FLAG_SECURE relies on matching:

• addFlags(0x2000)
• addFlags(WindowManager.LayoutParams.FLAG_SECURE)
• addFlags(8192)

However, this approach is unreliable for APK analysis because detection depends entirely on how the Java code is reconstructed by a decompiler.
Different decompilers frequently substitute the original constant with any other public static final int that shares the same numeric value (0x2000).

Example:
Instead of:

window.addFlags(WindowManager.LayoutParams.FLAG_SECURE);

a decompiler may output:

window.addFlags(PKIFailureInfo.certRevoked);

Both refer to the same integer value (0x2000), but the current Semgrep rule fails to detect such cases.
This results in false negatives, causing incorrect evaluations.

Example

Original code:

After decompiling via JADX:

Proposed Fix

There are two potential solutions.

Option A – Add a Smali-based Semgrep rule (recommended)

This is the most reliable and decompiler-agnostic approach. Smali represents bytecode directly, so the constant 0x2000 is preserved exactly.
For example:

rules:
  - id: mastg-android-sensitive-data-in-screenshot-smali
    languages: [generic]
    message: FLAG_SECURE (0x2000) detected in smali
    severity: INFO
    patterns:
      - pattern: |
          const $REG, 0x2000
      - pattern-inside: |
          invoke-virtual { ..., $REG, ... }, Landroid/view/Window;->addFlags(I)V

This guarantees detection across all APKs, regardless of decompiler behavior.

Option B – Extend the existing Java rule

Add all known alternative constant names that may appear due to decompiler substitution, e.g.:

PKIFailureInfo.certRevoked

Updated section of the rule:

pattern-either:
  - pattern: addFlags(0x2000)
  - pattern: addFlags(WindowManager.LayoutParams.FLAG_SECURE)
  - pattern: addFlags(PKIFailureInfo.certRevoked)

This reduces false negatives but still depends on the decompiler and may require maintenance as new aliases appear.

Additional Notes

• The rule in question comes from MASTG-TEST-0291: References to Screen Capturing Prevention APIs.
• Reproducible with APKs decompiled via JADX.

[ZX41R]

The smali direction is the right one. Extending the Java rule with aliases like PKIFailureInfo.certRevoked will always be incomplete because the alias set is whatever the decompiler happened to choose for the integer 0x2000.

I would make the bytecode rule slightly broader than the sketch above:

• cover const, const/16, and possibly const vX, 0x00002000
• cover both Window->addFlags(I)V and Window->setFlags(II)V
• for setFlags, require that the mask argument can also carry 0x2000, otherwise the rule may report calls where the value is present but not applied as the mask

The hard part is register tracking. A Semgrep generic rule is fine for the simple case where the constant load is close to the invoke, but it will miss cases where the register is copied or loaded earlier in the method. If this rule needs to be high-confidence across real APKs, a tiny smali/DEX pass that does local constant propagation into addFlags / setFlags would be more robust than trying to model this through decompiled Java.

So I would avoid Option B entirely, add a smali rule for low-noise wins, and treat a DEX-level constant-propagation scanner as the long-term fix.