Kobo Vox Hacking Progress

[danieru]

Just use adb over wifi (adbwireless.apk). As a bonus you can then have the vox charging while you play with it.

Adb is part of android. If your unit is truly bricked then it isn't going to do anything.

[pulsar]

I gave an example when I had no WIFI (so obviously no adb over WiFi), but fixed the unit using adb over USB. Another advantage is that you should be able to clone the internal SD without any modifications (no apk's to install).

I am actually stuck right now, trying to clone my "pristine" internal SD using "adb shell" and "dd if=/dev/block/mmcblk0 of=/dev/block/mmcblk1". For some reason, I get

/dev/block/mmcblk0: read error: I/O error
9527352+0 records in
9527352+0 records out
4878004224 bytes transferred in 3119.049 secs (1563939 bytes/sec)

There may be a few explanations. May be my internal SD does have some problem, and that's why the unit went into a full factory reset. Or may be the fact that I am doing it a) adb over USB, or b) it's not rooted, or c) I'm not using busybox. Before, I successfully cloned the card, but I did it over ssh (WiFi), to a rooted device with busybox.

Too bad - it looks like I won't get a pristine image.

I think adb over USB is one of the very first processes launched, but in a truly bricked unit it won't be available.

UPDATE: Hah, I've just successfully did "dd if=/dev/block/mmcblk0 of=/dev/null bs=4096". I also stopped most of the running processes - may be they somehow prevented the copy before? In any case, it appears there are no issues with the internal card. I'll try to repeat it now to the external SD card.

BTW, doing adb over USB apparently keeps the battery charged (?!). I've been running it for a few hours, and the battery sign is still "full charge".

UPDATE2. I did succeed with creating a clone of my "pristine" internal SD, running dd with bs=4096. Perhaps that was the key? I remember I used the same bs value when I made my first clone SD, over SSH.

I'll probably post my mini-guide "adb for Kobo Vox" tomorrow.

[hieronymos]

Awesome! Could you upload it somewhere? If you tar.gz it, t should become 200-300 MB...

Next step is to find that darned bootloader :-) In the freescale tools, they also included tftp - does anybody know if that could be any good?

[spikexp]

Originally Posted by pulsar

BTW, doing adb over USB apparently keeps the battery charged (?!). I've been running it for a few hours, and the battery sign is still "full charge".

Well, could be your motherboard. Some motherboard now give 3 the amp output (1.5 A). That might be enough to charge what is used by the device (or near it so it only discharge really slowly).

[pulsar]

Originally Posted by spikexp

Well, could be your motherboard. Some motherboard now give 3 the amp output (1.5 A). That might be enough to charge what is used by the device (or near it so it only discharge really slowly).

No way - it is a 6 years old laptop .

[pulsar]

Originally Posted by hieronymos

Awesome! Could you upload it somewhere? If you tar.gz it, t should become 200-300 MB...

Next step is to find that darned bootloader :-) In the freescale tools, they also included tftp - does anybody know if that could be any good?

Well, the image has my Kobo (+Facebook) accounts with passwords, so I wouldn't share it publicly.

You think the compression level will be that high? BTW, I discovered that the "full factory reboot" didn't touch files on the FAT32 partition (user data), and I had some stuff there (not much - a few MBs).

[hieronymos]

Ah, you had turned it on :-) And actually the only thing that will get really compressed is the empty space in all partitions. /system itself has maybe 150 MB of data and the other images are peanuts, basically.
An empty 8Gb usually becomes < 200kb.

And if you have the screen off while plugged basically anything will charge the tablet. When you turn the screen off, also the processor scales down and with it everything on the board. I'm quite curious to see battery life when scaling is implemented while awake (when the GPU works).

Add: Well, at least I now know where the repos for the recovery are. http://forum.cyanogenmod.com/topic/3...y-on-kobo-vox/
Will have a look at it when I receive the SD and can dissect the system image properly.

[hieronymos]

Originally Posted by stevebriggs

