45 seconds of play, ~5 hours of desperate hacking.

A few days ago, my 4 year old daughter was playing with my mobile phone running Android 1.6. To let her play with the screen while avoiding any mishap, I locked the phone. It was obviously not enough, she instantly found the MENU key to unlock it.

So I had the brilliant idea to put on a locking pattern, the pretty method used on Android to really lock the screen.

After 5 unsuccessful tries, which my daughter reached in about 15 seconds, the pattern unlocking incurs a 30-second guard delay. I decided that the game was too risky (I found out later there’s also a 20-try hard limit, but we didn’t reach it) and took my phone back.

There, I had another brilliantly fatal idea: I clicked on the “forgot the unlock pattern” button which just appeared, just out of curiosity to see what would happen next. The phone asked for my Gmail account and password. I filled the requested information, but it didn’t unlock the phone; apparently this is a known Android bug that I didn’t know about. And, contrary to what I naively assumed, there was no way to get back to the unlock pattern screen. I rebooted the phone. No change, no escape.

Then it dawned on me that I was 600 kilometers away from home, for almost a full week, without all my computer tools. And I was locked out of my own phone.

On the plus side, I had another almost usable (EDGE) mobile connection, and quickly found out a hack to clear the lock pattern using the Android SDK tools. I needed a Windows or Linux PC, but I had one at hand.

So I happily began downloading the 23 MB Android SDK zip file. It stuck at 5 MB. I tried again. It stuck again at the same size. Something crappy, either (most probably) in my mobile provider’s network or Google servers.

Long story short: I ssh‘d at home to get the SDK through wget. scp’d it. Got stuck at 5 MB again. sftp‘d it in 5 MB chunks instead. Finally got it where I needed it. Installed it, started it. Discovered that I needed to fetch the USB driver for Android… which is a 6 MB download. I’m sure you can guess what happened next; no ssh fallback this time since this download is integrated within the Android SDK tools 🙁

(apparently there were standalone USB drivers available, but I didn’t find these until it was too late)

That’s when I fortunately remembered I had installed the JFv1.43 custom recovery code on my phone, which you can activate by pressing the HOME key while powering up the phone.

So I did, I started a single-user mode root shell directly on the phone, mounted the /data and /system partitions, and as described in the fix I referenced above, ran “update system set value=0 where name=’lock_pattern_autolock’;”.

Reboot. No way. I was still stuck on the Gmail login form.

After a bit more wrestling with SQL, looking at the system table, I finally found out the cure to my problem:

update system set value=0 where name=’lockscreen.lockedoutpermanently’;

Reboot. I got access to my phone, at last, after 5 hours of cursing. I love Android. What other phone would let me do this?

Lessons learned:

don’t play with or (worse) monkey-test security systems, especially when away from home;

set up a recovery shell for future use, to cater for possible bugs;

Android is still a bit rough on the edges, to put it nicely;

it’s nice to always have a real computer handy; and possibly a spare IP connection, too;

I’m glad Android makes this kind of hacking possible, almost easy and legit.

Things that I think should really be changed in the Android locking pattern behavior:

don’t count (or significantly raise) the number of unlocking failures before asking for the Gmail login (What if the phone is in my pocket? A child plays with it unattended?);

fix the old bug that prevents unlocking (at least in my case, but I don’t seem to be alone) with the Gmail account: given that it was so fast to reject the password, it clearly didn’t test it to Google over the data connection; so I wonder if that screen isn’t just a mock-up, which would be perverse but is supported by the name of the variable lockedout permanently ;

bug that prevents unlocking (at least in my case, but I don’t seem to be alone) with the Gmail account: given that it was so fast to reject the password, it clearly didn’t test it to Google over the data connection; so I wonder if that screen isn’t just a mock-up, which would be perverse but is supported by the name of the variable lockedout ; let the user revert from the Gmail login screen to the unlocking pattern, that may come in handy (at least when he explicitly chose to press the “Forgot the pattern” button), or make it very clear that there’s no coming back.