New BootROM Break for Apple A12 and A13: Why “usbliter8” Cannot Be Patched Away

<h2><strong>Not Remote, But Physical</strong></h2><p>usbliter8 is not the kind of attack that triggers through a website, a message, or a malicious link. The attacker needs physical access to the device, must place it into DFU mode, and must connect it over USB to specially prepared hardware.</p><p>In the researchers’ setup, that hardware is an RP2350-based microcontroller board. Once the right conditions are in place, the exploit completes in under two seconds. The attack is not casual, but with the right equipment and access, it is fast.</p><p>The technical write-up and working proof-of-concept code were published on June 18, 2026, after coordinated disclosure with Apple Product Security.</p><h2><strong>Affected Chips and Devices</strong></h2><p>The public proof of concept directly targets A12, A13, S4, and S5 chips. The same approach is described as theoretically possible for A12X and A12Z, although working support for those variants has not been released.</p><p>That places a broad range of Apple products in scope. Affected device families include the iPhone XS, XS Max, and XR; the iPhone 11 lineup; the second-generation iPhone SE; the third-generation iPad Air; the fifth-generation iPad mini; the eighth-generation iPad; Apple Watch Series 4 and Series 5; the first-generation Apple Watch SE; the HomePod mini; and other products built on the same SoC families.</p><p>A11 is not affected. A14 and newer Apple chips are believed to be outside the reach of this specific exploit path.</p><h2><strong>The Root Cause Is in the USB Controller</strong></h2><p>At the center of usbliter8 is a low-level memory handling behavior in the Synopsys DWC2 USB controller.</p><p>The controller receives USB Setup packets and writes them into memory using DMA. Under normal conditions, several packets are buffered, and on the fourth packet the write position is moved backward by a fixed amount. However, the controller also accepts Setup packets smaller than the standard size. When that happens, the write pointer advances only by the number of bytes actually received, rather than by the expected packet length.</p><p>On its own, that difference may seem minor. Repeated over multiple packets, however, it causes the write pointer to drift backward. Eventually, the controller begins writing into memory areas it should never reach. In the researchers’ exploit chain, this becomes a controlled and repeatable buffer underflow.</p><p>The critical Apple-specific factor is the USB DART configuration during SecureROM execution. DART acts as the IOMMU layer that should restrict USB DMA access. On the affected A12 and A13 devices, this layer runs in bypass mode at that stage, allowing the faulty DMA writes to reach a much wider area of SRAM.</p><p>The same issue does not lead to exploitation on A11 because its USB driver resets the DMA address after each packet, preventing the drift from accumulating. On A14 and later, DART appears to be configured in a way that blocks this path.</p><h2><strong>A More Direct Path on A12, a Harder One on A13</strong></h2><p>On A12, the exploit path is relatively straightforward. The DMA buffer is placed near the USB task’s stack on the heap. That proximity allows the attacker to target saved control-flow data on the stack. Once the stored link register is overwritten, the next context switch can redirect execution to attacker-controlled code.</p><p>A13 makes the process harder because of Pointer Authentication. PAC is designed to protect return addresses stored on the stack from being replaced with forged values. Instead of directly overwriting a return address, the researchers used a more indirect sequence.</p><p>They first corrupted DART-related heap structures to create limited write primitives. Then they modified the panic depth counter so the chip would remain in an error loop instead of immediately rebooting. DMA timing was carefully controlled to avoid destroying the USB task’s critical saved registers.</p><p>The final step was overwriting the USB interrupt handler pointer in the BSS section. When the next USB interrupt arrived, the processor executed attacker-supplied code instead of Apple’s expected handler.</p><p>In both cases, the outcome is the same: code execution inside SecureROM at EL1 privilege level.</p><h2><strong>How Far the Chain of Trust Is Broken</strong></h2><p>Once exploitation succeeds, usbliter8 injects a custom USB request handler into the device. It also changes the USB serial string to include “PWND:[usbliter8],” marking the device as successfully exploited.</p><p>From there, an attacker can temporarily demote the SoC’s production mode or boot a raw, unsigned iBoot image without Apple’s normal signature checks. In practical terms, this allows code that Apple’s boot chain would normally reject to run during an early boot stage.</p><p>The research does not demonstrate a direct compromise of the Secure Enclave. Apple’s Secure Enclave is designed as a separate security boundary from the application processor. Still, BootROM-level control may create new avenues for future attacks against that boundary.</p><h2><strong>A New Hardware Boundary After checkm8</strong></h2><p>To understand why usbliter8 matters, it helps to look back at checkm8, the SecureROM exploit disclosed in 2019. checkm8 created a permanent hardware-level attack surface across Apple devices from A5 through A11. Apple could not fully remove it through software updates; it could only prevent similar issues in later hardware generations.</p><p>usbliter8 belongs to the same general class, but it reaches newer devices. A12 and A13 were part of the post-checkm8 generation that had long been considered beyond that earlier attack path. This exploit shows that, with physical access, SecureROM-level trust can also be broken on that newer generation.</p><h2><strong>What It Means for Users and Organizations</strong></h2><p>For everyday users, this is not an urgent remote-exploitation threat. An attacker needs the device in hand, must put it into DFU mode, and must use specialized USB hardware. Those requirements keep the attack outside most ordinary threat models.</p><p>The picture changes in high-security environments. Government agencies, research labs, journalists, human rights workers, critical infrastructure teams, and companies handling sensitive data should treat physical custody more seriously. A vulnerability at this level creates a risk that cannot be compensated for by simply installing the latest software update.</p><p>Organizations should identify whether A12, A13, S4, or S5 devices are still being used in sensitive roles. Those devices should be marked in asset inventories, and replacement with A14 or newer hardware should be considered where the threat model justifies it. DFU access, service workflows, USB connection policies, and device handoff procedures should also be reviewed.</p><p>usbliter8 is not a remote mass-exploitation tool against Apple users. Its impact comes from the fact that it lives at the hardware root of trust. With public proof-of-concept code now available, the issue is no longer just a research finding. It has the potential to become a reusable technique in other people’s toolkits.</p><p>The right reading of the risk is this: there is no need for panic among average users. But anywhere physical access is part of the threat model, A12 and A13-generation devices now belong in a different security category.</p>