Kobo Vox Hacking Progress - Page 4

hieronymos · 11-17-2011, 09:02 AM

Maybe I have a very special device then. *shrugs*.

The log for the reset however contains the explanations for your image; the mount table. I'll just dump the whole log here if I may.
Somehow it explains the unallocated space. /tmp could probably be on the SD instead of the RAM without any problem - maybe they're still working on that.

Spoiler:

I'll go and see what's inside that recovery_backup_signed.zip - maybe I can simply replace a few of the contents with Clockworkmod.

P.S.: stevebiggs, probably the internal SD card is too slow to play back 3GB / (the seconds your film takes). Try streaming it from another computer - a 1.8GB file from my UPnP server worked fine here.

P.S2: Turn out the recovery .zip is particularly interesting. The only file I can mount is system.img - the other files are in some other format than ext or yaffs or simply are corrupt. System.img contains a bluetooth.apk (indicating it might be the freescale image) and no bloat. Just two kobo files.

pulsar · 11-17-2011, 09:50 AM

And here's what my Gparted says about my clone SD (it should be identical to the internal SD, except for the bottom unallocated space):

Which version of gparted are you using? Mine is 0.9.1, ran under Fedore 15. The differences are that it does reports ext4 for 3 partitions (as Kobo's "mount" command), but it agrees with you on /data being ext2, and KOVOBOX being fat32. Why on earth are they using fat32 on the internal SD card? WHat advantage can it have compared to ext* file systems, given that it is Linux?

pulsar · 11-17-2011, 09:52 AM

Quote:

Originally Posted by hieronymos

Maybe I have a very special device then. *shrugs*.

Do you mean the fact that your device had data wiped out by Volume Up + Power? In fact, it also happened to my device. I discovered yesterday that all my user data was gone - I'm pretty sure because I also tried Volume Up + Power at some point.

spikexp · 11-17-2011, 10:06 AM

Quote:

Originally Posted by pulsar

Why on earth are they using fat32 on the internal SD card? WHat advantage can it have compared to ext* file systems, given that it is Linux?

So that it can be see on windows. I suppose.

pulsar · 11-17-2011, 10:44 AM

The first, 45MiB unallocated space must contain the boot loader and kernel image. Inside the file recovery_backup_signed.zip I found files uramdisk.img, recovery-uramdisk.img, and uImage. Running "files -s" command on these files on Fedora 15, I got this information:

uramdisk.img: u-boot legacy uImage, Android Root Filesystem, Linux/ARM, RAMDisk Image (Not compressed), 182088 bytes, Fri Sep 23 03:38:23 2011, Load Address: 0x90308000, Entry Point: 0x90308000, Header CRC: 0x6CD9AD84, Data CRC: 0xE99D6FFC

recovery-uramdisk.img: u-boot legacy uImage, Android Recovery Filesystem, Linux/ARM, RAMDisk Image (Not compressed), 958829 bytes, Fri Sep 23 03:42:05 2011, Load Address: 0x90308000, Entry Point: 0x90308000, Header CRC: 0x7EE613C2, Data CRC: 0x740C7563

uImage: u-boot legacy uImage, Linux-2.6.35.3, Linux/ARM, OS Kernel Image (Not compressed), 2941580 bytes, Fri Sep 23 02:05:50 2011, Load Address: 0x70008000, Entry Point: 0x70008000, Header CRC: 0x88FC0EBD, Data CRC: 0xD8FC49A0

So uImage is the kernel. All of them are probably located inside the first unallocated space. They are raw images, so presumably they don't need partitions.

pulsar · 11-17-2011, 10:47 AM

Quote:

Originally Posted by spikexp

So that it can be see on windows. I suppose.

Actually, I am reading that the type of partition (e.g. reported by gparted) can be ignored by Android/Linux - it can mount almost any filesystem on almost any type of partition. Command "mount" executed on Kobo shows all of the filesystems of type ext4, even the one inside the partition of type fat32. If you thought it's confusing, I would totally agree.

jefftheworld · 11-17-2011, 02:45 PM

Quote:

Originally Posted by pulsar

Actually, I am reading that the type of partition (e.g. reported by gparted) can be ignored by Android/Linux - it can mount almost any filesystem on almost any type of partition. Command "mount" executed on Kobo shows all of the filesystems of type ext4, even the one inside the partition of type fat32. If you thought it's confusing, I would totally agree.

Yeah, but Windows can't easily mount ext filesystems, so they made this partition fat32 so that both the Vox and a windows computer could easily mount it.

PeterT · 11-17-2011, 06:30 PM

If anyone is interested, more internal pictures are available at the FCC database. Go to Advanced Search; search for Product Code K080 and then select Detail.

jefftheworld · 11-17-2011, 08:06 PM

I'll be taking apart my Vox again this weekend, so I'll post pictures or a video outlining the process of opening it, as well as a few pictures of the internals.

hieronymos · 11-18-2011, 09:50 AM

This document [removed] gives a rough idea how the boot process works for the internal SD. A.k.a. the way to a more-than-reset recovery.

I myself have never used Clockwork Recovery, do I don't know anything. I however believe it would be easier just to do the modifications the apk does directly to the SD.

spikexp · 11-18-2011, 09:55 AM

In the init.rc file, we can see the partition and the mount.
all seem to be ext4 except the fat32 one.
mmcblk0p1 is the system.
mmcblk0p5 is the data.
mmcblk0p6 is the cache.

pulsar · 11-18-2011, 10:44 AM

Are you using adb? I've managed to run adb from a Linux distro over USB. I've found some promising adb commands on this page:

adb reboot
adb bootloader
adb recovery
adb reboot-bootloader

Especially the "adb recovery" - it may very well be functional on Kobo. Just be aware the that recovery*.zip file in mmcblk0p2 contains older binaries (September 23), whereas the current binaries on my Vox are of October 27 (presumably the update when I used Kobo for the first time). I think it still should be okay, to revert to older binaries, as then the Kobo's "update" process should do the upgrade.

hieronymos · 11-18-2011, 10:51 AM

As far as I know, the only thing the recovery does right now is wiping all data (see the recovery log up the page). I don't want to reboot there.

My SD is arriving in a few weeks I'll stop complaining then :-)

Add: made a post over at Cyanogen: http://forum.cyanogenmod.com/topic/3...y-on-kobo-vox/

pulsar · 11-18-2011, 12:17 PM

Interesting - so you believe the bootloader (and kernel?) images are not encrypted (locked) on Kobo? Is there a way to test that?

pulsar · 11-18-2011, 12:22 PM

As an experiment (useful for those who would like to swap their internal SD card for a larger one), I just used Gparted on my Linux box to slightly expand the fat32 partition on my clone micro-SD (even though it is 8GB, but it is larger by 300 MiB than the internal one), by 300MiB. Next time I disassemble my Kobo, I can test if this card still works fine inside Kobo.

11-17-2011, 09:02 AM	#46
hieronymos Groupie Posts: 186 Karma: 45172 Join Date: Nov 2011 Device: Kobo Vox	Maybe I have a very special device then. shrugs. The log for the reset however contains the explanations for your image; the mount table. I'll just dump the whole log here if I may. Somehow it explains the unallocated space. /tmp could probably be on the SD instead of the RAM without any problem - maybe they're still working on that. Spoiler: Build: freescale/imx51_bbg/imx51_bbg:2.3.3/GRI40/eng.CAN.20111027.172304.39765:eng/test-keys Hardware: BBG Bootloader: unknown Radio: unknown Kernel: Linux version 2.6.35.3 (victor@vgonzalez-ubuntu) (gcc version 4.4.3 (GCC) ) K01.01.20110801 Factory data reset 0:Install Success Starting recovery on Wed Nov 16 14:52:16 2011 framebuffer: fd 4 (1024 x 600) recovery filesystem table ========================= 0 /tmp ramdisk (null) (null) 1 /system ext4 /dev/block/mmcblk0p1 (null) 2 /recovery ext4 /dev/block/mmcblk0p2 (null) 3 /sdcard vfat /dev/block/mmcblk0p4 (null) 4 /data ext4 /dev/block/mmcblk0p5 (null) 5 /cache ext4 /dev/block/mmcblk0p6 (null) 6 /misc emmc /dev/block/mmcblk0 (null) 7 /extsd vfat /dev/block/mmcblk1p1 (null) I:Got arguments from boot message Command: "recovery" "--wipe_data" Checking Sideload : E:failed to mount /extsd (No such file or directory) file is not exist Wipe data/cache ro.sf.lcd_density=240 ro.tether.denied=1 ro.config.notification_sound=Razzle.ogg ro.secure=0 ro.allow.mock.location=1 ro.debuggable=0 persist.service.adb.enable=0 ro.factorytest=0 ro.calibration=0 ro.serialno= ro.bootmode=unknown ro.baseband=unknown ro.carrier=unknown ro.bootloader=unknown ro.hardware=freescale ro.revision=332080 init.svc.recovery=running init.svc.boot_count=stopped init.svc.adbd=stopped BATTERY = 100 (0) Formatting /data... format_root return :0Formatting /cache... format_root return :0 I'll go and see what's inside that recovery_backup_signed.zip - maybe I can simply replace a few of the contents with Clockworkmod. P.S.: stevebiggs, probably the internal SD card is too slow to play back 3GB / (the seconds your film takes). Try streaming it from another computer - a 1.8GB file from my UPnP server worked fine here. P.S2: Turn out the recovery .zip is particularly interesting. The only file I can mount is system.img - the other files are in some other format than ext or yaffs or simply are corrupt. System.img contains a bluetooth.apk (indicating it might be the freescale image) and no bloat. Just two kobo files. Last edited by hieronymos; 11-17-2011 at 09:47 AM.

11-17-2011, 10:44 AM	#50
pulsar Connoisseur Posts: 54 Karma: 52416 Join Date: Nov 2011 Device: kindle 3, kobo vox	The first, 45MiB unallocated space must contain the boot loader and kernel image. Inside the file recovery_backup_signed.zip I found files uramdisk.img, recovery-uramdisk.img, and uImage. Running "files -s" command on these files on Fedora 15, I got this information: uramdisk.img: u-boot legacy uImage, Android Root Filesystem, Linux/ARM, RAMDisk Image (Not compressed), 182088 bytes, Fri Sep 23 03:38:23 2011, Load Address: 0x90308000, Entry Point: 0x90308000, Header CRC: 0x6CD9AD84, Data CRC: 0xE99D6FFC recovery-uramdisk.img: u-boot legacy uImage, Android Recovery Filesystem, Linux/ARM, RAMDisk Image (Not compressed), 958829 bytes, Fri Sep 23 03:42:05 2011, Load Address: 0x90308000, Entry Point: 0x90308000, Header CRC: 0x7EE613C2, Data CRC: 0x740C7563 uImage: u-boot legacy uImage, Linux-2.6.35.3, Linux/ARM, OS Kernel Image (Not compressed), 2941580 bytes, Fri Sep 23 02:05:50 2011, Load Address: 0x70008000, Entry Point: 0x70008000, Header CRC: 0x88FC0EBD, Data CRC: 0xD8FC49A0 So uImage is the kernel. All of them are probably located inside the first unallocated space. They are raw images, so presumably they don't need partitions. Last edited by pulsar; 11-17-2011 at 10:48 AM.

11-18-2011, 09:50 AM	#55
hieronymos Groupie Posts: 186 Karma: 45172 Join Date: Nov 2011 Device: Kobo Vox	This document [removed] gives a rough idea how the boot process works for the internal SD. A.k.a. the way to a more-than-reset recovery. I myself have never used Clockwork Recovery, do I don't know anything. I however believe it would be easier just to do the modifications the apk does directly to the SD. Last edited by hieronymos; 11-18-2011 at 01:14 PM.

11-18-2011, 10:51 AM	#58
hieronymos Groupie Posts: 186 Karma: 45172 Join Date: Nov 2011 Device: Kobo Vox	As far as I know, the only thing the recovery does right now is wiping all data (see the recovery log up the page). I don't want to reboot there. My SD is arriving in a few weeks I'll stop complaining then :-) Add: made a post over at Cyanogen: http://forum.cyanogenmod.com/topic/3...y-on-kobo-vox/ Last edited by hieronymos; 11-18-2011 at 12:02 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Touch Hacking into the Kobo Touch	stef70	Kobo Developer's Corner	60	03-04-2017 11:32 AM
Kobo Vox, Kobo preorder	shannont	Kobo Tablets	5	12-17-2012 09:52 PM
What Can the Kobo Vox Do?	pokee	Kobo Tablets	36	11-18-2011 03:00 AM
Where do you use your kobo vox?	ron1959	Kobo Tablets	8	11-04-2011 09:57 PM
Kobo won't read books already in progress	La Coccinelle	Kobo Reader	3	11-29-2010 03:29 PM

