Demystifying Phone Unlocking Tools A Technical Overview

src/mobile-pentesting/android-app-pentesting/README.md

@@ -789,6 +789,88 @@ To access the data inside the keystore you could use this Frida script: [https:/
 frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
 ```
 
+## BFU / AFU, FBE, and physical extraction attacks
+
+For **mobile app pentests** and **seizure/forensics threat modeling**, it is useful to separate the device into 2 states:
+
+- **BFU (Before First Unlock)**: after boot and before the user unlocks once. **Credential Encrypted (CE)** data is still cryptographically protected.
+- **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.
+
+### Android credential path that matters during physical attacks
+
+Modern Android credential protection is not just the lockscreen UI:
+
+- **Gatekeeper** verifies PIN/password/pattern and rate-limits guesses.
+- **Keymaster / KeyMint** releases **authentication-bound keys** only after a valid Gatekeeper token.
+- **Synthetic Password** protects the CE keys used by `fscrypt`.
+- **StrongBox / Weaver** (when present) moves part of the secret material and throttling into a separate hardened chip.
+
+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**.
+
+Useful artifact locations during rooted/physical analysis:
+- scrypt parameters + salt used by Synthetic Password live under **`/data/system_de/<user_id>/spblob`**
+- background task snapshots often live under **`/data/system_ce/0/snapshots`**
+
+### BFU attack pattern on devices without a Secure Element
+
+On devices **without** a real Secure Element / StrongBox-backed Weaver path, the reusable pattern is:
+
+1. Gain **pre-OS code execution** via **Boot ROM** bug or vendor mode such as **MediaTek Download Mode** / **Qualcomm EDL**.
+2. Patch the early boot chain so later stages no longer verify signatures.
+3. Load a modified **Trusted OS / TEE** and patch **Gatekeeper** to accept arbitrary credentials.
+4. Abuse **Keymaster** to recover intermediate key material.
+5. Extract the encrypted **Synthetic Password** and brute-force the credential **offline**.
+
+That offline step converts the problem from device-side rate limiting into attacker-side compute:
+
+```python
+for candidate in candidates:
+    stretched = scrypt(candidate, salt, params_from_spblob)
+    applicationId = derive_application_id(stretched, other_material)
+    plaintext = aes_gcm_decrypt(encrypted_synthetic_password, applicationId)
+    if gcm_tag_valid(plaintext):
+        return candidate
+```
+
+If you need the early-boot details for MediaTek devices, review:
+
+{{#ref}}
+../../hardware-physical-access/firmware-analysis/android-mediatek-secure-boot-bl2_ext-bypass-el3.md
+{{#endref}}
+
+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.
+
+### StrongBox / Weaver changes the brute-force model
+
+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:
+
+- the Weaver secret should remain inside the separate chip
+- throttling is enforced by hardware outside the main SoC
+- guesses often remain **online only**, sometimes with exponential backoff
+
+This is why **short PINs** are still weak, but a **long alphanumeric password** becomes much more resistant on properly implemented StrongBox devices.
+
+### AFU USB exploitation: lockscreen is not the boundary anymore
+
+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:
+
+- **HID**
+- **USB Audio / ALSA**
+- **UVC**
+- **MTP / MSC**
+
+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.
+
+### iOS parallel: USB policy bugs reopen AFU attack surface
+
+The same idea appears on iOS:
+
+- **checkm8** is the classic **Boot ROM** example for older A5-A11 devices.
+- Newer iPhone physical attacks tend to focus on **AFU USB access** and **USB Restricted Mode** bypasses.
+- **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.
+
+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**.
+
 ### **Fingerprint/Biometrics Bypass**
 
 Using the following Frida script it could be possible to **bypass fingerprint authentication** Android applications might be performing in order to **protect certain sensitive areas:**
@@ -1091,5 +1173,9 @@ AndroL4b is an Android security virtual machine based on ubuntu-mate includes th
 - [BeatBanker: A dual‑mode Android Trojan](https://securelist.com/beatbanker-miner-and-banker/119121/)
 - [Pre-installed C2 Infrastructure and RAT Payload on Android Projectors](https://github.com/Kavan00/Android-Projector-C2-Malware)
 - [Reverse-engineering pre-installed Android malware with Claude Code](https://zanestjohn.com/blog/reing-with-claude-code)
+- [Demystifying phone unlocking tools: A technical overview](https://osservatorionessuno.org/blog/2026/05/demystifying-phone-unlocking-tools-a-technical-overview/)
+- [Android Open Source Project - Weaver](https://source.android.com/docs/security/features/authentication/weaver)
+- [MTKClient](https://github.com/bkerler/mtkclient)
+- [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)
 
 {{#include ../../banners/hacktricks-training.md}}