iPhone 3G with 4.2.1 – jailbreak and unlock

Wow – where did the month of June go? I’ve kept busy, but haven’t been very good about posting to the blog – I’ll try to get back to my once a week posts.

Recently my Dad rediscovered my blog and found the iPhone 3G with 3.1.2 post. He also has an older Rogers iPhone 3G and wanted some help unlocking it for use with any carrier, especially for use in the States.

He had upgraded the iPhone 3G to 4.2.1. This came along with the baseband (modem) version 05.15.04. I believe that 4.2.1 is the most current version of iOS that can be run on this generation of the hardware, and from what I’ve been told many feel that 3.1.3 is better performing but will prevent you from running some of the more recent applications that require newer features.

One of the problems with 4.2.1 is that while it can be jailbroken, it doesn’t have an unlock due to the baseband (modem) version. So my first thought was – why not just put the phone into DFU mode, and install 3.1.3 on it?

This is where I ran into the first problem. The firmware installed just fine, but we then got a 1015 error. There are two steps that happen when you’re installing a new firmware on your iPhone. (1) The firmware is installed (2) your PC calls home to Apple to verify the firmware.  There is a good write-up on this by Jay Freeman (saurik) that goes into details (read up on the signature server).

At this point I allowed iTunes to just restore back to 4.2.1 to get the phone back into a working state. Still not deterred, I figured there had to be a way to solve this problem. There is probably more than one solution, but I’ll focus on the one I used: it turns out that you can downgrade your baseband (modem) in 4.2.1 IF you have the right bootloader (5.08).

I used tiny-umbrella to check the bootloader version, I puzzled a bit over the information it was providing until I realized the bootloader version was tacked onto the end of the modem version. This is actually not a required step as the downgrade process will check for the correct bootloader anyways.

On the right is my conceptual model (potentially incorrect) of how the iPhone lays things out. There is the bootloader which is a little bit of code that runs when the phone is powered on. It knows enough to help recover if things are in a very bad state and there appears to be no firmware – or we’re in DFU mode. Breaking the bootloader would be a very bad thing.

The firmware and modem (or baseband) are bundled together for distribution, but occupy unique areas in memory and are installed somewhat independently. There are a number of hacks which allow you to prevent the modem from being upgraded (allowing for unlocking to still work).

My understanding of iPhone unlocking is that most of the unlocks are software tweaks to the modem. This is not a true unlock, but a patch that is run each time the phone is booted (or possibly more often). The reason you need to jailbreak your device in order to unlock, is you need to run some unsigned code to unlock the phone. No jailbreak, no unlock.

So, assuming you’ve got the 5.08 bootloader the steps are:

  1. Jailbreak 4.2.1 with redsnow (the latest)
  2. Launch Cydia and install FuzzyBand
  3. Modify FuzzyBand with a new ‘cert’ (download ICE2-05.15.04.cert)
  4. Run FuzzyBand to downgrade the modem/baseband
  5. Install ultrasn0w via Cydia

That’s it. At the end of step 4 you’ll see the “I HAZ DOWNGRADE!” as pictured at the top of this post.

I find it a bit odd that FuzzyBand in Cydia needs to be modified with an additional ‘cert’ file to identify the 05.15.04 modem/baseband. I used a trial version of DiskAid as I was using a Mac. The modification is simply reaching into the FuzzyBand application installed on your iPhone using DiskAid and adding the cert file to it, very easy. If you don’t modify FuzzyBand, it will refuse to downgrade the 05.14.04 modem, it also appears to check that you’ve got the right bootloader (I did) – so it tries fairly hard to be helpful.

Now that your phone is jailbroken and unlocked, sync it to iTunes to recover all of your apps an files. Do not upgrade the firmware again – or you will be back to square one (or worse, possibly locked out). Also consider capturing your SHSH blob.

Self Promotion: Web Video Interview

As part of a Java Technology India Group event called “Java week 2011” – I was asked to participate in an interview with the experts series. The resulting video interview is linked above. If you want to see a bit more about the entire event, check out the main page.

I need to thank my co-worker Lee for bringing in his camera and also asking the questions on the video.  We did it late on a Friday in one take, so it is very casual.

Here is the list of questions asked:

  • Q. Thank you for granting us this interview. Please introduce yourself and let us know a little about your background and the work you are currently involved in.
  • Q. What has impressed you in monitoring developments in Java technology?
  • Q. What is IBM’s stake and investment in Java Technologies ?
  • Q. What are the technology focus areas for IBM in Java?
  • Q. Do you see any challenges with Java scaling up in leveraging multi-core systems ?
  • Q. While Java (and the JVM) approaches memory management as an internal matter, there are efforts towards moving parts of memory outside Java heap – for instance, look at GigaSpaces, Terracota (and their eCache) etc. What are your thoughts on how this is going to shape up? More specifically, will the Garbage Collection technology become optimal for specific use-cases like caching for instance?
  • Q.  Lately, there is an appliance based delivery of Java (Azul). That approach has compelling technical claims – be it ‘pauseless garbage collection’ or the simplicity in attaining elasticity (Zing). Can you compare and contrast in terms of the overall cost, usability and scalabilty of IBM’s approach versus the appliance based approach?
  • Q.  Any advice for our readers and young developers who aspire to pursue their career in Java ?

