Notices

Have a 623.1mb -optfs file and a 270.4mb rootfs file.

I think, Backupmenu should have a settable password.

I'd love to install this, but if my device get stolen or lost, backupmenu without password is too easy way to hack it.

Because, even if rootfs and eMMC is flashed, security code stays the same and if it has been set, the device will ask the security code when the system boots after both rootfs+eMMC-flash.

Er... No, it doesn't. If you flash your n900, the security code will be the same, yes, but it -will not- ask for it at boot. This means that someone could easily enough simply pull up a root terminal, grab a "key-code grabber" script(It's one line), run the encrypted result through John The Ripper, and have a new password set in an hour.

Remember: When you lose physical control, you have lost all security.

As such, I'm not going to do this. SSH/terminal mode -do- require a password however(Your root password).
Also, for anyone that cares - Once you login via ssh and have your password entered, you can type "getlockcode" at the prompt to recover your (encrypted) lock code.

@etuoyo:
Can you give me the output of "df -h"? That rootfs size looks fine, and the optfs -may- be fine too. It may be just a corrupted file or something... But you should be getting a message about it during backup.

I have flashed couple of times both eMMC+rootfs and every time when I boot, the N900 asks the security code or it will not boot further. Also my N900 (both of them) somehow does not show anything useful for John The Ripper to work from.

I just checked the topic. I'm guessing you broke something in /dev/mtd1 (Bad block, perhaps?) - Not only is flashing not resetting it, but you aren't getting any code back, while everyone else seems to be able to do it.

Unless you can actually have your code -work- as well as not be able to get in after reflash without the code, I can't say that's the "normal" behavior.

edit:
As it is, if you are a knowledgable person(and take the time), if you have BackupMenu on your system you would be able to login via SSH(with your root password) and either crack or replace/fix the lock code if it was needed.
I'm pretty sure that in the case of BackupMenu, users would prefer to be able to recover things than have more security. Remember, if there was a lock on this too, you would be screwed - you wouldn't be able to get in via BM either.

Hey Robbie, I've been thinking more about using nandsim/nandwrite to make it easier to create the ubinized image. In the process, I've discovered an alternative to using dd which does include OOB data - namely, nanddump /dev/mtd5 (the rootfs partition). This can then be restored using nandwrite -a -o /dev/mtd5 path/to/image/file and does keep bad blocks marked etc?

There are few others who have this "problem" also, that there is not coming anything looking like DES encryption after the string "lock_code" in /dev/mtd1

I wonder, if this is a patent thing, and in some parts of the world Nokia has indeed used other encryption than DES.
Or if it indeed is some kind of fortunate seldom triggered bug, that makes the device harder to crack.

And forgot to mention, I have in settings, that in 10 minutes of idle usage, the device will lock itself with the security code. I think that is why it asks the security code every time it boots up, also after full rootfs+rMMC reflash. I guess people normally do not have that auto security lock enabled and haven't noticed it does survive over reflash also. (which seems to be a good thing).

Backupmenu asks a root password with ssh access, good, but using (o) USB-storage mode or Create a backup it is, IMO, too easy now to copy user data out of the device by a thief. Couldn't the same password be used as with ssh-access to whole backupmenu if a user wants to set up it that way?

I know, having physical access to the device and enough time, a thief can get the data anyhow, maybe (?), but now with backupmenu leaving the phone unattended just for a few minutes lets a cracker copy eMMC to his PC and only thing owner notices is that the device has been shut down.

I said "maybe", because currently I haven't figured out how to access or mount /home/user (or MyDocs) without knowing the security code. Maybe flashing with rescue_initrd allows it to be mounted over USB without knowing the security code? Also in those devices where DES is working "normally", I guess one can flash /dev/mtd1 and get rid of the security code asking, but then the owner will notice that the security code has been removed.

At least, it would make the crack harder and more time consuming and perhaps there would be marks left by a cracker. Now with backupmenu installed there is no trails left to notice if someone has stolen you data while you were in a toilet.

Guys,
I havent read the 42 page thread but need some suggestions. I plan to install my own custom kernel on N900 but before doing that want to make sure i dont end with a bricked device. I have installed backupmenu and taken a backup of rootfs and opt in MyDocs.

Now if i flash my kernel (and copy over /lib/modules) and the device doesnt boot will i be able to restore the /lib/modules from backup. This is assuming that i still willbe able to see the bootmenu even after flashing my custom kernel and a bricked device.

Also, i dont plan to change my kernel version string but have it as -omap1 which is the same as stock kernel. I will simply overwrite all the stock /lib/modules/2.6.28-omap1 with my own custom kernel modules.

How does this sound?

You'd be on a safers ide if you were leaving original files as they are and use some other string for your own kernel. That way you'd have no downside (as far as I know) but would always be able to reflash the original kernel and it would immediately find its own modules again.

I presently have a symlink /lib/modules/current which points to /lib/modules/2.6.28-omap1. Is that 'current' symlink necessary in maemo? Because if it is, and since it will point to my new set of modules and if try to use the stock kernel it will fail.

If i have /lib/modules/2.6.28-omap1 and /lib/modules/2.6.28-mykernel and no 'current' symlink, would the device boot up fine?