11246unlock, good enough for the prize

OMG Updated to be more idiot proof and the winner of the 11246unlock contest.

Full software unlock of 1.1.2; the impossible(or at least I said so) Here it is; instructions are in the package. I guess I really am becoming a good reverser ;-)

ZiPhone is a conglomerate of others work. It copies a new fstab for write access to system, runs iPatcher to patch lockdownd, copies installer, and runs my gunlock to unlock. It is a good way to restore from most problems, and true jailbreak 1.1.3 My program is just patched to change the default IMEI(0049) to the user entered IMEI; although I would strongly advise against changing your IMEI. The exploit he uses runs an unsigned ramdisk with all these programs. This is the best way to jailbreak; and I had been imagining this for a long time, I just didn't have the exploit. This ramdisk exploit was stolen from the dev team, so be careful who you give credit to.

Yes, the impossible has been done. This has absolutely *nothing* to do with JerrySim or any elite/dev/zibri etc project. I'll start with a little story. Yesterday I was really pissed off. So I figured I'd channel my anger toward something productive; I don't know, something like a 1.1.2 software unlock. I knew the odds were against me, but I'd figured I try anyway. At about 1 last night, I hardware "upgraded" a 3.9 phone to 4.6 with the bootrom locations blank, the read command patched to work, and a 0x102 read arbitrary memory command.

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.

So, thats 24hrs to a software unlock; with about 3hrs of sleep in two segments. I am disappointed in the elite/dev team for not finding this; or even looking here. I know not everyone in elite/dev is so closed, and I feel bad for those people. Why don't we all just share everything? Apple will patch it anyway. They always have the upper hand. And whetever happened to the dev wiki?

If you were giving money to the "dev team" for this software unlock, why not give it to the guy who actually found the exploits and exploited them?