Christopher Wade spent a research project moving down through the Android boot stack, layer by layer, testing how each layer handles malformed USB traffic. He started at the ordinary Android OS level, moved down through bootloader modes, and eventually reached the Boot ROM: the very first, immutable code that runs when a phone powers on, and the root of the entire secure-boot chain. Along the way he found bugs at nearly every layer on both Google Tensor (Pixel) and Samsung Exynos devices, several assigned CVEs, one of which let an unmodified secure-boot chain be bypassed. This is vendor-acknowledged hardware research with a long, deliberate disclosure timeline; I describe the research approach and its significance, not a working exploit.
Post 27 of my Black Hat Asia 2026 series. Boot ROM research is about as sensitive as this series gets: the deck includes exact memory offsets, patch locations and working bypass sequences. I'm deliberately not reproducing those; I focus on the research methodology, what a Boot ROM compromise means, and how the disclosure was handled.
1. Why USB is the thread that connects every layer
USB is not just a cable protocol for charging and file transfer. On Android devices, USB, specifically the low-level Control Transfer mechanism used for device configuration, is present as a communication path at nearly every stage of the boot process: the running OS, bootloader modes used by technicians and manufacturers, and even the very earliest recovery modes some chips expose. That makes it an unusually good thread to pull on if you want to compare how consistently different layers of a system defend themselves against malformed input.
Control Transfers carry a handful of structured parameters and a data buffer. Because the format is standardised across the entire USB ecosystem, it's easy to assume every implementation parses it correctly and consistently. Wade's research method was simply to test that assumption directly, and to remove artificial safety limits that normally prevent a fuzzer from sending transfers outside the values a spec-compliant host would ever produce, both in the userspace library used to talk to USB devices and in the operating system kernel's own filtering.
2. Working down the stack
The research moved through progressively lower, progressively more privileged, and progressively less publicly documented layers:
| Layer | What it is | Outcome |
|---|---|---|
| Android OS (HLOS) | The normal, running operating system | Manufacturer-specific kernel driver bugs found; one led to a CVE on a specific vendor's devices, after an earlier researcher had already found a related issue affecting all Android devices |
| ABL (Android Bootloader) | A pre-boot mode used for flashing and diagnostics | A buffer-handling bug in a specific USB request type exposed adjacent memory, including internal pointers used by the USB stack itself |
| Exynos "Download Mode" | A manufacturer secondary-bootloader recovery mode | New buffer-handling bugs led to code execution, and could bypass bootloader-locking restrictions on newer devices |
| Boot ROM | Immutable first-stage code baked into the chip itself | Full extraction and analysis of the ROM, and a way to bypass secure-boot signature verification |
Two things are worth noticing about this progression. First, each layer's bugs were of the same general kind, buffer over-reads and over-writes triggered by malformed Control Transfer parameters, discovered using the same technique each time. Second, the deeper the layer, the more consequential the outcome: a bug in the running OS might crash an app or leak some memory; a bug in the immutable Boot ROM undermines the security guarantee that everything built on top of it depends on.
3. Why the Boot ROM is special
The Boot ROM is the first code the chip executes, and it cannot be patched: it's physically fixed at manufacturing time. Its job is to start the secure boot chain, verifying the cryptographic signature of the next boot stage before running it, which in turn verifies the next, and so on. If the Boot ROM's own logic can be subverted, every guarantee built on top of it, including protections most people rely on without ever thinking about them, is only as strong as whatever the attacker chooses to leave standing.
Public security research into smartphone Boot ROMs is comparatively rare, partly because reaching this code at all is difficult (on the chip family studied here, dedicated recovery interfaces typically require either physical disassembly of the device or an undocumented trigger sequence) and partly because, even once reached, the code itself is completely undocumented and has to be recovered and understood from scratch with no source, symbols or public reference.
4. The general research approach, without the specifics
Having found a way to reach an early, minimally documented recovery interface, Wade's team faced a familiar constraint in this kind of work: the target code cannot be read in advance, so any attempt to influence it has to be tested experimentally and its effect inferred from observed behaviour, rather than reasoned about from source. Several categories of technique were used to make that practical:
- Systematic Control Transfer fuzzing to find any buffer boundary issue in the interface itself, exactly the same technique used at every earlier layer.
- Passive memory inspection: once an over-read exists, simply reading nearby memory over many attempts reveals structural clues (repeating patterns, plausible pointer-like values, predictable counters) about how the surrounding code and data are laid out, without needing to understand the code that produced them.
- Hardware-assisted automation: because each experimental attempt could crash or hang the target, the researcher built a small hardware rig to automatically power-cycle the device between attempts, allowing large numbers of blind trials to run unattended.
- Iterative, outcome-driven refinement: rather than aiming for a specific known effect, the process favoured any outcome that was distinguishable from "nothing happened", an unusual crash, continued booting, or unexpected data transmitted, and used those signals to narrow down what was actually being affected.
This combination, of a discovered flaw, blind experimentation, and automated iteration, is a recognisable pattern in low-level hardware security research generally: when you cannot read the target's source, you characterise its behaviour empirically and let observed effects guide the next step.
5. What full Boot ROM access actually enabled
Once the Boot ROM's own code could be examined, its role in the wider boot sequence became clear enough to identify where the chain's signature-verification logic lived, and, separately, to demonstrate that it could be routed around under the researcher's control rather than the manufacturer's. The consequences the talk highlights are notable for being a mix of genuinely useful and genuinely risky:
- Device recovery: the affected devices had no built-in way to recover from a corrupted boot image at home. Bypassing the boot-chain's verification made it possible to load a known-good image and recover an otherwise "bricked" device, arguably a legitimate repair capability that the platform doesn't otherwise expose to users.
- Deep reverse-engineering access: with the full chain loadable and inspectable, every privilege level's boot-time state becomes visible, which helps future defensive and compatibility research (and, the deck notes, some memory is deliberately zeroed by the vendor beforehand specifically to limit exposure of sensitive user data through this path).
- Bypassing engineering-only restrictions that are normally locked to manufacturer test builds.
- Persistence risk: some boot stages support persistent configuration changes that survive a factory reset, though the talk notes other platform mitigations limit how effectively this particular weakness could be abused for that purpose.
6. Disclosure, and why it took so long
The core Boot ROM finding was reported in November 2023. Because the impact affected the root of the secure-boot chain across a device family, and because fixing it meaningfully required more than a simple software patch, the vendor requested, and was given, an unusually long disclosure timeline. Remediation work included rotating cryptographic security keys where necessary across affected models. Public disclosure was only completed in February 2026, over two years after the initial report, and the finding was assigned a CVE at that point. A second line of research on a related chip family (Exynos-based Samsung devices, studied separately after the Tensor findings) followed a similar arc: reaching an early boot interface, finding comparable buffer-handling weaknesses, and again demonstrating that image-loading and decryption logic in early boot stages could be subverted, with its own complications around partially self-decrypting boot images that briefly leave decrypted code unprotected in memory during execution.
7. What this means for the industry
- Control Transfer parsing deserves the same scrutiny at every boot layer, not just in the running OS. The same bug class recurred from the application OS all the way down to immutable ROM code, because nobody had tested the deepest layers as thoroughly as the outer ones.
- Undocumented recovery interfaces are still attack surface. "It's not publicly documented" is not a security boundary; it only raises the cost of discovery, not the difficulty of exploitation once found.
- Root-of-trust bugs need remediation plans, not just patches. Because Boot ROM code can't be updated, vendors need pre-existing plans for key rotation and layered mitigation in later stages, precisely so a ROM-level finding doesn't leave them with no options.
- Legitimate repair and security are in tension here. The same bypass that helps a user recover a bricked phone is, in different hands, a way around the platform's core integrity guarantee, an uncomfortable but recurring theme in root-of-trust research.
Is this exploit still usable today?
The core finding was disclosed to the vendor in 2023, remediated across affected models, and only made public in 2026 after fixes and key rotation were completed. It should not be treated as a current, unpatched attack against up-to-date devices.
Does this let someone unlock a stolen phone?
No. The research explicitly separates application-processor boot compromise from lock-screen authentication, which on the devices studied is handled by a separate, dedicated security chip untouched by this research.
Why does a Boot ROM bug take over two years to disclose?
Because Boot ROM code is physically immutable once a chip ships, fixing the underlying issue for future hardware and mitigating it for already-shipped devices (including rotating cryptographic keys) is a much bigger undertaking than shipping a software patch, and the vendor requested time proportional to that complexity.
Did this require special equipment?
Reaching some of the early boot interfaces required physical access to the device and, in places, opening it up; automating the research also involved a simple custom hardware rig to repeatedly power-cycle the target. None of it required equipment beyond what a determined hardware researcher could assemble.
Takeaways
- USB Control Transfers are a consistent, cross-layer attack surface on Android devices, from the running OS down to immutable Boot ROM code.
- Standard fuzzing tools artificially limit what they'll send; removing those limits exposed bugs invisible to conventional testing.
- A full Boot ROM compromise was achieved on two different chip families (Google Tensor and Samsung Exynos), enabling a secure-boot bypass.
- Boot ROM bugs are unpatchable by design; the only remedies are later-stage mitigations, key rotation, and fixes in future silicon, hence the multi-year disclosure timeline.
- The compromise reached the application processor's boot chain only, not the separate security chip guarding lock-screen authentication.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Official talk recording on YouTube — Black Hat channel.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- CVE-2026-0124 — the core Boot ROM finding referenced in the talk.
- CVE-2024-22012 — the earlier ABL-layer finding on Pixel 6A.
- Android Verified Boot documentation — background on the secure boot chain this research examines.