Security researchers have disclosed a new unpatchable BootROM exploit, dubbed usbliter8, targeting Apple’s A12 and A13 chipsets. The vulnerability, uncovered by Paradigm Shift, compromises the SecureROM—the first code executed when an Apple device powers on—by exploiting a hardware bug in the USB controller combined with a firmware configuration weakness. This allows attackers to achieve code execution during the earliest and most trusted stage of the boot process, undermining the hardware root of trust for millions of devices.
Unpatchable BootROM Exploit: Devices and Chips Affected
Paradigm Shift’s usbliter8 exploit impacts devices powered by Apple’s A12 and A13 system-on-chips, which include the iPhone XR, XS, 11 series, and several iPad and Apple Watch models. The vulnerability also extends to devices using the S4 and S5 Apple Watch chips. Although the exploit currently supports these specific chips, the researchers note that support for A12X and A12Z processors—found in older iPad Pro models—is technically possible but has not been implemented in the public proof-of-concept. Crucially, devices with A11 chips and older are not vulnerable, and Apple has addressed the underlying issue in A14 and later chips through correct hardware configuration, making newer devices secure from this specific attack.
Technical Breakdown: How the BootROM Exploit Works
The core of the exploit lies in a flaw within the Synopsys DesignWare USB 2.0 (DWC2) controller used by Apple. The researchers discovered that the controller’s Direct Memory Access (DMA) mechanism mishandles certain USB Setup packets. While the controller can hold up to three Setup packets before resetting its DMA pointer, sending malformed packets of unexpected sizes can cause the DMA address to underflow. This underflow creates a critical memory corruption primitive, enabling an attacker to overwrite sensitive data structures in memory.
Bypassing Hardware Protections
The exploit’s success depends on how SecureROM configures the USB subsystem on A12 and A13 devices. On these chips, Apple’s Device Address Resolution Table (DART) is set to a bypass mode during SecureROM execution, allowing DMA writes to reach sensitive SRAM regions. This is a key difference from A11 devices, where the USB driver manually resets DMA addresses after each packet, and from A14 and later platforms, which configure DART correctly to prevent exploitation.
Achieving code execution introduces further complexity, especially on A13 devices. While A12 attackers can overwrite a saved link register in the USB task stack to gain direct control of the program counter, A13 chips implement Pointer Authentication Codes (PAC). PAC cryptographically protects return addresses and other control-flow data. To bypass this, Paradigm Shift developed a multi-stage attack chain. This process involves corrupting DART-related heap structures, manipulating panic-handling routines, and timing DMA writes precisely to overwrite interrupt-handler structures stored in memory. By replacing a USB interrupt handler pointer with attacker-controlled values, the exploit ultimately gains arbitrary code execution within SecureROM.
Impact on the Device Boot Chain
Once code execution is achieved, the exploit gains broader system control by leveraging SecureROM’s transition from unprivileged EL0 to privileged EL1. On A12 devices, this involves a Return-Oriented Programming (ROP) chain that redirects execution into a boot trampoline. For A13 systems, the attack uses authenticated branch instructions and a specific gadget that enables execution despite PAC protections. After compromising SecureROM, usbliter8 installs a custom USB request handler within the Device Firmware Update (DFU) environment. This handler introduces powerful capabilities, including temporarily lowering the SoC’s production security mode, booting arbitrary iBoot images without signature verification, adding a “PWND” marker to USB device identifiers, and maintaining persistence within the current DFU session. For A13 devices, the researchers opt to restart SecureROM from SRAM after patching a copied version, allowing modifications to survive reinitialization without instability.
Why This Vulnerability Is Unpatchable
The severity of this vulnerability stems from its location. SecureROM code is permanently embedded in the hardware and cannot be modified via a software update. Because the underlying USB controller bug and the insecure DART configuration are baked into the silicon itself, Apple cannot release a patch for existing A12 and A13 devices. The company addressed the conditions in later chip generations, but the hardware flaw in affected devices will remain for their entire operational life.
What Is the Secure Enclave’s Role?
While the exploit compromises the application processor boot chain and Apple’s hardware root of trust, the researchers note that the Secure Enclave Processor (SEP) remains a separate security boundary. This separation is a critical design feature, as compromising the SEP would grant broader access to sensitive user data like biometrics and encryption keys. Nevertheless, gaining SecureROM-level access significantly expands the attack surface, allowing advanced attackers to install persistent, low-level malware that can survive operating system reinstalls.
What Affected Users Should Do Now
Given that this is a hardware-level, unpatchable vulnerability, there are no simple mitigation steps like installing a software update. Paradigm Shift privately reported the findings to Apple Product Security and coordinated disclosure before publication. For users concerned about long-term exposure, the most effective recommendation is to migrate to newer Apple hardware platforms unaffected by the flaw—specifically, devices with A14 and later chips. Organizations that manage fleets of affected devices should restrict physical access to them, as exploitation requires USB connectivity and direct interaction with DFU mode. Users should also be aware that while the risk of a targeted attack is low, the public availability of the proof-of-concept exploit increases the potential for misuse in physical-access scenarios. As a general security best practice, enable a strong passcode, use a reputable security solution with endpoint protection features, and monitor for any unusual device behavior that could indicate low-level tampering.