11-17-2011, 09:50 AM	#47
pulsar Connoisseur Posts: 54 Karma: 52416 Join Date: Nov 2011 Device: kindle 3, kobo vox	And here's what my Gparted says about my clone SD (it should be identical to the internal SD, except for the bottom unallocated space): Which version of gparted are you using? Mine is 0.9.1, ran under Fedore 15. The differences are that it does reports ext4 for 3 partitions (as Kobo's "mount" command), but it agrees with you on /data being ext2, and KOVOBOX being fat32. Why on earth are they using fat32 on the internal SD card? WHat advantage can it have compared to ext* file systems, given that it is Linux?

11-17-2011, 06:30 PM	#53
PeterT Grand Sorcerer Posts: 13,266 Karma: 78869092 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	If anyone is interested, more internal pictures are available at the FCC database. Go to Advanced Search; search for Product Code K080 and then select Detail.

11-17-2011, 08:06 PM	#54
jefftheworld Groupie Posts: 190 Karma: 157090 Join Date: Nov 2011 Device: Kobo, Kobo Vox	I'll be taking apart my Vox again this weekend, so I'll post pictures or a video outlining the process of opening it, as well as a few pictures of the internals.

11-18-2011, 09:55 AM	#56
spikexp Connoisseur Posts: 88 Karma: 4132 Join Date: Oct 2011 Device: Kobo Vox	In the init.rc file, we can see the partition and the mount. all seem to be ext4 except the fat32 one. mmcblk0p1 is the system. mmcblk0p5 is the data. mmcblk0p6 is the cache.

