Ok, here is where we stand right now.
ZiPhone seems to be the tool a lot of people are using. What it does is boot an unsigned ramdisk with a script to jailbreak, activate, and unlock. If you would like to view the ramdisk yourself, cut the first 0xCC2000 from the dat file and mount it as a dmg. The script is in /etc/profile. Also, Zibri, patch out the bootloader check from gunlock, it'll work with 3.9
ZiPhone is a wrapper for gunlock, which means with 4.6, it currently only unlocks 4.02.13 In order to unlock 4.03.13, right now you need bootloader 3.9
gbootloader will erase and downgrade your bootloader from software. I have checks in the program to prevent a bootloader without the bootrom locations blank from being uploaded, but if used properly, it will downgrade to 3.9, allowing 4.03.13 to be used.
4.6_GEOMOD is a modified bootloader I have with all secpack stuff patched out, hard coded IPSF style unlock(tokens always validate), full anywhere write access, no startup sig checks, and the bootrom locations blank. But the only 4.6 phone I have got bricked while I was trying to restore the seczone, and my bootloader software hack doesn't seem to work in 3.9 I guess I'll have to hw upgrade. Laziness...
Another problem comes with the release of the modified bootloader. It is copyrighted, and the patches are decently complex. What I'd really like to see is an open source, very well coded(the current compiler is crap), bootloader. Say written in assembly. I believe a full bootloader with all the functionality(minus the security) can fit in under 0x1000 bytes. It should continue to work with bbupdater, but have the crypto state machine fixed to validate everything possible. Maybe I'll get around to writing it. This is the ultimate in baseband hacks, and will put every other hack to rest, once you get the new bootloader on there. I'm sick of patching and trying to understand other peoples(badly written) code, when I can just write my own.
Tuesday, February 12, 2008
A look at things to come...
Done in software from 4.6
Update: I just bricked a phone, and when I say bricked, I mean bricked. These bootloader hacks are dangerous. I made a really stupid typo, and it probably cost me a phone. When I go home, I will look at the phones I have in pieces; maybe there is some backdoor I overlooked. Maybe this is a sign I should put down the iPhone.
I am working on a loader for 4.03.13 that will run and unlock post bootloader. This is the better way to unlock 1.1.3
Ok, since I've gotten requests for it, the download link to the bootloader downgrader is at the end of this paragraph. Thanks to the dev team for the WP# discovery. I didn't brick my phone with this, I bricked my phone by typing 0 instead of 3FA000, but use extreme caution. I haven't included a patched bootloader, hopefully if you are using this, you have the skills to patch a bootloader. Here, don't say I didn't warn you.
Friday, February 8, 2008
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?
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?
Thursday, February 7, 2008
Monday, February 4, 2008
1.1.3 Unlock and another 3.9 exploit
I cleaned up the token generator code and wrote a shell script to do the IPSF style unlock. I believe that this is the best unlock for 3.9, since we know Apple doesn't update the bootloader. Here is the script and some support files, including a new version of norz that fixes the "Waiting for data..." problem. This unlock should be restore, and *hopefully* upgrade resistant. Thanks to elite for the virginizor, dev for iUnlock, PmgR for getting lip to compile on the iPhone, and gray for his initial crypto work. It works on 04.03.13, the baseband of 1.1.3
The unlock command needs to be rerun on restart. Could someone patch lockdownd to send 'AT+CLCK="PN",0,"00000000"' on startup?
Also I finally found the download exploit IPSF uses. If the last four bytes in the SHA are 00, the endpack command, which writes 0xA0020000-0xA0020400, always validates. Get the IPSF hlloader and check it out.
The unlock command needs to be rerun on restart. Could someone patch lockdownd to send 'AT+CLCK="PN",0,"00000000"' on startup?
Also I finally found the download exploit IPSF uses. If the last four bytes in the SHA are 00, the endpack command, which writes 0xA0020000-0xA0020400, always validates. Get the IPSF hlloader and check it out.
Subscribe to:
Posts (Atom)
