11246unlock, good enough for the prize

寂夜清风

http://iphonejtag.blogspot.com/2 ... ough-for-prize.html
! W( Y1 z. d6 j! \
) ]7 p" t. P  W; D7 o, K' i  d

OMG NOW supports 1.1.3 TOO. But use the 112 fls.

/ D7 V& t4 |+ z, CFull 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 ;-)

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.

% g3 }- U+ j0 D2 _4 E% vThe 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.
8 c  I* z2 j8 M3 I
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.
! l$ U; `2 ^' ~* z/ p  }9 g
) N2 d' I( K' C6 V3 Q$ lI finally found a working exploit about 23 hours into my search for the software unlock. The explict 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.
2 F& I/ z( K9 }1 \% ]: y2 x
: I* G1 R) _% rThe 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?