11-18-2011, 10:44 AM	#57
pulsar Connoisseur Posts: 54 Karma: 52416 Join Date: Nov 2011 Device: kindle 3, kobo vox	Are you using adb? I've managed to run adb from a Linux distro over USB. I've found some promising adb commands on this page: adb reboot adb bootloader adb recovery adb reboot-bootloader Especially the "adb recovery" - it may very well be functional on Kobo. Just be aware the that recovery*.zip file in mmcblk0p2 contains older binaries (September 23), whereas the current binaries on my Vox are of October 27 (presumably the update when I used Kobo for the first time). I think it still should be okay, to revert to older binaries, as then the Kobo's "update" process should do the upgrade.

11-18-2011, 12:17 PM	#59
pulsar Connoisseur Posts: 54 Karma: 52416 Join Date: Nov 2011 Device: kindle 3, kobo vox	Interesting - so you believe the bootloader (and kernel?) images are not encrypted (locked) on Kobo? Is there a way to test that?

11-18-2011, 12:22 PM	#60
pulsar Connoisseur Posts: 54 Karma: 52416 Join Date: Nov 2011 Device: kindle 3, kobo vox	As an experiment (useful for those who would like to swap their internal SD card for a larger one), I just used Gparted on my Linux box to slightly expand the fat32 partition on my clone micro-SD (even though it is 8GB, but it is larger by 300 MiB than the internal one), by 300MiB. Next time I disassemble my Kobo, I can test if this card still works fine inside Kobo.

Advert

Advert