Demystifying phone unlocking tools: A technical overview

Comments

This post is a written description of a presentation titled Phone unlocking tools and where to find them that we have delivered privately to different events and organizations, including Primavera Hacker 25, the Freedom of the Press Foundation, and the Public Interest Technology Group.

It provides a technical overview of how commercial forensic tools compromise mobile devices, focusing on the specific attack surfaces exploited at each stage of the device lifecycle. Further posts will focus on sample analysis, and defenses.

See also the previous posts of this serie: Introduction

Commercial phone unlocking tools are not magic

They exploit the same classes of vulnerabilities that security researchers publish about at conferences and in academic papers. What makes them distinctive is not the novelty of the techniques, but the systematic commercialization of exploitation: acquiring or developing exploits for each hardware and software combination, and reaching a certain degree of stability, packaging them into automated workflows that require minimal operator expertise.

This post aims to demystify the technical foundations of these tools. The attack vectors available to a forensic examiner with physical access to a device are constrained by well-understood boundaries: the boot chain, the trusted execution environment, the secure element (when present), and the kernel's peripheral driver stack.

This post mostly details Android internals, however iOS equivalent concepts are technically similar. Much of the background research referenced here comes from Quarkslab, whose extensive publications on TEEs, and Android's data encryption architecture have been invaluable to understand these tools. Their work, alongside reporting from Amnesty International's Security Lab and other NGOs, and analysis by the GrapheneOS project, provides the empirical basis for the claims made in this post.

Hardware security architecture

Before examining attack vectors, it is necessary to understand the hardware security architecture of modern Android devices. The following sections describe the components that forensic tools must eventually hack or bypass.

The System-on-Chip: Normal World and Secure World

Modern ARM-based mobile processors implement TrustZone, a hardware security extension that partitions the processor into two execution environments: the Normal World and the Secure World.

The Normal World runs the Android operating system, user applications, and the Linux kernel. The Secure World runs a separate, minimal operating system, the Trusted OS, along with small, specialized applications known as Trusted Applications (TAs).

The two worlds share the same physical processor cores but are hardware-isolated: the Normal World cannot directly read or write Secure World memory. Communication between the two happens through a monitor, a piece of code running at the highest privilege level (EL3 on ARMv8), which handles context switches triggered by Secure Monitor Call (SMC) instructions. Each physical processor core effectively provides two virtual cores, with the Non-Secure bit in the Secure Configuration Register determining which world is active at any given time.

The Trusted OS hosts critical security services. Two are directly relevant to device unlocking:

• Gatekeeper: responsible for verifying user credentials (PIN, password, pattern). It implements rate-limiting to throttle brute-force attempts and, upon successful authentication, issues a signed authentication token.
• Keymaster: the key management service that stores and operates on cryptographic keys. Some keys are authentication-bound, meaning they can only be used after Gatekeeper has issued a valid token.

Different SoC vendors ship different TrustZone implementations. Google (and AOSP in general) uses TrustyOS; Qualcomm uses QSEE; Samsung uses TEEGRIS (on both Exynos and MediaTek SoCs in Samsung devices); Huawei uses TrustedCore; Trustonic's Kinibi is also often found on MediaTek and Exynos SoCs.

The security properties vary between implementations.

The Secure Element

A Secure Element (SE) is a physically separate, tamper-resistant hardware chip that provides an additional layer of security beyond the TEE. Unlike the Secure World, which runs on the same SoC as the Normal World, a Secure Element is an independent processor with its own boot chain, its own firmware, and its own cryptographic key storage.

In the Android ecosystem, the Secure Element is exposed through the StrongBox API (introduced in Android 9). Google's Pixel phones, starting with the Pixel 3, include the Titan M chip as their Secure Element, that was later upgraded with the Titan M2 from Pixel 6 onward. On Apple devices, the equivalent is the Secure Enclave Processor (SEP).

The Secure Element's role in device encryption is to hold key-encryption keys and enforce rate-limiting for credential verification in hardware that the main SoC cannot tamper with, even if fully compromised. This is an important distinction: on a device without a Secure Element, compromising the TEE is sufficient to extract or bypass credential-derived keys. On a device with a Secure Element, the attacker must additionally compromise a separate, hardened chip.

Unfortunately, only flagship devices typically include a Secure Element. Most mid-range and budget devices rely solely on the TEE for credential protection. This architectural gap is the single most important factor determining the chances that a device has to resist forensic unlocking when powered off.

The boot chain

The boot chain establishes a chain of trust from immutable hardware to the running operating system. Each stage verifies the integrity of the next before executing it. The chain proceeds as follows:

• Boot ROM: the first code executed at power-on. It is burned into silicon at manufacture and is, in principle, immutable and unpatchable (with a few modern exceptions to deploy patches for vulnerabilities). The Boot ROM verifies and loads the next stage (the preloader or secondary bootloader). It forms the hardware root of trust.
• Preloader/Secondary Bootloader (BL2): loaded and verified by the Boot ROM. On MediaTek SoCs, this is often called the preloader. It initializes hardware, loads the Trusted OS into the Secure World, and loads the main bootloader into the Normal World.
• Trusted OS: loaded into the Secure World by the preloader. It hosts Gatekeeper, Keymaster, and other Trusted Applications. Its integrity is verified by the preloader as part of the secure boot chain.
• Bootloader (BL3): the Normal World bootloader (e.g., Little Kernel on MediaTek, ABL on Qualcomm). It enforces Android Verified Boot (AVB), anti-rollback protections, and device-state checks before loading the Android kernel.
• Android OS: the Linux kernel and userspace. Verified Boot (dm-verity) ensures the integrity of system partitions at runtime.

