TIL SecureROM != SecuROM. I came to this post anticipating a nostalgic trip about some ancient DRM and a stupidly simple way to break it. Got confused when it was about Apple phone OS.
Same.
The One Weird Trick SecureROM Hates [pdf]
11–20 of 23 posts
Re: The One Weird Trick SecureROM Hates [pdf]
#12Wow, it's really cool to read how things like this happen. While we're here, is there anything I can use to remove the alphanumeric passcode from an iPad 4 (A6X chipset, no Secure Enclave) that I've forgotten the password to?
There's a device called "IP box" which may be able to do that, it's not cheap but a mobile repair/unlocking store would probably have one.
How does it work?
Re: The One Weird Trick SecureROM Hates [pdf]
#13Earlier quoted context omitted.
USB stack is because one of the rom bootloader’s primary functions is DFU mode so that you can reflash a bricked device.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
Either all the senior engineers and PhDs working for Apple are idiots, or it’s harder than you think.
This same heuristic can be applied all across the HN front page with good results.
Re: The One Weird Trick SecureROM Hates [pdf]
#14Earlier quoted context omitted.
There's a device called "IP box" which may be able to do that, it's not cheap but a mobile repair/unlocking store would probably have one.
How does it work?
For a 4 digit unlock code, the device would enter them sequentially starting from 0000 and ending at 9999 [1]. Because there is a delay of 6 seconds between each attempt (on iOS 7.xx) it would take just over 16 and a half hours to try all codes.
[1] https://www.fonefunshop.com/ip-box-iphone-password-unlock-to...
Re: The One Weird Trick SecureROM Hates [pdf]
#15Earlier quoted context omitted.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
Either all the senior engineers and PhDs working for Apple are idiots, or it’s harder than you think. This same heuristic can be applied all across the HN front page with good results.
The costs just outweigh the benefits.
Nothing to do with idiot engineers or the task being hard. They could be idiots _and_ the task easy. Some things just don't need to be done.
Re: The One Weird Trick SecureROM Hates [pdf]
#16Earlier quoted context omitted.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
Either all the senior engineers and PhDs working for Apple are idiots, or it’s harder than you think. This same heuristic can be applied all across the HN front page with good results.
I'm sure the choice was made by a small team back when iPhone was still a carefully guarded secret inside the company, and it's stuck around since then.
Re: The One Weird Trick SecureROM Hates [pdf]
#17Earlier quoted context omitted.
USB stack is because one of the rom bootloader’s primary functions is DFU mode so that you can reflash a bricked device.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
Not the best, but not the worst. It's pretty simple as it is.
Re: The One Weird Trick SecureROM Hates [pdf]
#18Earlier quoted context omitted.
USB stack is because one of the rom bootloader’s primary functions is DFU mode so that you can reflash a bricked device.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
It's entirely possible that it was a "good enough for now" decision, and that the next bootrom will include additional hardening based on this attack.
As has been well documented, while Apple the organization may have practically unlimited resources, specific teams within Apple do not, so a lot of stuff is sort of "if it ain't broke" mode until the CADT model kicks in and they do a total rewrite and close all the old bugs.
Re: The One Weird Trick SecureROM Hates [pdf]
#19Earlier quoted context omitted.
How does it work?
For a 4 digit unlock code, the device would enter them sequentially starting from 0000 and ending at 9999 [1]. Because there is a delay of 6 seconds between each attempt (on iOS 7.xx) it would take just over 16 and a half hours to try all codes. [1] https://www.fonefunshop.com/ip-box-iphone-password-unlock-to...
Right now with these tools you are just playing passcode roulette to recover your device if you forgot the code and you enabled factory wipe after N tries.
Out of these retries, at least 1/N correct passcode attempts are needed, so such tools are close to useless if your care about retrieving your data with factory wipe enabled.
Re: The One Weird Trick SecureROM Hates [pdf]
#20Earlier quoted context omitted.
A heap isn't needed, it is just super helpful. Also DFU is not the world's best protocol, I am surprised Apple didn't just roll their own. It isn't exactly hard to replace DFU with something simpler that gets the job done.
Either all the senior engineers and PhDs working for Apple are idiots, or it’s harder than you think. This same heuristic can be applied all across the HN front page with good results.
> Either all the senior engineers and PhDs working for Apple are idiots, or it’s harder than you think.
I was part of a team that rolled our own firmware update mechanism at Microsoft . (I didn't work on the replacement myself, the engineer sitting next to me did.)
And deeply embedded USB stacks w/o a heap aren't exactly uncommon, considering malloc is forbidden in a large % of firmware.