Free Soft

The IPSF exploit still works in the 1.1.3 baseband, and now that we know Apple doesn't update the bootloader it appears to be safe to use. IPSF works using the RSA padding hack in bootloader 3.9, so as long as the bootloader is 3.9, I can't see it breaking. Here is reference code I wrote to do the IPSF unlock a while ago. With a few mods, elite can turn their virginizer into an IPSF unlocker. I wouldn't bother with the AnySim patches anymore, they are lost after every restore, and need to be modified for each version of the baseband. Be warned though, back up your seczone before IPSF unlocking. IPSF erases your NCK token.
Also I was playing around with writing linux drivers, and I figured I'd start one for the iPhone. Here is what I have so far, it only works in recovery mode. You can echo iBoot commands to /proc/iphone/cmd

Tagi: iphe, linux drivers, recovery mode, bootloader, baseband, ipsf, padding, cmd, token, hack, patches, elite, linux

So now that the iPhone 1.1.3 new features are widely known, check out this video of the home-screen rearrangement. The wiggly icons are super cool:

Read the rest of this post

Tagi: rearrangement, iphone, new features, home screen

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

While I was waiting for CPICH to finish the first bits of the NAND FTL reverse engineering work, I've been trying to fill in some of the gaps we had in other places, such as the PMU. As promised, there is also now an easy way to install openiboot onto the iPhone. This is great because it will eventually lead to an even leaner and easier QuickPwn in the future.

One of the annoying parts about iBoot in recovery mode is that the thing refuses to charge the iPhone while sitting in recovery mode. The battery just eventually entirely drains. With the new PMU code, openiboot now recharges the battery, so programmers using it (read: me) can just have it sit on the console screen indefinitely. You can also do neat things like check the current battery voltage and check the power supply type the phone is charging from.

The "installation code" consists of porting over my knowledge of reading and modifying img3 files from working on the jailbreaks. I was too lazy to port over the entire xpwn framework, but I wrote up a "diet" version that is sufficient to read and modify img3 files in a limited fashion. img3 files are sort of the new native format of the main part of the NOR (just a bunch of img3 files concatenated together). The upshot is that you can load openiboot as an img3 through iBoot (just like sending an iBEC image) and then type "install" at the console and openiboot will be a permanent stage in your bootloader chain. =P

You can, of course, keep booting up to the iPhone OS as you always do by selecting the option in the boot menu. Installing openiboot isn't very useful except for hackers wanting to hack openiboot.

I also figured out how to parse and modify the NVRAM banks (storing environment variables like "auto-boot", etc.), which was actually pointless complicated (in my opinion). They have two banks consisting of a bunch of partitions with these headers that Apple uses a pointless one-byte custom checksum on. The entire bank is also checksumed with adler32. When NVRAM is modified, the oldest bank is overwritten with the data and becomes the newest bank (which is tracked by an epoch number on each bank). This is so if one bank becomes corrupted, the other can be used as a backup. However, NVRAM hardly contains anything high value so the value of all this trouble is doubtful. Being able to write to NVRAM, though, makes it possible to set auto-boot on and off within openiboot so that we can easily control whether or not to enter iBoot's recovery mode.

Someone asked me how "safe" it was to do the installation, etc. Well, I've been doing it every time I make an update these days, so it's fairly safe. The worst that can happen in the usual case is that you may be forced into a DFU mode restore. Everything will be undone with a restore. Early on, I did have bugs that really screwed things up so that a DFU mode restore was no longer possible, but even that was recoverable. I'll just go over how briefly:

The important thing is to have a backup of the NOR. As I described in a previous posting, it's possible to really screw things up if you erase the SysCfg section of the NOR. If you do that, the iPhone OS will refuse to boot at all since iBoot cannot properly populate the device tree for the kernel. Since restore ramdisks rely on XNU booting, this is Bad News Bears. In addition, the SysCfg section is device specific, so if you do not have a backup, it will be difficult to ever completely recover from erasing it.

Therefore, before you proceed, MAKE A BACKUP OF YOUR NOR. openiboot can do this for you (and subsequently restore your backup if things go wrong).

Load openiboot via loadibec and select the console. Connect with the oibc client. Type in: nor_read 0x09000000 0x0 0x100000

This will read all of NOR into memory. Then type: ~nordump.bin:0x100000

This will transfer the dump over USB onto your computer and save it as nordump.bin.

Supposing you filled the entire NOR with garbage somehow and are unable to boot. You have to get into openiboot to restore the NOR. The problem is that openiboot is only designed to operate in a post-LLB or post-Recovery Mode context, so it cannot be directly booted from DFU mode. Basically, you've got to load a pwned WTF, then a pwned iBSS, and then a pwned iBEC (all of which is available from a custom IPSW). After that, you can use loadibec to load openiboot. Then, you can restore the NOR thus:

!nordump.bin
nor_write 0x09000000 0x0 0x100000

After that, you can reboot and everything should be normal.

Also, I received a few responses for people volunteering to do the art. I'm not sure what the best thing would be, since I don't want anyone putting in effort for nothing, but we do want the best possible results. So, I'll be getting back to you guys about that.

Tagi: recovery mode, csts, fashi, boot menu, auto boot, battery voltage, promed, pmu, iphe, nand, iboot, phe, upshot, opti, aces, gaps, programmers, hackers, variables, banks

Apple has added a new layer of security to the iPhone 3GS. I mentioned it several posts earlier; it's the ECID field. When iTunes starts the restore process, they contact Apple servers to generate signatures just for your device. It's important you get these signatures for your phone before a new version of the software comes out. I had previously suggested doing this by dumping usb while the iPhone restores. But this is complicated.

Fortunately, the good folks at purplera1n are here for you, the end user who wants a jailbreak. Follow these instructions to generate a unique certificate for your phones iBSS. And don't delay, Apple may change their minds. To clarify, this is instead of a usb dump. Do this, and you are good!

1. Put your phone into recovery mode and connect it to your computer.
2. Using usbview on Windows(enable Config Descriptors), System Profiler on Mac, or lsusb on Linux, read your phones ECID. It's the 16 digit hex number after "ECID:"
3. Go to purplera1n, type it, and hit enter
4. Save the generated file for a purplera1nyday...

Tagi: digit hex number, iphe, phes, recovery mode, system profiler, good folks, phe, jailbreak, signatures, ecid, ibss, servers, linux