Posted by on under jailbreak, iphone, phe, dev team, rk, itunes | 
Well, the iPhone Dev Team has done it again. A working jailbreak for 1.1.3 is finally here.
STATEMENT OF RISK
As all upgrades are risky, this one is doubly so. You may have to restore your phone using iTunes and start again if it fails. Make sure to back up first!
Let's continue
This jailbreak, like the 1.1.2 jailbreak, comes as an upgrade. This means you need to have a 1.1.1 or 1.1.2 jailbroken phone already, before you can begin.
QUESTIONS? See the FAQ
Official Jailbreak release works for iPod Touch, and is easier to do. Go here for that.
Update - unlocked phones appear to remain unlocked and work properly after the update, according to scattered reports.
MAC...
Read the rest of this post
Tagi: jailbreak, iphone, phe, dev team, rk, itunes
Posted by George Hotz on under bootrom, gunlock, reverser, half the battle, fstab, big numbers, finding a way, full software, phe, dev team, fw, anger, odds, elite, idiot proof, memory |
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?
Tagi: bootrom, gunlock, reverser, half the battle, fstab, big numbers, finding a way, full software, phe, dev team, fw, anger, odds, elite, idiot proof, memory
Posted by George Hotz on under gizmodo, phes, recovery mode, iphone, possiblity, iboot, endpoint, dev team, 3g, bricks, date time, hack, protocol, fear, beta, truth |
So I read
this on gizmodo. Here's the truth...
Post beta 4, the ramdisk hack stopped working. Sorry Zibri, guess you'll have to steal another exploit. They also changed the recovery mode USB protocol to use the control endpoint to send commands.
The possiblity of unlocking, which is very distinct from jailbreaking, is based entirely on the baseband bootloader. Apple doesn't appear to upgrade the bootloader on phones in the field, probably for fear of bricks. So any old iPhones out there today, regardless of version, can be unlocked.
The iPhone 3G uses a different bootloader, which I believe there aren't any known exploits in yet. So no unlock.
There is a known exploit in iBoot, on both the old and 3G iPhones. The "the specific date/time is not firm yet" pwnage tool will leverage it to jailbreak all 2.0 software iPhones, 3G and otherwise. Dev team, that date better be soon or I might just have to release
yiPhone. The iBoot exploit is yours, use it. You wouldn't want a repeat of ZiPhone now...
Tagi: gizmodo, phes, recovery mode, iphone, possiblity, iboot, endpoint, dev team, 3g, bricks, date time, hack, protocol, fear, beta, truth
Posted by George Hotz on under iphe, bootrom, dev team, great news, wtf, 3g, many things |
Congrats to the
dev team for finding the ultimate exploit in the S5L. We may not agree on many things, but I certainly respect your skills.
Pwnage uses an incredible exploit actually at the DFU level, which means it's locked into the hardware. I have managed to reproduce the exploit, but in no way understand it. I can't wait for your explanation. This is akin to finding a soft-exploitable exploit in the bootrom of the baseband.
Apple attempted to cover it up by having the new WTF downloaded as soon as iTunes sees the phone(0x1227) vs DFU(0x1222). I thought they might be covering an exploit but then just figured they didn't want the iBoots unencrypted. Good thing dev looked closer.
Also it's unbelievable they left the LLB unsigchecked in the 3G. They have all the code in the DFU to sig check, they just don't call it.
This is also great news for iphonelinux. We'll be able to boot code without the need for any of Apple's copyrighted software(and maybe without their cert).
Today is a good day for iPhone
Tagi: iphe, bootrom, dev team, great news, wtf, 3g, many things
Posted by George Hotz on under iphe, phes, iphone, dmg, nice job, piece of cake, dev team, heap, cbc, sdk, aes, garbage, signatures, hack, certificates |
Strip the first 0x800 bytes from your >= 1.1.1 firmware ramdisk
Run:
openssl enc -d -in ramdisk.dmg -out de.dmg -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0
Ignore the error. Then there will be some garbage, signatures and certificates, at the end of the file. Remove it and mount your ramdisk.
Why would this key be published without any explanation of what it is? Apple knows what it is, not telling us how to use it doesn't serve a purpose for anyone. I don't know exactly what this key is or where it came from. But I do know it decrypts ramdisks :)
Nice job to Zibri, the dev team, and whoever owns Austin Heap for finding this key, I'd love to see the hack used. Sadly this will not help us unlock BL 4.6 phones, or sign our own SDK apps; sign anything for that matter. But hopefully this key is deeply embedded in the iPhone, and decrypting all future ramdisks will be a piece of cake.
Tagi: iphe, phes, iphone, dmg, nice job, piece of cake, dev team, heap, cbc, sdk, aes, garbage, signatures, hack, certificates
