Jailbreak (S5L8720x)

The iPod Touch 2G, which is the first of the iPhone/iPhone3G/iPodTouch family to use a new processor, the S5L8720x. It is possible that future devices will also use this but for now it is just the iPod Touch 2G. Here is a mini "manifesto" to get you caught up to speed. Please use the "Discussion" page for any type of brainstorming or ideas, and limit this page itself to actual, solid, information.

Summary

With a proper chain of trust, this ones going to be hard.

We assume the DFU is the WTF 0x1227, and therefore not vulnerable to the Pwnage 2.0 attack.

So lets post whats been tried and what doesn't work. It's only a matter of time before the 3G has this DFU. Apple revved the silicon for the S5L and once the old stocks are gone, no more jailbreaks.

What is new?

DFU 2.0

Unlike the iPhone, iPhone3G, and iPod Touch, the iPod Touch 2G has a new bootrom. It is based off of WTF2.0, and is much more secure than the previous bootrom. It boils down to 3 things:

• Pwnage 2: It should go without saying, but the iPod Touch 2G is no longer vulnerable to the stack overflow that Pwnage 2 relied on.
• No 8900 Support: It does not have support for 8900 files any longer. So you cannot just cheat by sending a 1.1.4 iBoot and then using the diags exploit to strap a patched one ;-)
• LLB Signature Check: This is the biggest of them all. Now, when firmware images are flashed to NOR, they are left entirely intact in their containers. This gives Apple the upper hand at making things much more secure, for a few reasons. First and foremost, they can properly signature check LLB, so the classic "Pwnage" exploit in which the device would happily run any LLB in NOR without first signature checking it, so if anyone found a hack to flash the NOR with custom files, then they would be able to "Pwn". No longer is that true though, since the images are intact in NOR, the new bootrom can do proper signature checking. The second reason that this gives Apple the upper hand on things is because they do not really have to have any code in the kernel to utilize the GID key for anything, and I have not personally looked into if they have done this or not, because the iPod Touch 2G kernel is encrypted (I will get into this in the next section), but theoretically they could just remove the code for it, thereby making it so the only way to decrypt KBAGs is by using openiboot, code that calls the AES_Decrypt(); function in iBoot, or something similar. Even worse, they now have less to worry about, because even if there was a bug in the AppleImage3NORAccess routine in the kernel, or an iBoot hack, or something like that, to reflash the NOR, it would be no use because the signature check that the bootrom performs on LLB will just fail.

Firmware Encryption

Apple did not even want people having the chance to reverse any of the code on the iPod Touch 2G, so they did the following:

• Gave iPod Touch 2G firmwares a different build number: Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod Touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod Touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the iPhone, iPhone3G, and iPod Touch 2G firmwares now.
• New GID key: There is now a new group ID key in the device, so unlike with previous devices, you cannot just decrypt the KBAG of the iPod Touch 2G firmware files on a Pwned iPhone or something. It must be decrypted on the device itself, and that cannot happen unless someone finds a way to run unsigned code.

What we need

Because of the new circumstances, it will not be as easy as finding a hack to Pwn any of the older devices, and even that wasn't easy :P

Unsigned Code (at iBoot level)

A viable first goal would be to get unsigned code running at iBoot level. This way, we could tinker around with many things, such as:

• Decrypting firmware files: We can recycle the code geohotz wrote in the summer of 2008 that called iBoot's AES function to decrypt KBAGs. This way, we could examine iBoot for any other vulnerabilities, the kernel, as there is maybe a 1% chance that there could possibly be a flaw in the codesign mechanism, DeviceTree, so we can make more sense of stuff going on in iBoot because we know the proper hardware addresses, and more.
• Testing hax: Since the end goal is to find an exploit that will trick the bootrom into saying the LLB signature is valid, when it is not, then having the ability to run unsigned code is a great advantage. This is because we could write code to call different internal functions for the signature / cert / etc checking routines, and to use 'printf' and such that is built into iBoot to report status messages, which would be great for exploit development. Hell, I believe there is even code already in iBoot to dump the stack frame, so there is another useful thing already there for us.
• Dumping the "true" bootrom: I have personally resorted to just examining WTF2.0, since that is technically what the new bootrom is. But there is a catch. Unless every worker in the factory is superman, I strongly doubt that Apple was able to get 2.1 iBoot code into the bootrom. As MuscleNerd said when I was talking to him a few months ago, it is not cheap to replace the bootrom like this, so if we are lucky it may have some exploitable stuff that Apple fixed for WTF2.0 and iBoot, but did not fix in the bootrom, since they would have to be insane to replace the bootrom with new code a second time because of one exploit that they probably would not expect people to see in the first place, since dumping the bootrom is not something that can be done without running unsigned code. Something that can somewhat boost the validity of my theory is that in the 1.2 (2.0 beta 1) lockdownd and higher, there was a check to see if the device model was "iPhone1,2" or "iPod2,1". If true, then the device would automatically activate. Knowing this, it is probably safe to assume that this is when the testing period for the iPod Touch 2G was. Now, to actually say something directly about this topic, I think Apple made a weak attempt to disallow this. The bootrom is mapped to 0x22000000 now, instead of 0x20000000. And before you ask, iBoot no longer uses it as a library for PKE stuff, it now has that stuff built in, so that is no longer a problem either. Anyway, LLB also maps itself to 0x22000000, therefore mapping itself over where the bootrom code was, and if you used mdb or mr to read what is at that location, LLB would be there. Luckily, iBoot maps itself to 0x18000000, so a solution to this issue would be to just restore to an IPSW with an invalid LLB (so that we can 100% confirm that we are in real, true, bootrom DFU, and not the stupid pseudo-DFU that LLB has built in), and then send simply send it iBoot with iRecovery. iBoot will map itself to 0x18000000, and we can use whatever unsigned code exploit is found to strap an iBoot with permissions/sigcheck/rangecheck patched, thereby allowing us to read what is at 0x22000000.
• OpeniBoot: Not that it a priority in the jailbreak, but it would definitely help out the iPhone Linux folks, since they can decrypt iBoot and spot the differences, as well as DeviceTree for any new hardware / GPIO addresses. On a plus side for the jailbreak, it would be much easier to have a working OpeniBoot to use for experimentation versus needing to write ARM code to call different iBoot functions.

Firmware Parsing Flaw

This is the end goal. Just running unsigned code is not enough, because the bootrom will signature check LLB at every boot. We need an exploit that will trick the bootrom into thinking a patched LLB is a valid, Apple signed LLB. This does sound like something very hard, but it is a flexible for requirement. For example, if the bootrom was still vulnerable to the Pwnage2 exploit, it would work in this case. At every boot, the bootrom would start parsing LLB, it would get to the place where it copies the entire cert to the stack, then the exploit itself tacked onto LLB would make the routine return 1 (success). Unfortunately, that explit is gone. But my point is the flexibility of it; The exploit would not specifically have to actually trick the bootrom into thinking it is valid, but rather, it could force it into saying it is valid via the forced return(1);

Chronic's Notes

I have a weird way of keeping things in order. One of them is, when I take notes / document iPod Touch 2G stuff, I do it in TextEdit then commit it via SVN to the chronicdev google code page. If you are interested in any specific topics, such as how the iBoot flags work, you can read about it all here

Anything else?

If there are any other questions, anything I missed, any kind of brainstorming, anything like that, post it on the discussion page and I will be sure to update this article with the answer.

-chronic