I'm slightly lost here - I thought that everyone who is not able to get their code via the mtd1 method was -also- not able to login with -any- code?

Now, one thing I -did- notice was that when I was testing out that /dev/mtd1 grabber script, the -first- time I tested it with root console, I got my encrypted code. The -second- and all following times, I got a blank string back.
However, when I ran that command via SSH inside BackupMenu, I was able to get the code -every- time I tried, with several different codes.

This may just be an issue of luck, or perhaps something ends up locking it up -sometimes-.

Either way, would you mind trying to grab it by installing BackupMenu and SSH server, then logging in and running "getlockcode" from the console? I'd like to see if it's an OS thing, or there -is- something different here.

@zimon: Rob1n is correct. It's just a script that relies on bootmenu-n900 for all the actual boot stuff. In fact, I'm not entirely sure quite how bootmenu-n900 actually works; I'm sure I was told at one point or another, but I've forgotten.
What I do know, though, is that if I put an ash-script file inside /etc/bootmenu.d/ with the extension .item, it will run that code during boot with the keyboard open.
Now, what's -supposed- to happen is that bootmenu-n900 will read all files and get menu items out of them as encoded variables. What -actually- happens is that it tries to read my script, which "hijacks" it, keeping control. This is why, when BackupMenu fails, it drops to the default bootmenu-n900 prompt.

Now, I'd like to figure out how to get a proper bootmenu-n900 compatible file there, so they can be run side-by-side, but I can't figure it out quite.