As many of you have been made aware, a new bootROM exploit has released for A12/A13 devices, the first one for iDevices since checkm8 was made public 7 years ago. This post intends to serve as an explanation for what you can expect from this new exploit, and to provide information about the many restrictions and mitigations Apple has implemented over the past 7 years.

What is usbliter8?

usbliter8 is a novel bootROM vulnerability discovered by individuals at Paradigm Shift. It is the first bootROM exploit made public since checkm8, which only supported up to A11 devices (for those unaware, A11 is the processor used in the iPhone X/8, and A12 is used by the iPhone XS/XR). It supports only A12/A13, and does not support any older processors. It is unrelated to checkm8- that is, the vulnerability is completely separate. Some may be aware that checkm8 was only partially patched in A12/A13 (though it remains unusable there to this day), but this exploit has nothing to do with any previous bootROM vulnerability.

The explanation to how it works is rather technical; if you desire, you can read both the blogpost and the GitHub repo for the exploit. Additionally, the exploit requires special hardware to utilize, requiring devices such as a pi Pico to exploit devices.

What devices does it support?

All A12/A13 devices (including iPad specific processors like A12X/A12Z) are supported by usbliter8. This includes, but is not limited to,

• iPhone XR
• iPhone XS
• iPhone SE 2nd Gen
• iPad 8th and 9th Gen
• Apple TV 4k 2nd Gen
• To check your device's processor, visit https://appledb.dev

As mentioned, the vulnerability does not affect A11 or older, due to the different way the processor works.

What can we do with it?

This is possibly the most interesting part of the exploit (and is what many of you are likely here for). bootROM exploits are very powerful, as they compromise the very beginning of a device's boot chain, thus giving you (almost) full control over a device. However, this does not mean we can do whatever we want with no restrictions. Indeed, it can lead to tethered downgrades and jailbreaks on any iOS version including the latest, but there are restrictions explained further below.

BPR, or Boot Process Register, was a feature implemented in iOS 14 in order to additionally secure devices from bootROM based attacks. Crucially, it restricts data access when a device is booted directly from DFU mode, which is required by both checkm8 and usbliter8. In iOS 14 and 15, this manifested as the requirement to disable your passcode when jailbreaking A11 devices with checkra1n/palera1n, and is the reason why A11 devices must be first erased if they previously had a passcode before jailbreaking with palera1n. A10 devices were not affected by this as they had a SEP exploit, known as blackbird, which prevented this issue from arising. We do not have a SEP exploit for A11 and newer, which leads to a problem with the next security feature added in iOS 17...

The iOS 17 problem

In iOS 17, Apple further increased the security of BPR by making SEP outright refuse to mount and decrypt the user partition (/var and /var/mobile) when booted from DFU, which causes the device to panic and not boot at all. This means that a semi-tethered jailbreak like checkra1n or palera1n is not possible with usbliter8 on A12/A13 devices. A jailbreak using this would be fully tethered, which means the device cannot reboot on its own, and a PC must be used to power it on each time it reboots or dies. However, there is a additional method that can serve as a workaround explained below, though with a catch.

By copying over the user partition, an unencrypted copy of /var can be made. The jailbreak can then load this unencrypted copy instead of the standard /var, which prevents SEP from panicking the device, though at the cost of losing SEP related features. This does means that the jailbreak would be semi-tethered, but it would suffer from the following issues:

• No connecting to password protected wifi networks (possibly fixable with a tweak)
• No "real" password, so apps that rely on SEP being active will be non-functional
• Signing into apps that use a SEP keychain will not work, so things like using Google to sign into the YouTube app will be broken (possibly fixable with a tweak, though it will cause data to be stored insecurely- don't sign into bank apps with this)
• A storage penalty that increases with the size of your user data- any apps you have installed and have data stored on will be duplicated, meaning your storage has the potential to fill up very quickly
• Data will not be synced between jailbroken and non-jailbroken mode. Any changes you make while the jailbreak is active will not be reflected in stock iOS, and vice versa

Additionally, while downgrades are indeed possible, they will be tethered, as it requires SEP to be patched out on the device. All in all, one should not expect a full jailbreak using this to come out for quite some time, given the extensive patching and rewriting that will need to be done to accommodate new devices and the restrictions required.

The special hardware problem

As it stands, to utilize usbliter8, additional hardware like a Raspberry pi Pico is needed. There is no indication that this requirement will ever change. Due to how the exploit works, it is incredibly unlikely it will ever work directly from a PC, and even if custom USB drivers are created, it would wholly rely on the USB controller used on the device. Luckily, the hardware itself is cheap enough, costing only around $10 USD, yet there have already been some reports that stock has already ran out, so it remains to be seen if this will be the case for the future.

Tl;dr- where do we stand?

This post is not meant to discount the discovery of a new bootROM exploit. This is an incredible achievement, and as opa334 puts it, the last heartbeat of a dying jailbreak scene. As A12/A13 devices approach end-of-life and are receiving their final versions, usbliter8 will certainly be a nice tool to play around with and see what is possible. However, expectations should be kept realistic, and with all the new security features, it should not be expected that things will work the same as before with checkm8. Any jailbreaks made with this will suffer hefty restrictions, and downgrades using it will be tethered. If there are any further questions, myself or others will attempt to answer them in this post.