INFRA-USBLITER8-2026

How it works

Every Apple device starts from the SecureROM (BootROM), a tiny piece of code burned into the chip that anchors the chain of trust: it loads and cryptographically verifies the next-stage boot loader, which verifies the next, all the way up to iOS. Break the SecureROM and you break the whole chain at its root. usbliter8 does exactly that, and it gets in through the USB port.

The flaw is in the Synopsys DesignWare USB controller (the DWC2 block) that Apple licenses and embeds in its chips. While a device sits in DFU mode it accepts USB Setup packets over the control endpoint, and the controller writes them into memory using direct memory access (DMA). It buffers up to three Setup packets back to back, then, on the fourth, resets its write pointer like a ring buffer. The mismatch is the bug: the controller advances the pointer by the size of each packet it writes, but it rewinds it by a fixed 24 bytes. Because the advance and the rewind do not match, every cycle nudges the pointer 12 bytes further backwards than it should be, giving an attacker a buffer underflow primitive that steps backwards through SRAM and writes attacker-controlled bytes wherever it lands. The researchers believe this is an inherent bug in the USB controller itself; the same Synopsys block ships in countless other devices, though no non-Apple target has been shown exploitable, because it also takes the two conditions below.

What makes A12 and A13 the sweet spot is how Apple configures the USB DART, its on-chip IOMMU (the "Device Address Resolution Table" that is supposed to police what a peripheral's DMA can touch). On these chips the SecureROM leaves the USB DART in bypass mode, so the controller's addresses are used as raw physical addresses with no isolation, and the underflowing pointer can reach straight into arbitrary SRAM. That is the difference between generations. The A11 dodges the bug because its USB code manually resets the DMA address after every packet, so the mismatch never accumulates. The A14 and later appear to configure the DART correctly, which traps the out-of-bounds write before it can do harm. Only the chips in between, A12 and A13 (and the matching Apple Watch S4 and S5), get caught.

The A12 falls quickly. It does not enforce Pointer Authentication on this path, so the attacker overwrites a saved return address on the USB task's stack, hijacks the program counter, runs a short ROP chain, lets DMA write the real payload into the boot trampoline, and jumps into privileged execution. The A13 is the harder target because it added Pointer Authentication Codes (PAC), which cryptographically sign return addresses so a tampered one fails validation. That forces a far more delicate route: corrupt heap metadata to abuse the controller's own cleanup routines as memory-zeroing tools, neutralise the device's reboot-on-panic safety by pinning a panic counter so a controlled fault does not reset the device, and finally hijack the USB interrupt handler to seize control without ever forging a signed pointer. On the A13 the SecureROM mostly runs in the unprivileged EL0 state, so the exploit issues an SVC 0 system call to cross into privileged EL1, then copies the ROM to the end of SRAM and re-maps it so it can patch a writable copy of code that is normally read-only.

What it gives an attacker, and what it does not

Once code is running in the SecureROM, usbliter8 injects a custom USB request handler into spare space in the boot trampoline and adds two new commands. One is demotion: it lowers the chip's production-mode security state (temporarily, until the next reboot), opening up debug surface that Apple normally fuses shut. The other boots raw, unsigned iBoot images with no signature checks at all, which is the moment the chain of trust is fully defeated. As a calling card it appends PWND, or PWND:[usbliter8], to the device's USB serial string, so an exploited device announces itself.

This is the foundation of two things. The first is jailbreaking: an A12/A13 BootROM exploit is the same kind of unpatchable footing that checkm8 gave the checkra1n jailbreak for older devices, and it could revive low-level jailbreaking and research for the iPhone XS through 11 generation. Note that usbliter8 is an exploit, not a finished jailbreak; a turnkey tool has to be built on top of it. The second, and more consequential, is forensic extraction. Tethered BootROM exploits are what mobile-forensics products and law-enforcement tools (in the lineage of Cellebrite, Grayshift/GrayKey, and Elcomsoft) lean on to perform device-level extraction across a wide range of hardware, because they grant code execution without needing Apple's cooperation.

The crucial limit, and the line that must not be overstated, is the Secure Enclave. Like checkm8, usbliter8 owns the application processor's boot chain but does not break the Secure Enclave, the passcode, or the encryption keys it guards. The researchers are explicit that it "doesn't affect SEP itself," while warning that it "opens up wider attack vectors" toward it. In practice that means a device with a strong alphanumeric passcode keeps its user data encrypted even after the boot chain is owned. Forensically the result splits on state: Before First Unlock (powered on but never unlocked since), only a thin set of keys is reachable; After First Unlock (unlocked at least once since boot), many class keys sit decrypted in memory and far more is extractable, but passcode-protected items still stay sealed without the passcode, and the Secure Enclave rate-limits any brute-force attempt. The honest framing is: an unpatchable device-level compromise that assists forensic extraction and enables jailbreaking, bounded by the Secure Enclave and the strength of the user's passcode. It is not a remote exploit, it is not wormable, and on its own it does not "unlock any iPhone."

Why it can never be patched

The SecureROM is mask ROM: its bits are fixed in the physical layout of the chip when the wafer is manufactured, so there is no firmware update, no signed patch, and no recall that can change a single instruction. Every affected A12, A13, S4 and S5 device carries this flaw for the rest of its service life. That is the defining property of a silicon-level bug, and the reason Apple's own guidance and the press converge on the same conclusion: migrating to newer hardware is the only true mitigation. Apple coordinated disclosure with Paradigm Shift before publication; there is no fix to ship and, as of disclosure, no CVE had been assigned. Apple's actual defence is architectural, not a patch: the security-critical secrets live in the separate Secure Enclave, which is designed to keep user data safe even when the application processor's kernel, or here its very first code, is compromised. The A14 and later close this specific door by configuring the USB DART properly in SecureROM, which is how a hardware-rooted weakness gets "fixed" in practice: not for the chips already in pockets, only for the ones designed afterward.

The checkm8 lineage, and why it matters

To understand usbliter8 you have to understand checkm8. In September 2019 the researcher axi0mX released checkm8 (CVE-2019-8900), a use-after-free in the USB DFU stack of Apple's SecureROM that affected every chip from the A5 to the A11, roughly the iPhone 4S through the iPhone X. It was the first unpatchable BootROM exploit for modern iPhones, it powered the checkra1n jailbreak, and it became a quiet workhorse of iPhone forensics. The widely held assumption afterward was that Apple had closed the era at the A12: the underlying use-after-free reportedly still existed, but the specific memory leak checkm8 relied on was made unreachable from the A12 onward, and the A13 added Pointer Authentication on top. The name usbliter8 itself rhymes with checkm8, and the work vindicates the lineage by finding a completely different way in (a USB-controller hardware bug plus the DART left in bypass) to reach the same unpatchable class of compromise on the two generations everyone thought were safe.

The deeper lesson is the one checkm8 first taught and usbliter8 now reinforces: hardware you have already shipped can never be truly fixed. A bug in immutable silicon is permanent, so the only durable defence is architectural isolation that contains the blast radius when (not if) the boot chain falls. That is exactly the role the Secure Enclave plays here. The boot chain was defeated; the data wall held. It is also a reminder that physical-access attacks are not a footnote: for a lost, stolen, or seized device, "the attacker needs to hold it" is precisely the situation that matters, which is why the practical risk is low for an ordinary user but real for enterprises, journalists, dissidents, and anyone whose device may fall into hostile hands. The vendor's own bug class, climbing one chip generation at a time, is a pattern worth watching: each new defensive layer (unreachable primitives, PAC, a correctly configured IOMMU) raises the bar, and each is eventually met by a new primitive that clears it.