Demystifying phone unlocking tools: A technical overview - Osservatorio NessunoSkip to main content

Menu<br>Demystifying phone unlocking tools: A technical overview.<br>7 May 2026 -<br>Research<br>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:<br>Cellebrite and the routine use of digital surveillance in Italy<br>A deep dive into Cellebrite: How it came to be<br>A deep dive into Cellebrite: Android support as of February 2025

Introduction<br>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.<br>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&rsquo;s peripheral driver stack. This post mostly details Android internals, however iOS equivalent concepts are technically similar.<br>Much of the background research referenced here comes from Quarkslab, whose extensive publications on TEEs, and Android&rsquo;s data encryption architecture have been invaluable to understand these tools. Their work, alongside reporting from Amnesty International&rsquo;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<br>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<br>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) .<br>SoC diagram showing Normal World and Secure World partitions, with the TEE running Trusted Applications and communicating with an optional Secure Element over SPI<br>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.<br>The Trusted OS hosts critical security services. Two are directly relevant to device unlocking:<br>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.<br>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.<br>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&rsquo;s Kinibi is also often found on MediaTek and Exynos SoCs. The security properties vary between implementations.

The Secure Element<br>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.<br>In the Android ecosystem,...