09-01-2012, 07:40 PM | #1 |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
Edit: [SOLVED] see Post #5
I've extracted the root file system from raw data. However, after recompressing the image and putting it back on disk, the T1 refuses to start up. Why? Here is what I did: Code:
# making a backup of the compressed root fs image dd if=/dev/mmcblk2 of=../rootfs.img.gz bs=1 skip=5242944 count=1048512 # extracting root fs gunzip -c ../rootfs.img.gz | cpio -i # re-creating compressed image find . | cpio -o -H newc | gzip > ../newrootfs.img.gz # applying new image dd if=../newrootfs.img.gz of=/dev/mmcblk2 bs=1 seek=5242944 The funny thing is when applying the backup, the T1 re-initializes (asking for language and time), so it is aware something has changed. Last edited by e-ink; 09-04-2012 at 12:40 AM. Reason: Changed to [SOLVED] |
09-01-2012, 07:43 PM | #2 |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
Here is a little background:
Going by this Guide (where I got most info from) the compressed image of Androids root file system is part of a boot image residing on a partition. The T1 however seems to follow a different approach with a stand-alone root fs image in form of raw data on the unpartitioned area. Code:
cat /sys/module/rawdatatable/parameters/rawdata_param MBR :0x00000000:0x00000400 uBoot :0x00000400:0x000bfc00 Boot Env :0x000c0000:0x00020000 Reserved1 :0x000e0000:0x00020000 Normal Kernel :0x00100000:0x00400000 Normal Rootfs :0x00500000:0x00100000 Recovery Kernel :0x00600000:0x00400000 Reserved2 :0x00a00000:0x00500000 Normal Boot Env :0x00f00000:0x00020000 Recovery Boot Env :0x00f20000:0x00020000 Raw Data Table :0x00f40000:0x00020000 Info :0x00f60000:0x00020000 Id :0x00f80000:0x00020000 Reserved3 :0x00fa0000:0x00060000 Boot Image :0x01000000:0x00100000 Waveform :0x01100000:0x00200000 LOG :0x01300000:0x00500000 |
09-02-2012, 03:17 PM | #3 |
Senior Altruist
Posts: 82
Karma: 600554
Join Date: Jun 2012
Device: Onyx Boox C67ML, Onyx Boox Note Pro
|
I haven't tried this myself and haven't looked closely into it, but I wouldn't be surprised if the T1 uses some form of secure booting, aka locked bootloader; most Android devices do. This typically works by having a trust chain among boot components, one element of which could be that the boot loader verifies the integrity of the root partition using a checksum or a signature.
|
09-02-2012, 04:06 PM | #4 |
Evangelist
Posts: 425
Karma: 75216
Join Date: Nov 2011
Location: old europe
Device: Kobo Mini, Tolino Epos 2
|
I also suspect that there is some checksum mismatch.
In the info area, you'll find an RSA key which is used to check update images if they can be trusted, maybe there are also MD5 checksums somewhere... |
09-03-2012, 06:26 PM | #5 |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
Solved:
The image is actually a special uboot ramdisk image. This format adds a header containing a CRC32 checksum to the compressed image. In the above example, the new image is used in combination with the old headers. Not good This is better (we need mkimage): Warning: Don't apply any of those commands if you don't understand what they are doing. You can easily make you're device unbootable. The commands are partly transcribed without further testing. I can't guarantee that they will work as expected Code:
# create & change directory to where we extract the files later on mkdir ~/rootfs && cd ~/rootfs # for safety reasons back up the whole root fs area (including uboot headers) dd if=/dev/mmcblk2 of=../rootfs.img bs=1 skip=5242880 count=1048576 # copy the compressed root fs image (without uboot headers) dd if=/dev/mmcblk2 of=../rootfs.img.gz bs=1 skip=5242944 count=1048512 # extract root fs gunzip -c ../rootfs.img.gz | cpio -i Code:
# re-create compressed image find . | cpio -o -H newc | gzip > ../newrootfs.img.gz # convert into special uboot format (adding headers to image) mkimage -A arm -O linux -C gzip -T ramdisk -n "Normal Rootfs" -a 0x500040 -e 0x500040 -d ../newrootfs.img.gz ../newrootfs.img # apply new image (make sure size of newrootfs.img ≤ rootfs.img) # you also might wanna consider zeroing out the rootfs area before applying the new image to make sure there are no leftovers dd if=../newrootfs.img of=/dev/mmcblk2 bs=1 seek=5242880 P.S. It smells like the kernel is of the same uboot format and could be changed the same way. Last edited by e-ink; 09-03-2012 at 11:04 PM. Reason: accidentally clicked submit while still creating this post |
09-04-2012, 05:40 AM | #6 |
Senior Altruist
Posts: 82
Karma: 600554
Join Date: Jun 2012
Device: Onyx Boox C67ML, Onyx Boox Note Pro
|
This is fantastic, thanks a lot e-ink!
|
09-04-2012, 09:27 PM | #7 | |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
Thank you too people for pointing in the right direction!
Quote:
Btw do you know how to convert the raw data into plain text? I was messing with hexdump, cpio, bc & xxd and even piping them together but gave up after a while. It would be quite useful to get a proper dump of the log area too. |
|
09-05-2012, 02:14 AM | #8 |
Senior Altruist
Posts: 82
Karma: 600554
Join Date: Jun 2012
Device: Onyx Boox C67ML, Onyx Boox Note Pro
|
Which data do you want to convert to ASCII, and into which target format? What's wrong with hexdump or od? Man pages are your friend… I routinely use “od -Ax -tx4 -tc” to dump both hex and ASCII data. Alternatively, I like using Emacs' hexl-mode for looking at binary data, but that becomes unwieldy if the data doesn't fit into memory.
You can dump the log area with the pastlog command installed on the Reader. |
09-05-2012, 01:25 PM | #9 |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
My bad. I was viewing the rsa key with hexdump, although it is stored in ascii. A simple dd prints it properly.
Thanks for the pastlog hint. Very convenient! |
09-05-2012, 02:06 PM | #10 |
Evangelist
Posts: 425
Karma: 75216
Join Date: Nov 2011
Location: old europe
Device: Kobo Mini, Tolino Epos 2
|
Great that it worked for you. I read about mkimage / cpio some time ago, but didn't remember. Here's the link:
https://www.mobileread.com/forums/sho...0&postcount=13 BTW - there are also means to extract the contents of official sony firmware updates by using shell functions included on the reader: https://www.mobileread.com/forums/sho...d.php?t=166871 http://projects.mobileread.com/reade...an/PRST1/tools |
09-05-2012, 05:20 PM | #11 |
partly refreshed
Posts: 36
Karma: 3026
Join Date: Aug 2012
Device: It's a Sony :P prs-t1
|
Interesting reads, thank you! Who would expect mkimage in a fsck / fix_perm thread
About replacing the kernel, can anyone confirm the following 2 assumptions? Recovery Console runs the following kernel Code:
Recovery Kernel :0x00600000:0x00400000 Recovery Console can still be booted if the following is damaged or missing Code:
Normal Kernel :0x00100000:0x00400000 |
Tags |
prs-t1, ramdisk, rootfs, uboot |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
PRS-T1 Can't root/un-root/use SD Rescue/boot into Recovery Console | bookp | Sony Reader Dev Corner | 6 | 03-07-2016 03:22 AM |
Altering search function on Kindle | jonalbert | Sigil | 2 | 01-14-2011 04:16 PM |
Development Alternate root method / "1-click root" | Oneiros | enTourage Archive | 0 | 09-06-2010 02:04 PM |
Save to Disk altering Title and Series | RichieTheK | Calibre | 9 | 08-21-2010 05:19 PM |
Is Google altering our mental habits (in a BAD way)? | Alexander Turcic | Lounge | 36 | 06-16-2008 03:44 PM |