android-physical-attacks.md (10716B)
1 --- 2 title: "Android Physical Attacks" 3 section: "Mobile" 4 sectionSlug: "mobile-pentesting" 5 sourcePath: "src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Android Physical Attacks 14 15 ## BFU / AFU, FBE, and physical extraction attacks 16 17 For **mobile app pentests** and **seizure/forensics threat modeling**, it is useful to separate the device into 2 states:<sup>[[1]](#references)</sup> 18 19 - **BFU (Before First Unlock)**: after boot and before the user unlocks once. **Credential Encrypted (CE)** data is still cryptographically protected. 20 - **AFU (After First Unlock)**: the user already unlocked the device after boot. **CE keys are already resident in memory**, so the lockscreen becomes mostly a **UI barrier** unless the device reboots. 21 22 ### Android credential path that matters during physical attacks 23 24 Modern Android credential protection is not just the lockscreen UI:<sup>[[2]](#references)</sup> 25 26 - **Gatekeeper** verifies PIN/password/pattern and rate-limits guesses.<sup>[[3]](#references)</sup> 27 - **Keymaster / KeyMint** releases **authentication-bound keys** only after a valid Gatekeeper token.<sup>[[5]](#references)</sup> 28 - **Synthetic Password** protects the CE keys used by `fscrypt`.<sup>[[1]](#references)</sup> 29 - **StrongBox / Weaver** (when present) moves part of the secret material and throttling into a separate hardened chip.<sup>[[4]](#references)</sup> 30 31 The important implication is that **TEE compromise and lockscreen bypass are not always the same thing**. On FBE devices, attackers often still need the credential-derived material used to decrypt the **Synthetic Password**.<sup>[[1]](#references)</sup> 32 33 Useful artifact locations during rooted/physical analysis:<sup>[[1]](#references)</sup> 34 35 - scrypt parameters + salt used by Synthetic Password live under **`/data/system_de/<user_id>/spblob`** 36 - background task snapshots often live under **`/data/system_ce/0/snapshots`** 37 38 ### BFU attack pattern on devices without a Secure Element 39 40 On devices **without** a real Secure Element / StrongBox-backed Weaver path, the reusable pattern is:<sup>[[1]](#references)</sup> 41 42 1. Gain **pre-OS code execution** via **Boot ROM** bug or vendor mode such as **MediaTek Download Mode** / **Qualcomm EDL**. 43 2. Patch the early boot chain so later stages no longer verify signatures. 44 3. Load a modified **Trusted OS / TEE** and patch **Gatekeeper** to accept arbitrary credentials. 45 4. Abuse **Keymaster** to recover intermediate key material. 46 5. Extract the encrypted **Synthetic Password** and brute-force the credential **offline**. 47 48 That offline step converts the problem from device-side rate limiting into attacker-side compute:<sup>[[1]](#references)</sup> 49 50 ```python 51 for candidate in candidates: 52 stretched = scrypt(candidate, salt, params_from_spblob) 53 applicationId = derive_application_id(stretched, other_material) 54 plaintext = aes_gcm_decrypt(encrypted_synthetic_password, applicationId) 55 if gcm_tag_valid(plaintext): 56 return candidate 57 ``` 58 59 If you need the early-boot details for MediaTek devices, review: 60 61 [Android Mediatek Secure Boot Bl2 Ext Bypass El3](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/hardware-physical-access/firmware-analysis/android-mediatek-secure-boot-bl2_ext-bypass-el3.md) 62 63 Also note that **public tooling such as [MTKClient](https://github.com/bkerler/mtkclient)** makes several MediaTek Boot ROM / download-mode workflows practical on affected chipsets.<sup>[[6]](#references)</sup> 64 65 ### Biometric TA AuthToken forgery: root-to-CE bypass without patching Gatekeeper 66 67 A second reusable pattern is to **abuse biometric Trusted Applications (fingerprint / face TAs) that share the same AuthToken HMAC trust domain as Gatekeeper and Keymaster / KeyMint**. On Android, a successful authenticator returns a signed **`hw_auth_token_t`** proving who authenticated, by which method, and when. If a biometric TA can be tricked into **signing attacker-controlled data** or **leaking the shared per-boot HMAC key**, Android root can be upgraded into **PIN recovery** and sometimes **BFU CE decryption**.<sup>[[7]](#references)</sup> 68 69 Relevant AuthToken properties:<sup>[[7]](#references)</sup> 70 71 - `hw_auth_token_t` is a fixed **69-byte** structure with fields such as `challenge`, `user_sid`, `authenticator_id`, `authenticator_type`, `timestamp`, and a trailing **32-byte HMAC-SHA256** computed with a **per-boot shared secret**. 72 - `authenticator_type = 1` is the important value for **Gatekeeper / PIN** tokens. 73 - Keymaster / KeyMint validates the HMAC, freshness, SID binding, and expected authenticator type before releasing authentication-bound key operations. 74 75 Common exploitation patterns seen in vendor biometric TAs:<sup>[[7]](#references)</sup> 76 77 1. **Signing oracle (`GET_AUTH_OBJ`-style bugs)**: a TA command accepts an arbitrary 69-byte buffer and simply HMAC-signs it, without checking that a fingerprint/face match actually happened. 78 2. **Biometric result oracle + verifier confusion**: a TA emits a valid **type-2** biometric token without a real match, and Keymaster incorrectly accepts it for operations that should require **type-1** Gatekeeper authentication. 79 3. **Error-path secret leakage**: HMAC verification failures print or return the shared **32-byte per-boot AuthToken HMAC key** via TrustZone logs, shared memory, or even `dmesg`-reachable secure logs. 80 4. **TA memory disclosure / corruption**: out-of-bounds reads or arbitrary-read primitives leak plaintext per-boot HMAC keys from heap / stack / BSS after defeating weak TA ASLR. 81 82 Once the attacker can mint a valid **type-1** token (or a verifier incorrectly accepts **type-2**), the remaining CE attack looks very similar to the early-boot TEE-patching chain, but **without** modifying Gatekeeper itself:<sup>[[7]](#references)</sup> 83 84 1. Obtain **Android root / kernel EL1 R/W**. 85 2. Invoke the biometric TA directly with **`libTEEC`** or an equivalent TEE client. 86 3. Forge or request a signed **Gatekeeper-typed AuthToken**. 87 4. Pass that token to **Keymaster / KeyMint** to decrypt the first-stage **Synthetic Password** blob. 88 5. Brute-force the real PIN **offline** using the AES-GCM tag as a correctness oracle. 89 90 Minimal attacker view:<sup>[[7]](#references)</sup> 91 92 ```python 93 at = forge_gatekeeper_authtoken() # type = 1, HMAC valid 94 spblob = read('/data/system_de/<uid>/spblob/...') 95 intermediate = keymaster_decrypt(at, spblob) 96 97 for pin in range(1_000_000): 98 key = derive_synthetic_pw(intermediate, pin) 99 if aes_gcm_decrypt(intermediate, key): 100 return pin 101 ``` 102 103 Operational notes:<sup>[[7]](#references)</sup> 104 105 - **BFU impact** usually requires a forged **type-1 / Gatekeeper** token that Keymaster accepts before first unlock. 106 - **AFU-only** cases can still exist if the device incorrectly accepts biometric **type-2** tokens after first unlock. 107 - Multiple dormant fingerprint TAs in one firmware image increase attack surface because **each TA may hold the same per-boot AuthToken HMAC material**. 108 - **StrongBox / Weaver-backed** designs reduce the usefulness of this chain because recovering the Keymaster-gated intermediate is not always enough to obtain an offline brute-force oracle. 109 110 ### StrongBox / Weaver changes the brute-force model 111 112 If the device uses **Weaver** backed by a separate Secure Element / StrongBox, compromising Android or even the TEE is usually **not enough** to obtain an offline brute-force primitive:<sup>[[1]](#references)</sup> 113 114 - the Weaver secret should remain inside the separate chip 115 - throttling is enforced by hardware outside the main SoC 116 - guesses often remain **online only**, sometimes with exponential backoff 117 118 This is why **short PINs** are still weak, but a **long alphanumeric password** becomes much more resistant on properly implemented StrongBox devices.<sup>[[1]](#references)</sup> 119 120 ### AFU USB exploitation: lockscreen is not the boundary anymore 121 122 In **AFU** state, many forensic chains no longer attack the password. They attack the **USB-reachable kernel attack surface** exposed while the device is locked:<sup>[[1]](#references)</sup> 123 124 - **HID** 125 - **USB Audio / ALSA** 126 - **UVC** 127 - **MTP / MSC** 128 129 A malicious peripheral emulator can present crafted descriptors/reports to reachable drivers, trigger memory corruption or information leaks, gain kernel code execution, and then read **already-decrypted CE storage**. At that point, the lockscreen is just UI and the attacker can pivot to **full filesystem extraction**, app databases, cached tokens, previews, and any application secrets that remain in memory.<sup>[[1]](#references)</sup> 130 131 ### iOS parallel: USB policy bugs reopen AFU attack surface 132 133 The same idea appears on iOS: 134 135 - **checkm8** is the classic **Boot ROM** example for older A5-A11 devices.<sup>[[1]](#references)</sup> 136 - Newer iPhone physical attacks tend to focus on **AFU USB access** and **USB Restricted Mode** bypasses.<sup>[[1]](#references)</sup> 137 - **CVE-2025-24200** is a good example of a **policy-enforcement bug** where a privileged path could re-enable USB data on a locked device.<sup>[[8]](#references)</sup> 138 139 For defenders and app testers, the important lesson is simple: **if the target device is AFU, assume filesystem-level compromise can expose app data unless the app adds its own cryptographic boundary**. 140 141 ## References 142 143 - [1] [Demystifying phone unlocking tools: A technical overview](https://osservatorionessuno.org/blog/2026/05/demystifying-phone-unlocking-tools-a-technical-overview/) 144 - [2] [Android Open Source Project - Authentication](https://source.android.com/docs/security/features/authentication) 145 - [3] [Android Open Source Project - Gatekeeper](https://source.android.com/docs/security/features/authentication/gatekeeper) 146 - [4] [Android Open Source Project - Weaver](https://source.android.com/docs/security/features/authentication/weaver) 147 - [5] [Android Open Source Project - KeyMint implementer reference](https://source.android.com/docs/security/features/keystore/implementer-ref) 148 - [6] [MTKClient](https://github.com/bkerler/mtkclient) 149 - [7] [The Biometric AuthToken Heist: Forging Android AuthTokens from Biometric Trusted Applications](https://darknavy.org/blog/the_biometric_authtoken_heist) 150 - [8] [First analysis of Apple's USB Restricted Mode bypass (CVE-2025-24200)](https://blog.quarkslab.com/first-analysis-of-apples-usb-restricted-mode-bypass-cve-2025-24200.html)