I finally figured it out how to unpack the raw images present in the recovery*.zip file inside unmounted partition /dev/block/mmcblk0p2 - at least for uramdisk and recovery-uramdisk . I did the following, for both images:
Code:
dd if=uramdisk.img bs=64 skip=1 of=uramdisk.gz
gunzip -v uramdisk.gz
mkdir uramdisk
cd uramdisk
cat ../uramdisk | cpio -iv
I skip the first (bootloader) sector, 64 bytes long, in both images. I ended up with all the files and directories present in the both images (including init and init.rc). You can download them from here:
http://www.physics.mcmaster.ca/~syam/uramdisk.tgz
http://www.physics.mcmaster.ca/~syam...y-uramdisk.tgz
The recovery image is the most interesting - presumably that is what is executed when you use the unit for the first time, or if you trigger a full factory reset. Have a look at its init.rc file (below). It is small, it does the most basic stuff - including starting adbd, and running sbin/recovery. The latter is a native ARM binary, statically linked, so I can't tell what it's doing. Can it include the initial Kobo signup stage? The uramdisk image doesn't have this recovery binary, and also have a different (much longer) init.rc.
Okay, I can see something by running "strings sbin/recovery". E.g., the following strings are present there:
Quote:
mkfs_ext4
inflate 1.2.5 Copyright 1995-2010 Mark Adler
E:Can't mount %s
E:Error in %s
I:Boot command: %.*s
I:Boot status: %.*s
recovery
I:Got arguments from boot message
E:Bad boot message
boot-recovery
recovery
BATTERY = %d (%d)
Formatting %s...
Factory data reset
Wipe data/cache
System update
Enabling Encrypted FS.
Disabling Encrypted FS.
Error: invalid Encrypted FS setting.
Successfully updated Encrypted FS.
/recovery/recovery_backup_signed.zip
/extsd/update.zip
/sdcard/update.zip
E:signature verification failed
E:Secure FS: error setting up properties.
E:Secure FS: error accessing properties.
E:Secure FS: error setting up key file.
E:Secure FS: error reading conmplete key.
E:Secure FS: error accessing key file.
E:Secure FS: error mounting userdata partition.
E:Secure FS: error reading generated file system key.
E:Secure FS: error reading file system salt.
E:Secure FS: error reading password hash.
E:Secure FS: error reading ported entropy.
E:Secure FS: error unmounting data partition.
E:Secure FS: error writing generated file system key.
E:Secure FS: error writing file system salt.
E:Secure FS: error writing password hash.
E:Secure FS: error writing ported entropy.
persist.security.secfs.enabled
/data/property/
/data/system/
/data/fs_key.dat
/data/hash_salt.dat
/data/system/password.key
/data/hash.dat
/data/system/entropy.dat
/data/ported_entropy.dat
...
|
Interesting - I think it's looking for update.zip file on both internal and eternal SD cards. Also, some file systems are likely encrypted.
I think the only way to test if these raw images are signed (locked) is to disassemble the unit, take out the internal SD card, make a copy of the non-live file system using dd, unpack it (say, the uramdisk), make a tiny modification (create a tiny file in the root directory?), repack it, copy it back to the SD card (or to another card - safer), put the modified card in Kobo, and power it up. If it refuses to power up - the raw images are locked, if everything is normal - at least that image (uramdisk) is not locked, which would let us customize it (init.rc etc). Does it all make sense?
Code:
on early-init
start ueventd
on init
export PATH /sbin:/system/bin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
symlink /system/bin/toolbox /system/bin/ls
symlink /system/bin/toolbox /system/bin/sync
symlink /system/bin/toolbox /system/bin/mount
symlink /system/bin/toolbox /system/bin/umount
symlink /system/bin/toolbox /system/bin/ps
symlink /system/bin/toolbox /system/bin/kill
symlink /system/bin/toolbox /system/bin/cat
symlink /system/bin/toolbox /system/bin/echo
symlink /system/bin/toolbox /system/bin/date
symlink /system/bin/toolbox /system/bin/dd
symlink /system/bin/toolbox /system/bin/rm
symlink /system/bin/toolbox /system/bin/mv
symlink /system/bin/toolbox /system/bin/ln
symlink /system/bin/toolbox /system/bin/insmod
symlink /system/bin/toolbox /system/bin/rmmod
symlink /system/bin/toolbox /system/bin/lsmod
symlink /system/bin/toolbox /system/bin/reboot
symlink /system/bin/toolbox /system/bin/wipe
symlink /system/bin/toolbox /system/bin/cmp
symlink /system/bin/toolbox /system/bin/dmesg
symlink /system/bin/toolbox /system/bin/df
symlink /system/bin/toolbox /system/bin/log
symlink /system/bin/toolbox /system/bin/sleep
symlink /system/bin/toolbox /system/bin/chmod
symlink /system/bin/toolbox /system/bin/chown
symlink /system/bin/toolbox /system/bin/uptime
symlink /system/bin/toolbox /system/bin/vmstat
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mount vfat /dev/block/mmcblk0p4 /sdcard
mkdir /extsd
mount vfat /dev/block/mmcblk1p1 /extsd
mkdir /recovery
mount ext4 /dev/block/mmcblk0p2 /recovery ro
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
on property:persist.service.adb.enable=1
start adbd
on property:persist.service.adb.enable=0
stop adbd
# Reset boot count
#start = 1024 * 1024 * 29 = 30408704
service boot_count /system/bin/toolbox dd if=/dev/zero of=/dev/block/mmcblk0 bs=1 seek=30408704 count=1
oneshot
service boot_count /system/bin/toolsbox sync
oneshot
Finally: I compared the first (boot) sector in both uramdisk and recovery-uramdisk, and they are completely different - both the binary part, and the string inside ("Android Root Filesystem" and "Android Recovery Filesystem", respectively). I am not sure what it means.
One more thing: the recovery_uramdisk contains a text file res/keys, which is filled with comma-separated numbers (keys for signing the images?). sbin/recovery has a reference to this file.