Chronic Dev Blog

I originally posted this on the Google Code page, which is a page for people more informed on the technical stuff, but I think I will post it here too so that everyone can someone be kept informed.

Introduction
On Februrary 27, 2008, the iPhone Dev Team demonstrated that they had the ability to load a custom recovery logo to the iPhone, bypassing signature checks. Then, two days later, they demonstrated that they could restore to a custom IPSW file. After that, they published some information on how the “Pwnage” exploit works. then finally, a full presentation of the tool.

It was an amazing exploit, so low level that it could not be fixed as it was in the hardware. The “Pwnage” exploit relied on the fact that bootrom does not signature check LLB, breaking the chain of trust, because that would mean that you could patch the LLB signature check so that it would accept a patched iBoot, and that iBoot will accept a patched kernel, and so on. Or, the exploit in their words: “Pwnage exploits a bad chain of trust in the boot sequence of the S5L8900 device. The boot sequence includes LLB and iBoot modules which are stored in device NOR flash and are typically encrypted (as of 1.1.x). However, they are not signed with RSA signature at that point, because the 8900 container is dropped away before the file is written to NOR flash. Pwnage exploits this vulnerability”. Now, you still had to find a way to write to the NOR unsigned, but once that was done, you were golden.

Now, this applied to the iPhone, the iPod Touch, and even the iPhone 3G. But, the iPod Touch 2G is a different story.

What is the difference?
The iPod Touch 2G has WTF 2.0, or what we dubbed as “DFU 2.0″, burned into the bootrom. It can no longer understand IMG2 files, so no sending old files and using old exploits, or using the 8900 parsing bug. Now, it can understand IMG3 files. Here is the kicker: IMG3 files are written to NOR the way they are right now, as in, with the container and everything. This means that the bootrom exploit that allowed Pwnage v1.0 and Pwnage v2.0 to work is gone, because now the bootrom will signature check LLB and refuse to boot it if it is patched. If the LLB is not patched, then it will definitely not boot a patched iBoot, and if iBoot is patched, it will definitely not boot a patched kernel, and if the kernel is not patched, then it will definitely not boot any unsigned Applications such as Cydia or Installer because of codesign checks.

Even if we are somehow able to decrypt the firmware files and patch them, then re-encrypt them, it is still no good. The bootrom will be able to now see, “oh, this LLB is patched, I refuse to boot it!”, and then the device just goes straight to DFU mode.

Oh no! I can’t haz jailbreak?!
Well, a jailbreak is still possible, The boot sequence’s chain of trust is much tighter now, or rather, it is what it probably should have been in the first place. Anyway, even though the bootrom signature checks LLB, and there is no way around that, there may be some kind of bug in the signature checking routine, as with the 8900 routine. Another possibility that would probably not last long is a muchmuch higher level exploit, one in the kernel, that would allow the codesign mechanism to be tricked into running homebrew code.

Basically now, we may need two exploits, depending on what direction is taken. You can almost say we are ‘back to square one’ when you think about the stance of what we know compared to the other devices, because, we cannot decrypt the new firmware kbags, we cannot Pwn with the classic meaning of it anymore, it is a new processor. iRecovery is a great start because we can freely experiment by having the ability to upload files and communicate with iBoot.

Now, instead of just needing an exploit to get patched files into the NOR, we will need either 2 exploits, or one really good one. The two would be one that allows unsigned code to run, so we can strap a patched iBoot and decrypt and patch firmware files, then run a ramdisk to flash it to NOR, then another exploit that will allow a patched LLB to pass the signature check from the bootrom. Fortunately, the beforementioned two, if found, will probably be able to be combined into ‘one really good exploit’, because if it is in the parsing code like the Pwnage2 stack overflow was, then it can be used to pass a patched iBoot so we can Pwn, and so that DFU will pass a patched LLB as authentic. It is going to be a much bigger challenge than anticipated, but I am up for it

In essence, this could be thought of as kind of a step forward, because we now know what needs to be done, versus finding out later down the road that an iBoot exploit to just run unsigned code is only the beginning.