Minus 0x20000 with Back Extend Erase

The first exploit I found, at around 4 AM last night, was the -0x20000 exploit. Just like the -0x400 exploit, but -0x20000. Go figure. I guess Apple thought big numbers were harder to guess. I was really pumped, hence the blog post. But that wasn't even half the battle.

Like I said in the "impossible" post, 0x3C0000 can't have a valid secpack to allow booting. I spent the next 16 hours finding a way to do this. I can already write unsigned to the main fw section, all I need is a way to erase the secpack. My first idea was the eeprom secpack; upload the eeprom, endpack it, and the secpack is erased because the eeprom is "clean". But you can't upload a eeprom secpack until the 0x3C0000 is blank. My next idea was that the bl must erase the secpack before writing it. So a simple timing attack should do it. It turns out that no secpacks, even the same one, will write.

I finally found a working exploit about 23 hours into my search for the software unlock. The explicit addresses 0xA03D0000-0xA03F0000 will always erase. This exploit relied on two things, the secaddrs are copied before the secpack is validated(stupid), and the erase command extends the range to whatever is in the secpack. So I tell it to erase 0xA03D0000-0xA03F0000, the erase command sees 0xA03C0000 to 0xA03F0000 in the secpack; BOOM secpack erased.

The third minor concern was the full range check of 1.1.3. So use 1.1.2 :) This allows full unsigned code execution, it is a relatively simple matter of patching the bootloader to skip the range check. And while you are at it, patch the bootloader to validate all tokens. IPSF style unlock w/o touching the seczone.