How commercial phone unlocking tools turn known mobile vulnerabilities into products

A technical write-up published on osservatorionessuno.org and picked up on Hacker News's front page dissects how commercial phone unlocking tools actually work, and its central finding is deflating: these products rely on the same vulnerability classes that researchers present at conferences and publish in academic papers. According to the author, the real differentiator is commercial — building or acquiring exploits for each hardware and software pairing, stabilizing them, and packaging them into automated workflows that need minimal operator skill.

Where an attacker with physical access can operate

The write-up frames a forensic examiner's options as tightly bounded by four areas: the boot chain, the trusted execution environment (TEE), the secure element where one is present, and the kernel's peripheral driver stack. It concentrates on Android internals, with the author noting that the equivalent iOS concepts are technically similar. Its empirical grounding draws on Quarkslab's research into TEEs and Android's encryption architecture, reporting from Amnesty International's Security Lab, and analysis by the GrapheneOS project.

Two worlds inside one chip

ARM's TrustZone extension splits a mobile processor into a Normal World — Android, its applications and the Linux kernel — and a Secure World running a minimal Trusted OS that hosts Trusted Applications. The worlds share physical cores but are hardware-isolated, so Normal World code cannot read or write Secure World memory; transitions run through a monitor at ARMv8's highest privilege level, EL3, triggered by Secure Monitor Call instructions.

Two Trusted OS services anchor unlocking. Gatekeeper verifies PINs, passwords and patterns, throttles brute-force attempts through rate limiting, and issues a signed authentication token on success; Keymaster manages cryptographic keys, some authentication-bound so they can be used only after Gatekeeper produces a valid token. Implementations vary by vendor — TrustyOS for Google and AOSP, QSEE for Qualcomm, TEEGRIS for Samsung devices across Exynos and MediaTek SoCs, TrustedCore for Huawei, and Trustonic's Kinibi often found on MediaTek and Exynos — with differing security properties, the author notes.

The Secure Element divide

A Secure Element is a physically separate, tamper-resistant chip with its own boot chain, firmware and key storage, exposed through Android's StrongBox API since Android 9. Pixels from the Pixel 3 onward carry Google's Titan M, upgraded to the Titan M2 starting with the Pixel 6; Apple's counterpart is the Secure Enclave Processor. The chip holds key-encryption keys and enforces credential rate limiting in hardware the main SoC cannot tamper with even when fully compromised. Without a Secure Element, compromising the TEE is enough to reach credential-derived keys; with one, an attacker must also defeat a second, hardened chip. Because Secure Elements appear mainly in flagships, most mid-range and budget devices rely on the TEE alone — a gap the author identifies as the biggest factor in whether a device resists forensic unlocking while powered off.

Why boot ROM flaws outlive the hardware

The chain of trust starts in the Boot ROM, fixed in silicon at manufacture and in principle immutable, though the author acknowledges a few modern exceptions for deploying fixes. It verifies and loads the next stage — the preloader, as MediaTek calls it — which initializes hardware and loads the Trusted OS into the Secure World and the main bootloader into the Normal World. That stage, Little Kernel on MediaTek or ABL on Qualcomm, enforces Android Verified Boot, anti-rollback protections and device-state checks before the kernel starts, with dm-verity then guarding system partition integrity at runtime. Because each stage vouches for the next, one compromised link makes everything downstream untrustworthy. Boot ROM vulnerabilities are the worst case: often unpatchable, and effective against every device built on the affected silicon for its entire hardware lifetime. A Secure Element, meanwhile, boots through its own independent sequence of Boot ROM, Bootrom EXT, Bootloader and OS — the most isolated arrangement in the system.

What the attacker is after

Everything converges on decryption keys for user data. Android began with Full Disk Encryption: one credential-derived key for the whole data partition, required before the OS could boot, the default until Android 6 and deprecated since Android 13. File-Based Encryption replaced it, becoming the default in Android 7 and mandatory in Android 10, encrypting files individually with distinct keys and dividing storage into classes that include Device Encrypted storage.

Why it matters

The overview reframes forensic unlocking as an engineering and procurement exercise rather than an arcane art. For defenders, the mitigations that count are concrete: whether a device includes a Secure Element, how hardened its particular TrustZone implementation is, and whether the boot chain holds — with the flagship-versus-budget hardware divide shaping a device's resistance as much as patch levels do. For the wider industry, it is a reminder that publicly documented vulnerability classes become durably monetizable once someone invests in stability and packaging, and that silicon-level defects such as Boot ROM bugs shadow every affected device for its entire service life.