Executive Summary
The usbliter8 exploit represents the first public, unpatchable hardware-level vulnerability affecting Apple's SecureROM since checkm8 (2019). By chaining a silicon-level flaw in the Synopsys DWC2 USB controller with a SecureROM configuration oversight, researchers have achieved arbitrary code execution at EL1 (privileged mode) inside the BootROM.
Because this code is permanently fused into the processor during manufacturing, Apple cannot patch this flaw with a software update. Affected devices will carry this vulnerability for their entire operational lifespan.
Supported Chips & Device Model List
The usbliter8 vulnerability explicitly targets Apple A12, A13, S4, and S5 Systems-on-Chip (SoCs). Devices powered by A11 or older are not vulnerable, while A14 and newer chips have correctly hardened hardware boundaries.

đ± iPhones
-
iPhone XR (A12)
-
iPhone XS & XS Max (A12)
-
iPhone 11 (A13)
-
iPhone 11 Pro & 11 Pro Max (A13)
đ± iPads
-
iPad Air (3rd Generation)
-
iPad mini (5th Generation)
-
iPad (8th & 9th Generation)
-
iPad Pro 11-inch (1st & 2nd Gen â A12X/A12Z) â theoretically supported but not yet implemented in public PoC
-
iPad Pro 12.9-inch (3rd & 4th Gen â A12X/A12Z) â theoretically supported but not yet implemented
â Apple Watches & Wearables
-
Apple Watch Series 4 (S4)
-
Apple Watch Series 5 (S5)
-
Apple Watch SE (1st Generation) (S5)
đ„ïž Additional Displays & Apple TV
Technical Methodology
Root Cause Analysis
The exploit abuses a low-level hardware bug in the Synopsys DWC2 USB controller. The controller stores incoming USB Setup packets via DMA, buffering up to three packets before resetting its write pointer on the fourth by decrementing it by a fixed 24 bytes. It also accepts smaller-than-standard packets, incrementing the pointer only by the actual bytes written.
This mismatch accumulates into a repeatable buffer underflow, stepping the write pointer backwards through memory 12 bytes at a time.
What makes this dangerous on A12 and A13 specifically is how Apple configured the USB DART (IOMMU) inside SecureROM. On these devices, it runs in bypass mode, allowing the underflowing DMA pointer to reach and overwrite arbitrary SRAM.
Architectural Differences
A11Â is not affected because its USB driver manually resets the DMA address after every packet, preventing accumulation.
Hardware Requirements
Why Standard PCs Cannot Run This Exploit
The exploit requires absolute, cycle-accurate control over physical data lines to intentionally violate USB specifications. Standard Mac/PC USB stacks and conventional microcontrollers (ESP32, STM32) have rigid USB protocols burned into their physical layers, which automatically fix or block illegal packet structures.
Required Hardware
The exploit uses Raspberry Pi Pico 2 (RP2350-based) microcontroller boards:
-
Waveshare RP2350 USB-A
-
Waveshare RP2350 Zero
-
Pimoroni TINY2350
-
Raspberry Pi Pico 2
The RP2350's unique Programmable I/O (PIO) blocks allow engineers to "bit-bang" their own software-defined communication engines, bypassing rigid hardware USB limitations to fire off non-compliant, malformed data blocks at exact microsecond intervals.
RP2040 can theoretically be used but is NOT stable, and Apple A13 SoC does NOT work at all.
Connection Details
-
Use a Lightning to USB-A cable with R13 resistor optionally removed
-
GPIO12 â D+ / GPIO13 â Dâ (configurable)
-
Keep the remaining cable (with Lightning end) relatively short
Firmware Flashing

Compiled UF2 images for supported boards are available in the official repository. Flash via:
Exploitation Process
Step 1: Enter DFU Mode
-
Do this while device is connected to your Mac/PC
Step 2: Connect to RP2350
Status Indication (RGB LED)
| LED State | Status |
|---|---|
| Blinking orange | RP2350 is booting (~2 seconds) |
| Steady orange | Idle, ready to exploit |
| Blue | Exploit in progress |
| Green | Exploit succeeded! |
| Red | Exploit failed |
Single-Color LED
| LED State | Status |
|---|---|
| Slow blinking (200ms) | RP2350 booting |
| Breathing | Idle, ready |
| Rapid blinking (100ms) | Exploit in progress |
| Steady | Success! |
| Off | Failed |
After either success or failure, reboot the microcontroller board via on-board button, picotool, or by replugging power.
Post-Exploitation Capabilities

Verification
After exploitation, the USB serial number will contain PWND:[usbliter8]:
CPID:8020 CPRV:11 CPFM:03 SCEP:01 BDID:0E ECID:XXXXXXXXXXXXXXXX IBFL:3C SRTG:[iBoot-3865.0.0.4.7] PWND:[usbliter8]
Python Control Tool (usbliter8ctl)
The official repository includes a Python control tool with two primary commands:
./usbliter8ctl {boot,demote} ...
-
boot â Boot a raw iBoot image (decrypted, free of any container) -
demote â Demote production mode (activates JTAG/SWD debugging interface)
Community Extensions
Elcomsoft has published modifications to the public exploit providing additional primitives:
-
Execute arbitrary functions in BootROM
-
Read memory (viaÂ
ipwndfu --hexdump) -
Write memory
-
Boot unsignedÂ
img4Â images (compatible with iTunes/idevicerestore)
Security & Privacy Implications
What This Exploit Does NOT Break
User files, passcodes, and biometric profiles remain protected behind the physical security boundary of the Secure Enclave Processor (SEP), which runs on its own isolated hardware architecture.
However:Â BootROM-level control may open new attack vectors for compromising the Secure Enclave, though this has not been demonstrated.
Risk Assessment
Mitigation Strategy
"Migrating to newer hardware remains the most effective mitigation"
Recommended Actions for Organizations
-
Inventory all A12, A13, S4, and S5 devices in sensitive roles
-
Prioritize refresh toward A14 or newer hardware
-
Strengthen device custody controls â avoid DFU mode over untrusted USB cables or hosts
Comparison to checkm8
Like checkm8, usbliter8 is tethered and requires physical access, but extends the unpatchable condition to a new generation of devices.
References
-
TechCrunch: "New unpatchable flaw in Apple chips"
đ How to Bypass Activation Lock on A4/A5/A6 iDevices Using Raspberry Pi Pico | Complete Tutorial
Â