So I tried swapping the internal 8gig SD card for a 32 today. I made a disc image using R-Drive Image 4.7 (which expanded the 5.3 gig FAT 32 free storage partition to fill the extra space on the bigger card, but the Kobo Vox wouldn't boot up. Replacing the original 8 gig card still works fine, no loss of any of the apps I've put on. Can any of you more tech-savvy types comment on this? Is it a lost cause because of something I don't know about?

I don't know if you're still reading but while turning on my Android 2.1 Motorola I just had an idea. So as far as I read on other forums, expanding the SD partition for our infrastructure didn't work. I don't understand enough about SD cards and embedded design to know why (although I guess it's a left-over from last year's NAND flash and absolute partition tables).
However, on my 512MB Motorola, I created a partition at the end of the SD that I afterwards mounted into the system storage, and then moved apps and linked them with http://forum.xda-developers.com/showthread.php?t=919326
I guess Link2SD could at least make it easy for you to create the mount scripts. And if you really just want to throw apps at your Kobo, it will do everything you want.
Otherwise, you could have a look at what Link2SD actually does and just mount the second partition inside the first partition. Which also mean you have to mount the second SD /after/ the first, contrary to Link2SD.
The second partition should still show up in Windows when you plug the cable - at least, on my Moto it shows in Linux.

Maybe try not to expand the last partition in the original image, but to append another one. If it still boots, that solution should work :-)

[pulsar]

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:

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:

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?

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.

[hieronymos]

Great! Skipping the bootloader was a great idea :-)

The recovery is usually either being called from the button combination or from within the OS. So the initial signup stage, if I understand right what you mean, happens within Android - you sign up there, then it downloads the update.zip and reboots into the recovery (I'm quietly wondering what happens if we place a update.zip on the sdcard and reboot recovery - I like simple solutions). You can browse what the recovery is usually supposed to do here: https://github.com/android/platform_recovery

The keys you have there might well simply be signed by victor@vgonzalez-ubuntu or K01.01.20110801 or something else that is automated in the freescale build process, which does it by default. But of course we need to find out if their use is actually enforced. What we (or at least me) want inside the recovery is fastboot (it doesn't seem like it's in there), so we can flash without opening up. Unfortunately, I just checked the freescale recovery and it isn't there either - I'm still trying to find the relevant piece of information on this one.


I wonder if Victor is coming around from time to time, smiling down on us as we are sitting in front of these riddles. :-)

P.S.: *fingers crossed that a distributer has asked for a way one-click solution to recover bricked units...* :-)

P.S.2: Well, they didn't. Back to reading, I guess.

[FriendlyFire]

I don't know if you guys have heard, but apparently there's now a build of ICS for the iMX53. Who knows, maybe it could be adapted to the iMX51

[hieronymos]

Debian and Linaro are working on the imx51 since it came out. It's use as a tablet is rather new. They have prepared images for imx. You can also download an Ubuntu image directly from freescale.
The problem is not getting any port running, but to get it on the device in an easy way.
Still waiting for the SD :-/

[hieronymos]

I just found something.

a) Device is turned off.
b) Hit power shortly, just to turn it on.
c) Hit power again and stay on it for a few seconds.

Result: green light keeps blinking, screen stays black.

I have nothing popping up in dmesg - no fastboot. No Elvis in Windows either.
But there is definitely something.

Maybe this is where tftp could come in handy.

[jefftheworld]

If you want a quick an easy way of using Linux you can always do a chroot install.

I've got a chroot Debian install on my Vox. It runs on top of Android so it's still fully functional as an Android device, but with the added power of linux. If you want a full GUI you can even install a linux desktop environment and a VNC server, then use a VNC viewer app on the Android side to interact.

Edit: Made a tutorial of it a while back. It's a little slow, but it'll walk you through everything you need to know about doing the install.

If you want full control of your Android install via the linux install you'll want to enable the "Bind /" option.

[hieronymos]

512MB RAM, of which are 370MB available - 170MB sytem apps = 200 MB for a chroot (starts swapping earlier) = not fun working on LibreOffice. :-)

Also, a native Linux would make it easier to check what we can do with the USB plug.

However, I'm getting a little frustrated, so I'll take a break until Kobo provides the GPL sources that they have to provide. What they did with uboot should be documented.