[Solution] Customize or update the factory image for stock recovery


Senior Member
Aug 27, 2009
The stock recovery on the Nook Simple Touch has a routine to restore the device to factory state, wiping everything in the process. It is initiated on the 8th unsuccessful boot (unsuccessful := interrupted before the boot counter could be reset). The image is stored on the "/misc" partition, /dev/block/mmcblk0p3, as /factory.zip. On my device, it's version 1.0.1 (file size: 108460423, MD5 sum: 3ae0d4d9869330dec639a7da9c50fa72). Not very useful. So, how about customizing it? Or at least upgrading it to stock 1.2.1?

When restoring to factory state, the /cache and /data partitions are wiped independently by the stock recovery. As for the files inside the ZIP, there is no difference between the factory image and the OTA (over-the-air) update (nook_*_update.zip). The format of both files is the standard Edify ("updater-script") style. If you have your own script you can put it there for easy restoration. If you don't, you can at least upgrade the factory image there to 1.2.1, the latest version. The example is for the latter case, but all the steps will be the same, except the first one.

Please do not follow these instructions blindly. Instead, read them critically and adjust to your situation, adding extra steps such as backups where necessary. Make sure that you don't mind if everything from your device is erased in the process.

Remove B&N cruft from the ZIP update header
Start with the file nook_1_2_update.zip (get it here from B&N). Make sure you have the right file: size 121323347, MD5 sum: 30822c2927482380c325a47dc060daee. Note that while a well-formed ZIP file starts with the letters "PK" (from the initials of Phil Katz, the original developer of the ZIP format), the B&N ZIP has some proprietary gibberish at the beginning:
First 418 bytes of nook_1_2_update.zip. Unprintable characters replaced with dots.
Unzip and other unpackers will get through this just fine so you might not even notice it but it will prevent the file from working as factory image for the stock recovery, so let's start by getting rid of the cruft. There are at least three options here: (1) use dd(1) (UNIX shell or Windows CLI), (2) use Free Hex Editor (Windows GUI), (3) unzip and repack again. The dd command if you're lucky to have a recent version is:
dd if=nook_1_2_update.zip of=factory.zip skip=418bytes
- or -
dd if=nook_1_2_update.zip of=factory.zip iflag=skip_bytes skip=418
Option (3) will break the B&N signature on the ZIP. Theoretically, if the signature is preserved, the file should work as-is as the new factory image as it matches the key stored in the recovery). It didn't work for me but I didn't try too hard because what I want to do is to use a custom image anyway so feel free to check for yourself (skip to the last step).

Otherwise, if you are using the stock update file that you want to sign again, you need to remove the signature that is already there. Supposing your soon-to-be new factory image file is called factory.zip, the way to do it is:
Insert your key into stock recovery RAM disk image
For customized factory.zip signed with your own key, we need to tweak the recovery image a bit.
Extract the image from the update ZIP:
unzip -j nook_1_2_update.zip ramdisk-recovery.img
Replace the file res/keys (see attachment) in the image, using XDA user Renate NST's bootutil.exe tool:
bootutil /r ramdisk-recovery.img res\keys
You can also leave the old key in place and append the new one, just make sure there is nothing in between them (not even whitespace). And here are the alternative steps to unpack and repack the image using just the standard tools, which might come handy on UNIX:
dd if=ramdisk-recovery.img bs=64 skip=1 | gzip -cd | cpio -id
find . -not -name ramdisk-recovery.img | cpio -oc | gzip -c9 | mkimage -A arm -O linux -T ramdisk -C gzip -a 0 -e 0 -d - ramdisk-recovery.new.img
Now the image just needs to be installed:
adb shell mkdir /data/boot
adb shell mount -t vfat /dev/block/mmcblk0p1 /data/boot
adb push ramdisk-recovery.img /data/boot/uRecRam
adb shell umount /data/boot
adb shell rm /data/boot
Sign and install the customized factory image ZIP
Suppose our new factory image is called factory.zip. Then to sign it:
java -jar signapk.jar [B]-w[/B] testkey.x509.pem testkey.pk8 factory.zip factory.signed.zip
See the attachment below for the necessary files. Note the -w switch, which is particularly important in this case.
Now just for the installation part:
adb shell mkdir /data/factory
adb shell mount -t ext2 /dev/block/mmcblk0p3 /data/factory
adb push -p factory.signed.zip /data/factory/factory.zip
adb umount /data/factory
adb rm /data/factory
Restore to factory image to check if it works
For an easy alternative to the power button marathon:
adb shell
echo -n -e "\x08\x00\x00\x00" >/rom/devconf/BootCnt
Warning: this wipes everything, all your data on the device will be lost.

Bonus: What if you want to use your own key?
The testkey.{pk8,x509.pem} is one of these ubiquitous Android debug keys, used all around. Apparently, it was good enough for B&N as well, as they used a version of it too for their OTAs (see /system/etc/security/otacert.zip). If it's not good enough for you though, and you have your own key, the attached keys file will not work for you; instead, you need to generate the key dump in the right format for yourself using the dumpkey utility also provided in the attachment:
java -jar dumpkey.jar testkey.x509.pem >>res/keys
Replace the references to testkey with the name of your key throughout the examples. If you're doing this on Windows, remember to convert the line ending to UNIX format (CR+LF to LF), not doing so might make the key not work.

General note: If at any stage you need to debug why a key is rejected, there is a log being saved by the stock recovery under /cache/recovery/log.

Disclaimer: Please do not follow these instructions blindly, but instead adjust them to your situation. This is the minimal set of necessary actions, with any optional steps removed for the clarity of illustration. I don't do it this way myself: personally, I'd make a backup here and there, verify MD5 sums after copying large files, etc. In any case, if something goes wrong, you will have to boot from SD card and restore your device. If everything goes right, you will lose all the data on the device. These instructions are provided on an "as is" basis. I will not provide support if anything doesn't work as expected for you. Anything you decide to do based on the above instructions is your sole responsibility.


Last edited:
  • Like
Reactions: tj_f


Senior Member
May 26, 2012
dumpkey.jar really helped, thanks for that. Had to make exponent 3 type android key else it gets rejected, if you compiled the class, can you remove that check? Out of thanks for today. :)

Renate NST

Inactive Recognized Developer / Recognized Contrib
Feb 3, 2012
Just a short note:
"bootutil" is now called "imgutil" and can be found in the signature.
There are more options than before, but I forget which ones.