Notices

recoverlock is a small shell script to automate the recovery of the N900 lock code. For all those times when someone sells you a used N900 and forgets to reset the lock code to default, and the like.

Just install it, run the command 'recoverlock' in X-Terminal, wait until it finishes doing its thing, and you'll have your lock code. I recommend you uninstall it afterwords, so that you don't have the command sitting around on your N900 waiting for someone or something else to notice and misuse it.

Currently it and the package it depends on ("john" as in the John the Ripper password bruteforcer) are only in extras-devel, but hopefully we can get them promoted down to extras in the near future.

I made this tiny script almost a year ago, and posted it up on the giant lock code recovery thread. Then the user hxka made it a bit better. But I never got around to properly sticking it into the repositories, so the people who really needed it most weren't all that likely to notice it. Hopefully having it available in the repository will be more helpful and convenient.

if anyone just need to bypass the lock code screen when it shows (using sftp client) i found that this works for me:

dbus-send --system --type=method_call --dest=com.nokia.system_ui /com/nokia/system_ui/request com.nokia.system_ui.request.devlock_close string:"com.nokia.mce" string:"/com/nokia/mce/request" string:"com.nokia.mce.request" string:"devlock_callback" uint32:'0'

That's good to know.

Though as I presume you realize, this addresses two different things. Being able to bypass the lock code screen is useful, but it doesn't actually allow you to change the lock code, as you need to know the current lock code to reset it (at least without manually overwriting the section of the CAL area that stores the password hash). Which means, if the lock code is set to something you don't know/remember, you can't regularly lock your phone again unless you're able to do workarounds like you mentioned whenever you have to unlock it.

of course - just thought it would be a nice addition

amazing work. it only took about 10 seconds to crack my 5 digit code. Great work.

Thank you, but I really didn't do much, I just automated running the commands and put it in the repository.

The real amazing work is by the people who made John the Ripper possible. (And actually the original maker of John the Ripper has done a lot of other great work too: http://en.wikipedia.org/wiki/Alexander_Peslyak )

Also by the various N900 users who figured out how to get the lock code hash from the N900 CAL area, and how to crack it most efficiently using John the Ripper.
As a small sampling, these users deserve thanks more than I do:
R-R [1]
danielpublic [2]
d0gi [3 - Their ONLY post on TMO funny enough]

There's probably others too, sorry in advanced if I missed any of them.

Thank you for this program.

Afterwards, I cannot remove this package, it reports broken cannot update/remove.

like
Removing john...
/var/libdpkg/info/john/.prerm: line 18:

Errors processing

Interesting. The problem is in the John the Ripper package, not mine. I'm not the maintainer for the john package, but I'll look into it when I get the chance, as that is definitely a blocker for John the Ripper getting promoted to Extras.

I presume you are using FApMan to uninstall, and have "Autoremove unneeded (automatically installed) packages" turned on in the options?

Normally, apt-get would delete just the recoverlock package. However, FApMan, when that option is turned on, will also get rid of other packages which were installed earlier automatically which nothing else depends on anymore. Very useful option, but it can lead to issues like this. (The reason it never came up in my testing is I had john installed manually, not brought in automatically by recoverlock like in your case.)

First, I would double check if recoverlock is still actually installed (it's fairly likely that recoverlock got successfully uninstalled before the error came up when trying to uninstall john, depending on exactly how FApMan handles apt-get).

If it's still there, then as root, run:
(You can do 'remove' instead of 'purge', but currently 'remove' doesn't delete the file in /etc/sudoers.d/ - that's fairly harmless, but I'm going to fix that in the next release.)

To remove John the Ripper as well though, the immediate fix would be to delete (also as root):
/var/lib/dpkg/info/john.prerm

And then proceed with uninstalling it as usual.

(Don't get in the habit of doing this, because the various dpkg scripts that come with a package could be doing something important, but in this case I looked through the scripts and it looks like prerm just stops John the Ripper cron jobs that you might have running, so it should be safe in your case.)

(Though the long-term fix would be for me or someone else to patch the cron-job handling script to not break all over the place.)

I'm happy my very dirty hack is still usefull :-)