My favorite part of the interview is at the 10min mark, where the final question is asked.  If you manage to make it through all 11:20 of the video and feel I didn’t give enough of answer to any of the questions, feel free to comment and I’ll reply with expanded detail.

Cyanogenmod 7 and sshd

Remote access to your phone might seem a bit odd, but being able to access my NexusOne from a computer with a real keyboard is nice when you need to poke around inside the internals. It also makes updating the photos, music, or movies possible without additional apps or cabling the phone to my PC. Today I forgot my phone at home, and was able to verify that I had “lost” it at home vs. somewhere else by ssh‘ing into my home network, then connecting over the local network to my phone using ssh.

There were 3 main steps:

  1. set the phone hostname on boot
  2. configure sshd
  3. make it start on boot

Step one was really easy, turns out it is a supported feature of CyanogenMod 7 (CM7). Enter the Settings menu,  choose Applications then Development, now select Device Host Name. That’s it, I didn’t even need to reboot (the setting is persistent across reboots).

Step two is the most involved, the cyanogenmod wiki has some instructions as does this tutorial. I’ll attempt to provide a guided walk-through here.

a) Let’s assume you’ve got a linux desktop machine. First we’ll create some ssh client keys. We’re going to do this as the dropbear in CM7 doesn’t support key passphrases, so passwords are not an option. The other benefit to ssh client keys is that we can automate connecting to the phone.

So on the linux destop we’ll execute:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/youruser/.ssh/id_rsa.
Your public key has been saved in /home/youruser/.ssh/id_rsa.pub.

For the passphrase we left it empty. In very simple terms – the id_rsa is the private part of the key, the id_rsa.pub is the public one. We’re going to put the public key file onto the phone later. The private one will stay safe and secure on your desktop.

b) I’ll also assume you’ve got adb installed. By connecting the phone to the desktop machine via USB we can push the key file using adb.

$ sudo platform-tools/adb push /home/youruser/.ssh/id_rsa.pub /sdcard/authorized_keys

c) Now we’ll use adb to execute a shell on the phone. This is how I used to get in with a keyboard, but doing so without a wire hook up is very convenient.

$ sudo platform-tools/adb shell

d) Time to configure dropbear, these are all executed within the shell we just created on the phone. You’ll find this is pretty much exactly what the CM wiki describes.

# mkdir /data/dropbear
# mkdir /data/dropbear/.ssh
# cp /sdcard/authorized_keys /data/dropbear/.ssh/
# dropbear-keygen

Initially I had thought I could avoid running dropbear-keygen, but it turns out this is a required step. [Edit: In CM 7.1.0 RC1 dropbear-keygen is not installed, nor does it appear to be required] Now we initialize the keys.

# dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
# dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

And set permissions to keep things happy.

# chmod 755 /data/dropbear /data/dropbear/.ssh
# chmod 644 /data/dropbear/dropbear*host_key
# chmod 600 /data/dropbear/.ssh/authorized_keys

e) Now we get to try it.

# dropbear -v -s -g

The -v option tells it to be verbose, handy if something has gone wrong. You should now be able to connect via ssh from the linux desktop machine, but only from the user id that created the public/private key combination (of which we’ve moved the public key to the phone). Since in step 1 we set the hostname, we can do:

$ ssh myphone
The authenticity of host 'myphone (192.168.1.174)' can't be established.
RSA key fingerprint is 00:c0:b2:78:2b:af:04:72:90:bb:0d:46:f9:14:cc:3f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myphone' (RSA) to the list of known hosts.
# ls
dropbear.pid dropbear_dss_host_key dropbear_rsa_host_key

[edit: CM 7.1.0 seems to be causing me some trouble, in two areas. a) it requires the username matches, so use “ssh root@myphone” b) it doesn’t like rsa public keys but dsa works, so use “ssh-keygen -t dsa”. You’ll know you have the problem as you get a “permission denied (publickey)” error.]

f) Bonus step. We’ll add more keys from other systems we want to be able to connect to the phone from. We repeat (a) on each machine / user id we want to connect from and append the public key to the authorized_keys file.

cat /sdcard/newmachineid.pub >> /data/.ssh/authorized_keys

Now on to step three – making sshd start on boot. I’ll assume you don’t already have a /data/local/userinit.sh file yet for some other modification, if you do I’m sure you can sort this out.

[Edit – as was pointed out by Devon, the original version had !# instead of #! in the userinit.sh script, I’ve fixed the post to reflect the correct code – no worries, the wrong way still works fine as my comment indicates]
On the phone (using ssh or adb to access the shell) you run the following commands:

# echo -e '#!/system/bin/sh\n\ndropbear -s -g' > /data/local/userinit.sh
# chmod +rx /data/local/userinit.sh

You can even run vi if you want (it works!). We can check the resulting file with cat:

# cat /data/local/userinit.sh
#!/system/bin/sh

 

dropbear -s -g

That’s it, we’re done. The next logical step is to start including your phone as part of your nightly rsnapshot backups, or building some scripts to make updating music on the phone easy (and wireless).