Jailbreak (S5L8720x)

The iPod touch (2nd generation) is the only device that uses a new processor, the S5L8720x. 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 DFU 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, iPhone 3G and iPod touch, the iPod touch (2nd generation) has a new bootrom. It is based off of WTF 2.0, and is much more secure than the previous bootrom. It boils down to 3 things:

• Pwnage 2.0: It should go without saying, but the iPod touch (2nd generation) is no longer vulnerable to the stack overflow that Pwnage 2.0 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 (2nd generation) 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 (2nd generation), so they did the following:

• Gave iPod touch (2nd generation) 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 (2nd generation) firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch (2nd generation) 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, iPhone 3G, and iPod touch 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 (2nd generation) 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.

Small Things

In the 1.1.x days, we can all agree that Apple probably did not expect people to be pulling off things such as Pwnage. Now that they have seen the possibilities though, they have implemented all kinds of small extra things to be more secure. One example of this is that now iBoot/iBEC/iBSS now does not jump to the secure bootloader to perform access the RSA accelerator, but now has all the logic coded in (as it probably should have been in the first place). In essence this does not really do much, but, for example, if there was an exploit in the PKE logic and Apple realized it something like a few days before release, then they can just fix it in iBoot/iBEC/iBSS instead of having to reball a new bootrom. People would not really be able to find out that the exploit even exists, either, since they need to be able to run unsigned code in the first place to dump the bootrom.

Another example of a small thing they have done is keeping the IMG3 containers intact when flashed to NOR, not only for the obvious reason of allowing a bootrom signature check, but also because during a restore, the kernel technically will not require access to the GID Key to decrypt the firmware file and flash it to the NOR, since again, all of the container remains intact, and the file is flashed as it is.

What will not work

Creating a custom IPSW

The level of difficulty (aka, zero) of PwnageTool often confuses some people that it is as easy as just making a custom IPSW. This is why that will not work.

• Firmware = Encrypted: The rootfs, ramdisks, iBoot, LLB, kernel, and others are all encrypted. Because we cannot run unsigned code, which we need to be able to do in order to utilize the AES engine, we cannot decrypt any of this.

• Integrity Checks: Obviously Apple would not let people have the ability to just load unsigned code willy-nilly. They have integrity checks in place to assure that the firmware files were legitimately signed by Apple. Thus, an exploit is needed to make this work. Pwnage used tricks to flash the NOR unsigned, but that will not help as described above, the bootrom sigcheck would declare it to be invalid. Something like the Pwnage2 stack overflow is needed, in which devteam made the sigcheck routine return success, even though the file was patched.

App Store-related

People have asked about doing a lot of things related to App Store applications in order to get the device jailbroken. There have been suggestions such as making a faux AppStore server, hiding a backdoor in an innocent looking game and getting it approved, and more. Now, there are a few problems with this:

• No root access: AppStore applications cannot run as root. The Data partition, which is where applications are stored, is mounted with the 'nosuid' flag, because they do not want to allow any applications to be able to run as root. If we cannot run as root, then we cannot really do much.
• MISValidateSignature(): Whenever an application is being installed, whether it is from XCode, iTunes, or the on-device AppStore, it uses the MobileApplicationInstall(); routin in the MobileInstallation framework. Now, this calls a function in libmis.dylib (a library for many lowev level MobileInstallation stuff) called MISValidateSignature(); which is the reason taht people need to patch MobileInstallation to always pretend this check succeeded.
• Codesign: Assuming the above two things had flaws in them that allowed them to be bypassed, codesign would kill any applications not signed by Apple. So even if you were using some kind of backdoor in an AppStore app, this means that you still cannot execute any unsigned applications such as Cydia to run, and that is assuming you wre even able to find a way to mount /dev/disk0s1 read-write and deploy Cydia (since /dev is not accessible from the sandbox, and because the Data partition is mounted with the nodev flag, disallowing trickery such as that used in the 1.1.1 and 1.1.2 jailbreaks that allowed /dev/disk0s1 to symlinked and patched via different exploits available at the type (toc2rta tiff exploit in 1.1.1, soft symlink hack in 1.1.1, hard link hack in 1.1.2).

"Just making an Cydia / Installer IPA"

People see this as different than the above, but it is not. No matter what way you think of it, the answer is no. It will not work. Period.

A Userland Exploit

To branch off of what I said above, no type of userland exploit would work because it will be killed by codesign.

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.

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 WTF 2.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 WTF 2.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 (2nd generation) 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 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 exploit 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);

Alternative Attack Vectors

Codesign Bug

If a major flaw could be found in codesign that would allow for unsigned applications to pass the check, then that would definitely be a decent temporary solution. the next firmware revision would probably have it fixed though, along with the fact that an exploit + privilege escalation hack would be needed to actually get the payload to run. on the flip,side, it would be dead simple because, if the bug was in codesign, execv(); + a return-to-libc attack could just be used.

Chronic's Notes

I have a weird way of keeping things in order. One of them is, when I take notes / document iPod Touch (2nd generation) 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