Because usbliter8 targets SecureROM (BootROM), it executes before Apple’s secure boot chain. That gives it a privileged position similar to what made earlier BootROM exploits so valuable. A BootROM exploit can provide a foundation for a jailbreak because it cannot be patched on affected hardware through software updates.
However, a usable jailbreak still requires much more than initial code execution. Developers would need to:
- Achieve reliable arbitrary code execution in BootROM.
- Bypass or work around later-stage security mechanisms (such as the bootloader, kernel protections, and code-signing enforcement).
- Develop a stable exploit chain that works across supported devices and iOS versions.
- Build the user-facing components of a jailbreak (payloads, bootstrap, package manager integration, persistence model, etc.).
Whether a jailbreak is practical also depends on the capabilities provided by usbliter8 itself. If it offers sufficient control to patch or replace later boot stages, it could become the basis for a jailbreak. If its capabilities are more limited, additional vulnerabilities may still be required.
Historically, the checkm8 BootROM exploit eventually led to jailbreaks such as checkra1n because it provided a permanent hardware entry point on affected devices. That said, usbliter8 targets a different generation of hardware (A12/A13), and it should not be assumed that the same outcome will necessarily follow.
What can you do with usbliter8?
This is arguably the most exciting aspect of the usbliter8 exploit—and likely the reason many readers are interested in it.
A BootROM exploit provides an exceptionally powerful entry point because it compromises the very first stage of Apple’s secure boot process. Since execution occurs before the operating system and most security mechanisms are initialized, it offers an unprecedented level of control over the device.
That said, “BootROM exploit” does not mean unlimited capabilities. While usbliter8 could potentially enable tethered downgrades and jailbreaks on any iOS version, including the latest releases, several hardware and software protections significantly limit what is actually possible.
Boot Process Register (BPR)
Apple introduced the Boot Process Register (BPR) in iOS 14 to strengthen security against BootROM based attacks.
Because exploits such as checkm8 and usbliter8 require the device to boot from DFU mode, BPR restricts access to protected user data during that boot process.
This behavior is why jailbreaking A11 devices with tools like checkra1n or palera1n required disabling the device passcode. If an A11 device had previously been protected with a passcode, it often had to be erased before jailbreaking.
Older A10 devices largely avoided this limitation thanks to the blackbird SEP exploit, which allowed researchers to bypass these restrictions. Unfortunately, no equivalent Secure Enclave Processor (SEP) exploit exists for A11, A12, or newer chips.
That became an even bigger challenge starting with iOS 17.
The iOS 17 limitation
Beginning with iOS 17, Apple further strengthened BPR.
When a device is booted from DFU mode, the Secure Enclave Processor (SEP) now refuses to decrypt and mount the encrypted user partition (such as /var and /var/mobile). Instead, the system immediately triggers a kernel panic, preventing the device from booting successfully.
Because of this behavior, traditional semi-tethered jailbreaks similar to checkra1n or palera1n are currently not feasible on A12 and A13 devices using usbliter8.
A jailbreak built on this exploit would instead be fully tethered, meaning:
- The device cannot boot normally after a restart.
- Every reboot requires reconnecting the device to external hardware to launch the exploit again.
A possible workaround
One potential solution is to create an unencrypted copy of the user partition.
Instead of mounting the original encrypted /var, the jailbreak could boot using this duplicated, unencrypted partition. Since SEP no longer needs to decrypt user data, the device can boot without triggering the panic.
This approach could make a semi-tethered jailbreak possible, but it introduces several significant compromises:
- Password-protected Wi-Fi networks may not function correctly (although software workarounds could be possible).
- Features that depend on SEP authentication, including the device passcode, would no longer operate normally.
- Applications relying on the Secure Enclave keychain may fail to authenticate. For example, signing in with Google or Apple within certain apps may not work correctly. While software fixes may exist, they would store sensitive credentials outside the Secure Enclave and therefore reduce security.
- Storage usage would increase substantially because the entire user partition would effectively be duplicated. Devices with large amounts of installed apps and user data could lose a significant amount of free storage.
- Data stored while running the jailbreak would remain separate from the normal iOS installation. Changes made in jailbroken mode would not automatically appear after rebooting into stock iOS, and vice versa.
Downgrades
The exploit also opens the possibility of downgrading supported devices to older iOS versions.
However, these downgrades would remain tethered, as bypassing the Secure Enclave restrictions still requires boot-time modifications every time the device starts.
For these reasons, users should not expect a complete, consumer-friendly jailbreak to appear overnight. Supporting A12 and A13 devices would require extensive engineering work, compatibility testing, and numerous software modifications to overcome the limitations imposed by modern iOS security.
Hardware requirements
At the moment, using usbliter8 requires dedicated external hardware, such as a Raspberry Pi Pico or Waveshare RP2350-USB-A microcontroller development board to trigger the exploit.
There is currently no indication that this requirement can be eliminated.
Because the vulnerability depends on very specific USB communication behavior, it is considered highly unlikely that the exploit will ever work directly from a standard PC. Even with custom USB drivers, compatibility would still depend heavily on the capabilities of the host computer’s USB controller.
In the next article, I will show you how to flash USB microcontroller board with usbliter8 exploit and boot your A12 or A13 device into PWND mode.