Note: Some of this may be a little technical, but I've tried to lay it out as simply as I can so you can all read about my adventures in Kobo.

So, I've been working on a lot of various things related to the Vox, but my main interest is the following:

Modifying the existing Android build to be as vanilla as possible; add Google Framework Support.
or
To deploy a build of the custom firmware CyanogenMod for the Kobo Vox; add Google Framework Support.

Hacker storytime below:

To that end, I started looking for the recovery image/partition. This will help me by telling me how the Vox performs it's updates/recovery as well as giving me a copy of the recovery, in case I muck things up (and I invariably will, at some point).

So, using my GNU/Linux knowledge (and a tip from FriendlyFire at the CyanogenMod forums) I checked /proc/partitions, which contains partition block allocation information.

Clearly (okay, clearly to me) there were a few partitions that weren't regularly mounted at boot.

The first one that I investigated was mmcblk0p2 because of that familiar number next to it. 524288 might seem like a pretty random number to you, but I work with computers a lot and I knew that if you divide that by 1024 you get 512 (going from kB to MB).

My spidey senses were going crazy.

I quickly mounted the partition and listed the contents...

Code:

$ ls
recovery_backup_signed.zip
$ _

Wow, that was too easy.

I copied the archive over to my computer and open it up. It contained several image files, but not the type of image files you might be used to. These were disk images, entire filesystems thrown together as a single file. They were named:

recovery-uramdisk.img
uramdisk.img
system.img

It's late right now (or rather, it's early) so I've decided I won't check those out right now, since I know they'll be pretty meaty. Instead I checked out a neat little file that I recognized as the build properties manifest.