Chronic Dev Blog

There has been a bit of confusion going on, with different terms being passed around and confused for something else. I would like to clear a few things up.

Hardware-Level Exploit
This is what Pwnage 2 is based on. It is considered one of the best exploits yet because it is such a low level one. It does not matter what firmware version you are on. This is because the code is burned into the bootrom of the iPhone, iPhone 3G, and iPod Touch. The firmware itself is even a higher level then this exploit is based on, is what I am saying. Basically, because it is built into the hardware, Apple cannot fix it without a hardware revision. You could be on version 1.0.0 or 3.0 and as long as you are using an exploitable bootrom, then you will always be able to pwn it no matter what. So basically, anyone with an iPhone, iPod Touch, or iPhone 3G do not have to worry about it getting fixed. The best Apple can do is prevent it from the iTunes side of things, but since that can be reversed and patch that does not matter. Now the downside to such a low level exploit is that even if iPod Touch 2G firmware 2.2 came out and iPhone 2.2 came out, you can still pwn the iPhone but not the iPod Touch 2G, because the exploit is not there in the iPod Touch 2G hardware.

Bootloader Level Exploit
I don’t know if this is what the official name of such an exploit would be, but what I mean is an exploit in the iBoot, or the iPhone / iPod bootloader. Some examples would be the ramdisk exploitor the diags exploit. Unfortunately, since the iBoot and friends are flashed during restore to a newer one found in the IPSW, these kinds of exploits can be patched. But, with that being said, you will always be able to, if you found an iBoot exploit, load it on compatible hardware. Like, if you tried, you cannot load a ramdisk/diags exploitable iBoot onto an iPod Touch 2G, because it does not support the old 8900 format. But, if an exploit was found in the iPod Touch 2G 2.1.1 iBoot, for example, and Apple fixed it for iPod Touch 2G 2.2, then you can always load an exploitable iBoot. All you would have to do is plug your device into the computer with all iTunes related processes killed, in DFU mode, and then grab iRecovery. Send it DFU the old exploitable iBSS, found in the old firmware IPSW, and then do the exploit as it would be normally done. Note that this does NOT mean that we have a jailbreak and this is the method, I am saying that if an exploit is found, this is how you can make it so that it will work on other firmware versions that have it fixed. Now, it is not quite as awesome as a bootrom exploit, but ranks pretty close.

Userland Level Jailbreak
There is really no use in these anymore. Some examples of these are the TIFF exploit in Safari, the 1.0.0-1.0.2 Restore Mode trick, and the 1.1.1/1.1.2 symlink hacks. Unfortunately, in 2.*, the kernel will kill any unsigned code that tries to run. Now, the exploit itself would work, as in, if it were a Safari exploit, then it would not be seen as a new binary running but as code inside of Safari (that is generally how exploits work). The issue is that you would have to run custom apps, like Cydia, or something like that, as a separate app. This type of jailbreak is a dead end if you want to do anything cool. You can’t even patch the lockdownd or MobileInstallation, which are thought of as the core things needed for a jailbreak on each firmware revision.

Filesystem Dump
This does not mean a jailbreak. It just means that we have found a method of looking at the filesystem of an iPod Touch 2G, but in read-only form. As stated above though, even if we could change things, it would not matter as the kernel would kill anything that is not Apple signed. To the Average Joe the Plumber, this is not a big deal, but it is just useful for us to be able to scope out the filesystem and see what is similar and what is different.

Two-Way Communication (iRecovery)
We can basically communicate with the iPhone / iPod just like how iTunes does, except we actually get to do whatever commands we want instead of letting iTunes do the hardcoded in stuff. This does not let us run unsigned code though, because Apple is smart enough to realize that stuff on the computer size of things can be easily tampered with, made most obvious by the 1.0.0 / 1.0.1 / 1.0.2 jailbreak method. We need to find an exploit to run unsigned code, and then we can use iRecovery to load / utilize that exploit to do what we need it to do.

Now, I would just like to make a note about the iPhone Dev Team. In the comments I see stuff like “chronic dev is god” and “you are better than devteam you can do this”. While we are working hard on this, it does not mean the Dev Team is not. They just have a bit of a different way of doing things, which I have come to respect by seeing how things fall apart / you can’t get any work done when you are doing stuff in a public place where it is mostly people asking questions about what you are doing. They may have an exploit already and are simply deciding amongst themselves if it would be a good idea to release it now or to wait for a future firmware rev where it will still be usable, or they may still be working on it. Whatever the case is, they do things in mysterious ways and I think that they deserve respect for their work, even if they are a bit more tightly knit than people usually would hope to see. So please, give them some credit for their effort too, they may not be blogging about it but that does not mean they are not trying

I hope this clears some stuff up. Ask questions in the comments and I will answer as many as I can to the best of my ability. Before you ask about the progress, it is being worked on, but no major breakthroughs have been made as of now.

This entry was posted on Friday, October 17th, 2008 at 10:45 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.