How to Bypass an iPhone with the Pi Pico 2: A Complete Guide

How to Bypass an iPhone with the Pi Pico 2: A Complete Guide

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)

  • iPhone SE (2nd Generation, 2020) (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)

  • HomePod mini (S5)

đŸ–„ïž Additional Displays & Apple TV

  • Apple TV 4K (2nd Generation)

  • Apple Studio Display

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



Chip Attack Vector Mitigation
A12 DMA buffer sits adjacent to USB task stack; overwriting saved link register grants program counter control Straightforward memory corruption
A13 Pointer Authentication Codes (PAC) protect stack return addresses; bypass requires corrupting DART heap structures and overwriting USB interrupt handler pointer in BSS More complex multi-stage layout required

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)

  • DO NOT use USB-C cables – they have different pinouts

  • 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:

  • Mass storage protocol of RP2350 bootrom

  • picotool

Exploitation Process

Step 1: Enter DFU Mode

  • Do this while device is connected to your Mac/PC

  • DO NOT enter DFU by breaking LLB – this will not work

Step 2: Connect to RP2350

  • Unplug device from Mac/PC and replug into the RP2350 board

  • Exploit completes in 0.7–1.2 seconds

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]:

text
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:

bash
./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



User Type Risk Level
General consumers Low – Requires physical access, DFU mode, technical knowledge, and specialized hardware
High-security environments Critical – Physical security boundary is permanently gone; device-custody and hardware-retirement decisions required

Mitigation Strategy

"Migrating to newer hardware remains the most effective mitigation"

Recommended Actions for Organizations

  1. Inventory all A12, A13, S4, and S5 devices in sensitive roles

  2. Prioritize refresh toward A14 or newer hardware

  3. Strengthen device custody controls – avoid DFU mode over untrusted USB cables or hosts

Comparison to checkm8



Feature checkm8 usbliter8
Release year 2019 2026
Affected chips A5–A11 A12, A13, S4, S5
Requires custom microcontroller? No (runs on PC) Yes (RP2350 required)
Post-exploit capabilities Full read/write/execute Initially limited; community extensions add full primitives

Like checkm8, usbliter8 is tethered and requires physical access, but extends the unpatchable condition to a new generation of devices.

References

  • Paradigm Shift official blog & GitHub repository

  • SecurityWeek: "New Exploit Bypasses Apple's Boot Defenses"

  • The Hacker News: "Unpatchable usbliter8 Exploit"

  • Elcomsoft blog: "A12 usbliter8 BootROM sigpatches"

  • TechCrunch: "New unpatchable flaw in Apple chips"

🔓 How to Bypass Activation Lock on A4/A5/A6 iDevices Using Raspberry Pi Pico | Complete Tutorial

usbliter8 File

 

Build your next project

Explore genuine electronics and embedded systems products

Shop Arduino, ESP32, Raspberry Pi, STM32, robotics, sensors, power modules, LED lighting and electronic components from Chip.pk.

Explore Products