- I'm curious what this will lead to, both security wise and jailbreak hobbyist wise. I saw this overview: https://www.reddit.com/r/jailbreak/comments/1ua58xd/usbliter... which mentions that it won't let an attacker gain full access to iOS on a passworded device without another exploit:
> 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.
- This is awesome news! It isn't a jailbreak in and of itself, but it is the first step.
Right now we only have a reliable jailbreak (checkm8) for up to iOS 18 (and that's only thanks to one iPad model). Some app developers are pretty aggressive about dropping support for older iOS versions.
This affects iPhone XR, XS, 11, SE 2nd gen, and a smattering of iPads. Many of these devices got the iOS 27 beta and will likely see future iOS versions for at least another year or two.
Edit: here's the affected iPads:
* iPad Pro 11" (gen 1-2)
* iPad Pro 12.9" (gen 3-4)
* iPad mini (gen 5)
* iPad Air (gen 3)
* iPad (gen 8-9)
- Also great new for Cellebrite?
- Not unless they also have a SEP exploit.
- Reboot your phone after the feds have it before you unlock it again
- Once the feds have the phone, they aren't going to allow him to touch it, much less reboot it.
- They have to reboot it to use a bootloader exploit. Reboot it again after you get it back to erase whatever they did.
- I realized they might have added a fake reboot menu. So either use the exploit yourself to check it's the real bootloader (no realistic chance the FBI made a fake bootloader exploit in the fake reboot menu) or let the battery run out or remove it.
- All Apple mobile devices I've used have had some form of low-level forced reboot method, akin to holding down your PC's power button. Though I can't say whether it's also something one could subvert with a BootROM exploit.
https://support.apple.com/guide/iphone/force-restart-iphone-...
- Nobody is going to add a fake reboot menu
- Or they wouldn’t have, until they saw this thread, just for the sport
- seems like a huge amount of effort when they could simply give you a bugged phone of the same model that automatically transmits the passcode to them when you enter it. Newest ios are usually vulnerable to Cellebrite anyways.
- I first thought of SecuROM, a CD/DVD copy protection scheme applied to computer game discs: https://en.wikipedia.org/wiki/SecuROM
- Time for my annual check, and yep, gamecopyworld.com is still kickin' with roughly the same theme since 1998
- A DRM scheme that often failed to work and had a limit to the amount of installs.
- Ohhhh this is interesting!!!!! I really miss the glory days of jailbreaking, it just unlocked so many handy, fun, and cool stuff. From running webservers to speeding up the terribly slow animations.
- ...or adding system-wide Copy and Paste when the iPhone first launched without it...
- ouch. imagine going back in time and tell someone that in your own pocket computers, it would be a forbidden art to spend 2min to code, and be allowed to run, a copy and paste application.
(well, to be honest this is a bad example to show the system is closed, because copy and paste was difficult on linux too during wayland)
- Where did they get the code for SecureROM? Also, why is the ROM code so large, I thought the BootROM should contain the minimal code to boot from flash memory and that's all.
- Many are dumped publicly at https://securerom.fun/
Some were dumped via known exploits, but I don't know how A12/A13 were dumped in the first place. I'd guess someone got code exec via fault injection and dumped it out that way, or perhaps just a privately known vuln.
iBoot source code has also been leaked, in the past.
- Do you want to break out a flash programmer and disassemble the entire smartphone whenever someone bricks it via firmware?
If not, you need to have unbrick-capable DFU straight in BootROM.
Which typically means: ROM code that carries an entire USB stack, as well as means of validating and booting executables from the USB stack.
An alternative would be to have BootROM recovery off MicroSD, but, iPhone lmao. They didn't chase the trend of "no expandable storage" - they created it.
- Sounds like it’s a low level hardware/firmware hole that can’t be patched.
- The articles have been unclear about this: Does this let attackers unlock a stolen iphone, for example, or is this just about jailbreaking a phone that you own and control.
- Since this can only underflow and some written bits are not attacker-chosen, does this not imply that the patchable part of the software could reliably detect this just in time and panic on suspected USB DMA corruption? Where is the catch?
- The exploit happens before any patchable software is running, it's not called ROM for nothing.
- The exploit grants arbitrary code execution, it can just fix up the telltale signs of the USB DMA corruption before jumping to an updatable part of the boot flow
- Ah, the exploit is all done before that!
- > The DesignWare USB controller stores up to three consecutive Setup packets in memory.
> Upon receiving a fourth Setup transaction, the DMA base address gets reset to its starting position before writing, akin to a ring buffer mechanism.
> After writing each received packet, the controller increments DOEPDMA by the size of data written. The reset operation is implemented by decrementing DOEPDMA by 24.
> The core issue arises because the controller also accepts smaller packets (though always stores in 4-byte chunks).
> Since the pointer increment does not match the fixed decrement amount, we end up with a buffer underflow primitive in 12-byte steps.
so the problem is directly in the hardware, not in driver
what kind of defense would work against such bugs?
====
wait, am I understanding it right that DMA access was given directly to the stack??
- On most modern Apple SoCs, including these two, there's an IOMMU dedicated to the USB complex (called the USB DART, perhaps DMA Address Remapping Table).
However, Boot ROM on these two chips does not program it; Apple probably felt that it was an unnecessary technical risk to do so. The Boot ROM code was well-verified and unlikely to contain bugs like buffer overflows. But nobody expected a hardware bug :)
- The DMA buffer points to the heap.
The USB controller has access to it, but it only increments it and decrements.
By sending multiple packets that are smaller than typical, we can trick the USB controller to decrement the base pointer by more than it should, getting to underflow.
It so happens that on A12, the DMA buffer is after the USB task stack, so getting it to decrement by enough will get it to point to the task stack, where we can then write to LR and control where some function on the stack will eventually return to.
- [dead]
- Imagine four balls on the edge of a cliff.
Say a direct copy of the ball nearest the cliff is sent to the back of the line of balls and takes the place of the first ball. The formerly first ball becomes the second, the second becomes the third, and the fourth falls off the cliff.
DOEPDMA works the same way.