When a Secure Element is present, it runs its own independent boot chain in parallel: Boot ROM → Bootrom EXT → Bootloader → OS. The Secure Element's boot chain is entirely separate from the SoC's, providing the most isolation.

If any stage in the boot chain is compromised, all subsequent stages are untrustworthy. This is why Boot ROM vulnerabilities are so devastating: they are often unpatchable, they undermine everything built on top, and they affect every device using the vulnerable silicon for its entire hardware lifetime.

Android data encryption

Understanding the attack vectors requires understanding what the attacker is ultimately trying to obtain: the decryption keys for the user's data.

Full Disk Encryption vs. File-Based Encryption

Android has used two encryption schemes over its history:

• Full Disk Encryption (FDE) encrypts the entire data partition with a single key, derived from the user's credentials. The key must be available before the OS can boot, so the user is prompted for their PIN or password at boot time. FDE was the default until Android 6 and has been deprecated since Android 13.
• File-Based Encryption (FBE) encrypts individual files with different keys, allowing more granular access control. FBE has been the default since Android 7 and is required since Android 10.

It divides storage into two classes:

• Device Encrypted (DE) storage: available immediately after boot, before the user authenticates. Used for system-critical functionality (alarms, phone dialer, Direct Boot). The DE key is derived without user credentials.
• Credential Encrypted (CE) storage: available only after the user authenticates for the first time after boot. This is where all user data resides - messages, photos, application data. The CE key is derived from the user's credentials, stretched through scrypt, and protected by keys held in the TEE (and, when present, the Secure Element).

CE key derivation: The role of credentials

Quarkslab's Android Data Encryption in depth provides the most detailed public analysis of how the CE key is derived. The process, in simplified form, proceeds as follows:

The user's credentials (PIN, password, or pattern) are stretched using scrypt, a memory-hard key derivation function, with parameters and salt stored in DE-protected files under /data/system_de/ /spblob. The scrypt step is intentionally slow: it introduces a negligible delay for a single authentication attempt but makes brute-forcing computationally expensive.

The stretched credentials are combined with other material to form a password blob, which is sent to the Gatekeeper Trusted Application in the TEE. Gatekeeper verifies the blob against a stored password handle using an HMAC with an internal key. If verification succeeds, Gatekeeper issues a signed authentication token.

The authentication token is presented to Keymaster, which uses it to unlock an authentication-bound key. This key is used to perform the first decryption of the Synthetic Password, an intermediate secret stored in encrypted form on the filesystem.

The Synthetic Password is decrypted a second time using a key derived from the user's credentials (the applicationId). This second decryption uses AES-GCM, which provides authenticated encryption: if the wrong credentials are supplied, the GCM tag will not match and decryption will fail. This is the cryptographic check that ultimately binds the CE key to the correct credentials.

From the Synthetic Password, the system derives the CE file encryption keys used by the Linux kernel's fscrypt subsystem to decrypt individual files.

The critical observation is that user credentials are cryptographically embedded in the key derivation chain. There is no way to bypass them purely through software attacks: an attacker who compromises the TEE can bypass the authentication token check, but they still need to brute-force the credentials through scrypt to derive the correct key material.

Key derivation with a Secure Element (Weaver)

On devices with a Secure Element, the key derivation process includes an additional step. Instead of relying solely on Gatekeeper in the TEE, the system uses Weaver, a service running on the Secure Element. Weaver stores a secret value that is released only upon correct credential verification and enforces its own independent rate-limiting.

This means that even if an attacker fully compromises the TEE, or other Trusted Applications as shown by Synacktiv's Kinibi TEE blogpost, they cannot extract the Weaver secret or bypass its throttling, if implemented properly. Brute-forcing must proceed online, at the rate the Secure Element permits, which, for a device like the Pixel with Titan M, means exponential backoff.

Attack vectors

With the architecture established, we can now map the specific attack surfaces that forensic tools exploit. These fall into two main categories, corresponding to teo device states: powered off or powered on but never unlocked (BFU), and powered on and previously unlocked (AFU).

BFU attacks on devices without a Secure Element

The most complete form of BFU attack targets the boot chain itself. If an attacker can compromise the Boot ROM or the preloader, they can break the entire chain of trust, including the TEE. The attack proceeds as follows:

Boot ROM exploitation: the attacker connects to the device via USB and exploits a vulnerability in the Boot ROM (or uses a vendor-specific download/recovery mode, such as MediaTek's Download Mode or Qualcomm's EDL mode) to gain code execution before the bootloader runs.

Boot chain patching: with Boot ROM-level access, the attacker patches or replaces the preloader to disable secure boot verification of subsequent stages. This allows loading a modified Trusted OS and modified Trusted Applications.

TEE patching: the attacker replaces or patches Gatekeeper to accept any credentials and issue valid authentication tokens regardless of input. They also patch or extract keys from Keymaster. As Quarkslab demonstrated in their proof-of-concept on Samsung A22 devices (MT6769V and MT6833V SoCs), this involved patching Samsung's TEEGRIS operating system: first disabling verification of the root filesystem, then disabling TA signature verification, and finally patching Gatekeeper's credential comparison to always succeed.

Key material extraction: with a rooted Android system and a compromised TEE, the attacker extracts the encrypted Synthetic Password and the intermediate decryption result from Keymaster.

Offline brute force: the attacker now has all the material needed for offline brute-forcing. The brute-force loop is:

• Generate a candidate password
• Stretch it through scrypt with the stored parameters
• Derive the applicationId
• Attempt AES-GCM decryption of the Synthetic Password
• If the GCM tag matches, the correct credentials have been found

Because this brute-force runs entirely offline, on the attacker's hardware, it is bounded only by computational resources and password complexity. A numeric PIN of six digits or fewer is trivially recoverable. Even longer numeric PINs fall quickly on dedi