iPhone Security & BootROM Research

USBLiter8 – iPhone A12 & A13 BootROM Exploit Explained

8 min read

Quick Summary: USBLiter8 is a permanent, hardware-level BootROM exploit for iPhone XR, XS, XS Max, iPhone 11 / Pro / Pro Max, and related Apple Watch / iPad chips. It was published on June 18, 2026 by Paradigm Shift Technology after coordinated disclosure with Apple. Because the flaw lives in read-only silicon, Apple cannot patch it via a software update. Affected devices will carry this vulnerability for their entire lifetime.

What Is USBLiter8?

USBLiter8 is a tethered BootROM exploit — meaning it requires physical USB access to the device each time it is used. It targets a hardware-level bug inside Apple's DWC2 USB controller (manufactured by Synopsys) that is present in the A12, A13, S4, and S5 system-on-chips. Because the vulnerable code lives in the SecureROM (a mask-programmed, read-only chip), the bug cannot be fixed by any iOS or firmware update.

The exploit was discovered and developed by three researchers at Paradigm Shift Technology: @__gsch and @hdesk (bug & exploitation) plus a third credited-but-unnamed team member (post-exploitation & development). The full proof-of-concept source code was released publicly on GitHub at github.com/prdgmshift/usbliter8 (1,300+ stars, 141 forks as of late June 2026).

Affected Devices

Any device whose SoC belongs to the list below is permanently vulnerable:

Apple SoC	iPhone Models	Other Devices
A12 Bionic	iPhone XR, XS, XS Max	iPad mini 5, iPad Air 3, iPad Pro 11″ (2018), iPad Pro 12.9″ (2018)
A13 Bionic	iPhone 11, 11 Pro, 11 Pro Max	iPhone SE (2nd generation), iPod touch 7th gen
S4 / S5	—	Apple Watch Series 4, Series 5, Series 6 SE

Not affected: A11 (iPhone 8/X) — Apple's engineers manually reset the DMA pointer after each USB packet in the A11 SecureROM, accidentally preventing this specific attack. A14 and newer (iPhone 12 onwards) configure the USB DART (DMA Address-Remapping Table) correctly in SecureROM, making the vulnerability unexploitable on those chips.

The Root Cause — DWC2 DMA Buffer Underflow

Every USB control transfer starts with a Setup transaction: an 8-byte packet describing the request the host wants to send. The DWC2 USB controller stores up to three consecutive Setup packets in a small memory ring buffer using Direct Memory Access (DMA).

Here is where the bug lives: when a fourth Setup packet arrives, the controller decrements its internal DMA pointer by exactly 24 bytes (the size of three 8-byte packets) to "wrap around." However, the controller also accepts shorter packets, always rounded up to 4-byte chunks. If those shorter packets were used before the fourth one arrives, the pointer increments by a smaller amount than expected — but the reset always decrements by the full 24 bytes regardless. The net result is a buffer underflow in 12-byte steps: the DMA writes now land before the intended buffer, progressively overwriting nearby memory.

On A12 and A13 the USB DART is left in bypass mode inside SecureROM, which means the attacker can freely overwrite any SRAM region adjacent to the DMA buffer — including heap data, stack frames, and global variables — using carefully timed USB packets.

How the Exploit Achieves Code Execution

On A12 (and S4/S5) — Straightforward Stack Corruption

On A12 the DMA buffer sits directly on the heap, which is allocated just before the USB task's stack. The exploit overwrites a saved return address (LR) on the stack and gains PC (program counter) control when the scheduler next switches back to the USB task. No Pointer Authentication (PAC) is in use, so a classic Return-Oriented Programming (ROP) chain of just three steps is sufficient to:

Redirect the DMA destination to the boot trampoline memory (normally execute-only, but DMA ignores MMU permissions)
Wait ~400 ms for the shellcode payload to be written there
Jump to the trampoline, elevate to EL1 (privileged) mode via SVC 0, and patch the SecureROM in-memory

On A13 — Multi-Step PAC Bypass

A13 introduced Pointer Authentication Code (PAC) protection on stack-stored return addresses, requiring a significantly more complex attack chain. The researchers had to bypass three separate mitigations:

Heap metadata checksums — verified on every heap operation; neutralised by zeroing the affected global pointer via a controlled 16-byte zero-write primitive into DART MMIO registers
LR signing during context switches — bypassed by timing DMA writes to occur while the USB task is awake, so that the genuine signed LR is saved back over the corrupted value before the task yields
Panic counter — overwritten with 0xF (via a side-effect in dart_flush_maybe()) so a triggered panic causes an infinite loop rather than a reboot, keeping USB IRQs running

After this setup, the exploit walks the DMA writes all the way to the global USB IRQ handler table in BSS, overwrites the handler pointer with an arbitrary value, and gains full PC control when the next USB interrupt fires. A nice firmware gadget at 0x10000A5E8 conveniently loads a function pointer from attacker-controlled memory with only an BLRAAZ (PAC-authenticated branch that accepts a null IA key) authentication — which passes trivially.

