BootROM exploits are an important part of modern low-level forensic acquisition, and our Elcomsoft iOS Forensic Toolkit is no stranger to it. It allows getting code execution at the earliest stage on the device and lets us then load custom software for data decryption and extraction. It has been almost 7 years since the last major BootROM exploit called checkm8 was released, which exploits Apple chips up to A11 (iPhone 8 / iPhone X).

More recently, just last month, a new BootROM exploit called usbliter8 was published. The vulnerability affects A12 (A12X/A12Z), A13 and S4/S5 chips and the exploit published by Paradigm Shift supports most of them, excluding A12X/A12Z. After seeing this unexpected release, we at Elcomsoft have immediately began researching affected devices and are actively working on incorporating the new exploit in our software to extend the range of supported combinations of devices / iOS versions in our products.

In this blogpost we will take a quick look at the exploit, focusing only on A12, compare it to checkm8 and contribute some of our own research.

Quick look into the exploit

The original blogpost published by Paradigm Shift (which can be found here) explains how the bug works and goes into great detail on how they have exploited it.

As a quick summary, the bug is in the USB controller itself, which gets exploited by sending malformed (undersized) USB control packets. Since these malformed packets are so out of spec, a normal USB controller cannot even send them. So in order to exploit the bug, a microcontroller is used. In this case – a Raspberry Pi Pico RP2350 or RP2040. By utilizing a microcontroller, it is possible to have complete and absolute control of every packet send over USB, which allows crafting even the most obscure malformed packets as required to exploit this bug.

If you have been following our blog for a while, you might be reminded of a similar situation regarding checkm8 on the A5 chips (check our blogpost here). However, unlike checkm8 on A5, the usbliter8 exploit can’t even be triggered by the USB controller of the Pico and requires the USB lines to be connected to GPIO pins where PIO statemachines implement the lowest level of the USB protocol directly on the wire, bypassing the need for any USB controller to get involved.

Comparing usbliter8 to previous exploits

Lets do a few comparisons of usbliter8 with previous exploits.

Apart from the fact that special physical hardware is needed to run the exploit, there is one other major difference between usbliter8 and previous exploits like checkm8 / limera1n.
Namely the USB handler or in other word the “post exploit payload” that is injected.

Limera1n

When checkm8 was released, the ipwndfu project did a tremendous job of unifying the capabilities that are available post-exploit. Taking the limera1n exploit as an example, while specifically focusing on the variant of ipwndfu (check shellcode here). After running the exploit you have the following capabilities:

• execute arbitrary functions
  • read memory
  • write memory
• load unsigned img3 images

The shellcode provides a way to execute arbitrary functions inside the BootROM. Since the BootROM already has the capability to receive data from the host (it’s designed for uploading an image to boot after all), you can pair that with the ability to call “memcpy” (or “memmove”) and you got yourself a write-what-where primitive.

Interestingly, the BootROMs compatible with this exploit still had the ability to “read back” the data that was sent (this was removed in later revisions). Now, if we pair this with our memcpy primitive, we got a read-what-where primitive. The way it works is we first call memcpy to copy whatever memory we want to read to the loadaddress, then use the readback function to transfer to the host what lies at the loadaddress (normally only things that the host has sent).

By having read/write/executing primitives, one can do all kinds of things inside the BootROM like accessing the AES engine and decrypting firmware keys, or demoting the device, dumping iBoot or injecting even more custom shellcode, and so on. The options are limitless.

Additionally, the limera1n payload allows booting unsigned images, which is the most useful feature. It does so in a way that works the same as booting a regular signed image.

This makes it compatible with regular iTunes restores. For example, one can make a custom IPSW which doesn’t have a valid signature, run limera1n then restore with iTunes as usual. Why this is incredibly useful we will see a bit down below.

checkm8

After running the checkm8 exploit from ipwndfu, the payload inside usb_0xA1_2_arm64.S gets injected to the USB packet processing handler. It looks into the USB packets received by the host and when it finds special “magic” packets, it intercepts them and handles them, providing extra functionality to the host, which wouldn’t exist without it. All other non-“magic” USB packets are forwarded to and handled by the original USB handler function in the BootROM. With that, after running the checkm8 exploit you have the following capabilities:

• execute arbitrary functions
• perform memcpy
  • read memory
  • write memory
• perform memset

As before, the BootROM already provides the functionality to send data to the device (for uploading an image to boot). However, the ability to read back data no longer exists inside the BootROM. Here is where the payload comes in. It checks all incoming packets and if the packet is the “read back” request, it handles it itself otherwise forwards it to the original handler. But before reading back, it looks at the data that was sent in earlier requests. If it corresponds to the magic format, some action is performed before reading it back. Those actions can be to execute a function, run memcpy (implemented by the payload itself) or run memset. Not entirely sure why one would need a dedicated memset functionality, as the same effect can be achieved by just copying in data with memcpy.

The other two functionalities paired with the ability to read back data, again give us the same read/write/execute primitives as described earlier with limera1n.

You may have noticed that checkm8 itself does not actually provide a way to boot unsigned images at all, but it is not a big issue. By using the read/write/execute primitives available to us, we can just make the BootROM accept our images ourselves. There are multiple strategies to achieve running unsigned images. One of them is to patch BootROM to skip the function responsible for checking the signature.

One example of this can be found here in the rmsigchks_t8015.py file. The primitives exposed by checkm8 are used to first copy a page of the BootROM to SRAM, then patch that page to skip signature checks and finally modify the pagetables such that the new page is used rather than the original page in BootROM.

Now when you upload an img4 image which has a valid format but invalid signature, it is still accepted by the BootROM and thus loaded and executed the same as a genuine signed apple image.

Again, this can be used to create a custom IPSW which then can simply be restore with iTunes (or Finder nowadays).

The biggest advantage of this is that it is a universal approach compatible with all the regular tools out there (iTunes / irecovery / libimobiledevice etc) and most importantly you don’t need any exploit specific special handling. Once the device is in the “sigpatch”-mode, just give it to the tools which already know how to handle iOS images and you’re good to go.

usbliter8

Finally, lets move to the new usbliter8. As a reminder, in this blogpost we will solely focus on A12 and ignore all other chips and aspects of the exploit!

Similar to checkm8, after successfully running usbliter8 the USB handler is again replaced by a custom payload. You can find the exact implementation of handler.c here.

With this handler installed you have the following capabilities:

• demote
• boot raw image

Unlike the previous payloads, the capabilities here are very different and also much more limited. First, lets go through them step by step. “Demoting” a device essentially means that the JTAG/SWD debugging interface is activated which allows you to connect a debugger given you have special hardware and software. With that you can halt the CPU at any time, inspect it’s internal state and freely modify it. Furthermore, you can read and write any memory on the device. While at first glance it sounds like exactly what we want, please keep in mind that this an interface which requires both special hardware and special software. A regular USB cable does not work for this and even if it did, currently only apple internal software can make proper use of the interface as there is no publicly available tooling (for A13 at least). Thus, while definitely nice to see that it is possible and surely useful to some developers, this isn’t something everybody can use.

Moving on to the next primitive which is “booting raw image”. This allows us to boot custom code or a patched next stage bootloader (iBoot), however only if we first extract the raw binary from the img4 file.

This has several disadvantages compared to previous methods which boot a normal img4 image. First, it is not compatible with regular iTunes restore and thus by extension not compatible with existing software like idevicerestore etc. It means we need to have custom special software just booting the raw image first, then either re-implement all further steps or try to plug it into existing software mid-way. We have already seen public solutions like this which wrap around shell scripts and boot pre-prepared files using irecovery only. Sure, it works but it doesn’t scale well to the extent and quality that we require for our software.

The other downside of booting a raw image is that, for earlier iOS versions, we also need to decrypt the img4 before we can extract the raw binary. But remember, the payload doesn’t actually provide a way to use the AES engine and thus we can’t actually get the keys to decrypt certain iBoot versions and thus can’t get the raw binary and thus can’t boot it. Sure, we could rely on the keys being already public (which they are) or rely on someone to use JTAG to decrypt them for us. But let’s be real, this isn’t a very nice solution, is it?

