Missing Debuggable Flag Detection

Missing Debuggable Flag Detection

Risk: hardening

Description

The application continued to run normally after its AndroidManifest.xml was patched to set android:debuggable="true" and the APK was rebuilt and re-signed.

When android:debuggable is enabled, an attacker can attach a debugger (e.g. via adb jdwp) to the running process, inspect memory, set breakpoints, and manipulate execution flow. An app that does not detect this condition cannot prevent such runtime analysis.

Common attack scenarios:

• Runtime analysis: Attach a debugger to inspect sensitive values (keys, tokens, business logic) in memory.
• Logic bypass: Use breakpoints and variable modification to skip license checks or authentication.
• Combined attack: Patch the manifest to enable debugging, then attach Frida or jdwp to hook sensitive methods.

Recommendation

Check the FLAG_DEBUGGABLE flag at runtime and terminate if it is set in a production build.

if ((getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
    throw new SecurityException("Debuggable build detected — terminating.");
}

Additional hardening recommendations:

• Perform the check in a native (JNI) function and in multiple locations to resist patching.
• Combine with an android:debuggable="false" build configuration enforced by CI to prevent accidental release of debuggable builds.
• Terminate or wipe sensitive state immediately — do not degrade gracefully.

Links

• OWASP MASTG - Testing whether the App is Debuggable (MASTG-TEST-0039)
• OWASP MASVS - MASVS-RESILIENCE-2
• Android Developers - android:debuggable security risks

Standards

• OWASP_MASVS_RESILIENCE:
  • MSTG_RESILIENCE_2
• OWASP_MASVS_v2_1:
  • MASVS_RESILIENCE_2
• PCI_STANDARDS:
  • REQ_6_2
  • REQ_6_3
• SOC2_CONTROLS:
  • CC_7_1
  • CC_7_2
• HIPAA_CONTROLS:
  • SECURITY212
  • SECURITY213
• OWASP_MOBILE_TOP_10:
  • M8_2024