What Happens After Exploitation

Once PC control is achieved, the exploit runs with EL1 (kernel-equivalent) privileges. It then:

Injects the string PWND:[usbliter8] into the device's USB serial number — the standard indicator that a BootROM exploit has succeeded
Installs a custom USB control-request handler (placed in unused space within the boot trampoline area)
On A13: copies the SecureROM to the top of SRAM and remaps the MMU so the patched copy runs from the original address — this survives a SecureROM restart without rebooting the phone
Cleanly restores all corrupted heap allocations and returns execution to normal DFU mode

The custom handler exposes two new USB commands via the usbliter8ctl Python tool:

demote — Lowers the SoC's production mode flag (temporarily, until next hard reboot). Required for some low-level operations.
boot <iBoot.raw> — Boots any raw (decrypted, unsigned) iBoot image directly. This is the foundation for carrier unlock and iCloud bypass tools.

Hardware Required to Run the Exploit

Because the bug is triggered at the raw USB electrical layer, a standard Mac or PC USB host controller cannot send the necessary malformed Setup packets. A Raspberry Pi RP2350-based microcontroller is required as the USB host:

Board	Notes
Waveshare RP2350 USB-A	Recommended; optionally remove resistor R13 for stability
Waveshare RP2350 Zero	Tested and working
Pimoroni TINY2350	Tested and working
Raspberry Pi Pico 2	Tested and working

Important: Use a Lightning to USB-A cable only. USB-C cables have a different pinout and will not work. Keep the cable short. RP2040 boards are theoretically supported but are unstable and do not work at all with A13.

Step-by-Step Usage

Flash the firmware — Download the pre-compiled UF2 image from the GitHub Releases page for your specific board. Flash via USB mass-storage or picotool.
Put iPhone in DFU mode while it is still connected to a Mac or PC. Do not enter DFU by breaking LLB — this will not work.
Unplug from Mac/PC and immediately replug the Lightning cable into the RP2350 board.
Watch the LED — the exploit completes in 0.7 – 1.2 seconds:
- ? Orange steady = idle, ready
- ? Blue = exploit in progress
- ? Green = exploit succeeded
- ? Red = failed (reboot board and try again)
Replug to Mac/PC — the USB serial number will now end with PWND:[usbliter8]
Run the control tool:
pip install pyusb
./usbliter8ctl demote — lower production mode
./usbliter8ctl boot path/to/iBoot.raw — boot a custom iBoot

USBLiter8 vs. checkm8 — Key Differences

	checkm8	USBLiter8
Discovered by	axi0mX (independent)	Paradigm Shift Technology
Published	September 2019	June 2026
Affected chips	A5 – A11	A12, A13, S4/S5
iPhone models	iPhone 4s – iPhone X	iPhone XR, XS, XS Max, 11 series
Root cause	USB DFU use-after-free	DWC2 DMA buffer underflow
PAC bypass needed	No	Yes (for A13)
Special hardware needed	No (works from Mac/PC)	Yes (RP2350 microcontroller)
SEP affected	No	No (widens attack surface)
Patchable?	No (BootROM)	No (BootROM)
Tethered?	Yes	Yes

Implications for GSM & Unlocking Professionals

This exploit extends the range of devices that can be serviced without authorised unlock codes. The key use cases relevant to our industry:

Carrier unlock — By booting a custom iBoot image, tools can read or modify the iPhone's baseband NVM (non-volatile memory), enabling full network unlock on A12/A13 iPhones without requiring an official unlock from the carrier.
iCloud Activation Lock removal — Boot-chain control allows bypassing the Activation Lock screen, a common requirement for second-hand device repair and resale.
Passcode-locked devices — With EL1 code execution, read-only hardware identifiers can be accessed, supporting data recovery workflows.
USB-based tool activation — Demotion lowers the production security flag temporarily, enabling low-level diagnostic access used by some professional GSM tools.

Important for shop operators: USBLiter8 is a tethered exploit — it must be applied each time after a full power cycle. The exploit does not survive a normal reboot. Physical USB access is required in every session. It cannot be triggered remotely.

Security & Legal Considerations

USBLiter8 was responsibly disclosed to Apple Product Security prior to publication. Apple was given time to review the findings and coordinate the disclosure timeline. Apple acknowledged the research but cannot patch the vulnerability because it lives in read-only silicon.

From a user security perspective:

The exploit requires physical DFU mode access — your iPhone cannot be attacked remotely or over Wi-Fi/Cellular.
The Secure Enclave Processor (SEP) is not directly compromised by USBLiter8, though gaining BootROM-level code execution does widen the attack surface for SEP research.
For end users concerned about physical device security, upgrading to an A14 or newer device (iPhone 12 or later) is the only complete mitigation.