Elcomsoft A12 BootROM sigpatches

To fix the aforementioned problems, we have modified the public usbliter8 exploit and are excited to discuss and publish our changes.

With our modifications, you will have the following capabilities after running the exploit and using our provided code:

• execute arbitrary functions
  • read memory
  • write memory
  • boot unsigned img4 images

Let’s review our modifications and discuss what can be done with it.

First, we replace the USB packet handler with an implementation similar to the one used by checkm8 (check out the file here). It implements the “read back” functionality and also allows executing arbitrary functions in BootROM with arbitrary arguments. As explained before, this lets us easily build read/write primitives giving us all the full set of read/write/execute primitives like we are used to have.

To demonstrate how to use them, we have modified ipwndfu such that it runs on python3 on the latest macOS 26 and we have also added support for our A12 payload. We have implemented the following functions of ipwndfu:

• --dump
• --hexdump
• --dump-rom
• --decrypt-gid

You can find our fork of ipwndfu_usbliter8 here.
First, flash our firmware of usbliter8 to a Waveshare RP2350 USB-A (firmware can be found here). Then put your A12 device in DFU mode, connect it to the pico and run the exploit and finally connect it to the mac. Then you can run for example python3 ./ipwndfu --hexdump=0x100000200,0x38 to read some memory.

WARNING:

• Our fork of ipwndfu is only meant to be used with usbliter8 devices
• All other functionality was not tested and probably DOES NOT WORK
• You can NOT use our fork of ipwndfu to run the checkm8 exploit

The other modification we have made is inside the exploit itself. As part of the exploit we add an additional entry to the page tables, which essentially allows us to modify the page tables itself later using our read/write/execute primitives. Without this modification it is not possible to alter the page tables at a later stage. It is an important part on which the following sigpatch implementation relies.

Finally, we want to be able to boot unsigned images as this is the most useful ability with a BootROM exploit. In our USB handler payload we have removed the ability to boot raw images, but instead we provide the following script to patch signature checks in BootROM similar to the t8015 checkm8 one we discussed earlier. You can find the script here.

By running this script the BootROM signature checks are disabled and afterwards you can boot an unsigned but properly formatted img4 image, which makes this method compatible with iTunes restores as well as all the existing tools like idevicerestore etc.

Why publish our changes?

Unlike previous exploits that can be run with software, the new usbliter8 exploit is different and requires special hardware. In addition, the “official” exploit lacks features that we need and provides a way of booting images that needs special care and is incompatible with many existing software. Our variant of the exploit fixes these issues and improves upon it, but due to the way those exploits work they are inherently incompatible with each other. For example, if someone has created software that relies on the device being exploited using the code published by Paradigm Shift, then that software will be not be working when our exploit was run instead. On the other hand, our software is incompatible with the unmodified exploit by Paradigm Shift.

So while our changes seem to be small, the effect they have on software following the exploit is big. Essentially, we now have (at least) two variants of the exploit that are inherently incompatible with each other – and especially with the software that comes after the exploit. To avoid having fragmentation, we are publishing our variant while usbliter8 tooling is still in the early stages and are hoping that the community will adopt our approach as the standard. We don’t want to see many different firmwares floating around all with exploit variants that are incompatible with each other.

So far we have only covered A12, but A12X, A12Z, A13 and S4/S5 are still missing proper read/write/execute primitives as well as BootROM sigpatches which allow booting img4 images.
We would love to see the community getting inspired on our ideas and research similar strategies for the remaining chips.

Conclusion

In this blogpost we have discussed the new usbliter8 exploit (focusing only on A12) and compared it with previous exploits like limera1n and checkm8. Furthermore, we have shared our improvements to the exploit in the form of read/write/execute primitives as well as A12 BootROM sigpatches, which lifts the A12 exploit on the same level as previous exploits in terms of provided capabilities and compatibilities with existing software.