extract initramfs from kindle dx kernel image

chinaet · 08-14-2009, 07:53 AM

Code:

 dd if=/dev/mtd1ro of=uImage bs=1024 count=3584
 dd if=uImage of=img.gz bs=1 skip=$((0x32a0))
 gunzip img.gz
 dd if=img of=initramfs.cpio.gz bs=1 skip=$((0x14a40))

rfog · 08-15-2009, 03:36 AM

Forgive my ignorance of Linux. And what is it for?

chinaet · 08-15-2009, 09:07 AM

Kindle dx kernel embedded initramfs filesystem.just for developer

ebs · 08-16-2009, 04:08 AM

Quote:

Originally Posted by rfog

Forgive my ignorance of Linux. And what is it for?

initramfs is a very basic filesystem which is embedded in kernel image itself. In this particular case it's used as a bootstrap to boot full fs off the NAND flash and the main purpose for this two stage boot is recovery and full update when main fs in NAND gets hosed.

rfog · 08-18-2009, 09:15 AM

Thank you, ebs!

sr105 · 09-23-2009, 01:05 PM

Quote:

Originally Posted by chinaet

Code:

 dd if=/dev/mtd1ro of=uImage bs=1024 count=3584
 dd if=uImage of=img.gz bs=1 skip=$((0x32a0))
 gunzip img.gz
 dd if=img of=initramfs.cpio.gz bs=1 skip=$((0x14a40))

I'm trying to extract an initramfs archive from another image and I'm wondering how you determined those offsets.

Thanks!

choff · 08-20-2010, 04:48 AM

As chinaet already implied, the newer Kindles use an initramfs instead of an initrd. The Kindle's initramfs is linked statically into the Kernel image.

In this post I will describe how I managed to get the uImage from the device and extracted the initramfs from it.

Part 1: Get uImage from device
There are multiple ways to do this. chinaet use /dev/mtd1ro, but you can also fetch a memory dump from U-Boot if you have a serial connection to your Kindle(which will give you bootloader access).

Here are the instructions for fetching the uImage from the boot loader:

Boot your Kindle via serial console and enter U-Boot.

Type "imls" to get a list of all installed images on your device:

Code:

uboot> imls
Image at A0060000:
   Image Name:   s049546-1006081846-TN2.1~2.6.22.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1887264 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
Image at A0400000:
   Image Name:   s049546-1006081846-TN2.1~2.6.22.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1887264 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK

On my Kindle both recovery and normal image were identical, so we only have to get a dump of one of those images.
First, change the address offset to the address of one of those kernel images (I used image 1):
Code:
```
uboot> base A0060000
Base Address: 0xa0060000
```

To check the base address, let's display the u-Boot header of the image at this position:

Code:

uboot> md.b 0 40
a0060000: 27 05 19 56 07 97 c8 68 4c 0e f6 88 00 1c cc 20    '..V...hL...... 
a0060010: 80 00 80 00 80 00 80 00 6b 87 43 35 05 02 02 00    ........k.C5....
a0060020: 73 30 34 39 35 34 36 2d 31 30 30 36 30 38 31 38    s049546-10060818
a0060030: 34 36 2d 54 4e 32 2e 31 7e 32 2e 36 2e 32 32 2e    46-TN2.1~2.6.22.

md.b will display the memory from address 0x0 to 0x40 relative to the base address. If your are interested in the U-Boot header format, look at include/image.h in the U-Boot sources(included in Amazon's source code release).

imls(or the above memory dump of the header) will give you the data size of your image. In my case, the data size is 1887264=0x001ccc20 Bytes.
Add 64 Bits(the size of the header) to the data size and you get the size of your uImage.
Now we will pull a dump of the whole uImage via the serial line. Minicom has a nice capture mode which can be enabled by typing CTRL-A, then Z and then L.
After you have started capturing, we can get us the dump:
Code:
```
md.b 0 {size of uImage in hex, see above}
```
And then allow some time to pass for the transmission(about 15 Mins).
Now for the difficult part: First of all, stop capturing by pressing the same keys in Minicom again.
Then let's have a look at your captured file. It should look something like this:
Code:
```
uboot> md.b 0 1ccc60
a0060000: 27 05 19 56 07 97 c8 68 4c 0e f6 88 00 1c cc 20    '..V...hL...... 
{very many lines}
a022cc50: 44 4c 1d 00 00 00 00 00 00 00 00 00 00 00 00 00    DL..............
```
Delete everything from the file that does not belong to the dump(in my case that would be the first line).
Now that we have the uImage as memory dump, it would be nice to convert this output into a real file.
I have written a C program which does this task for you(attached), but you still need to compile it with gcc or an IDE. I am too lazy too look up how to do this from command line via gcc, but there are probably tons of info on this in the internet.
Now you can run the whole thing:
Code:
```
./UBootMemeryDumpParser {path to dumpfile} > uImage
```
It will probably complain about a few errors in you dump, but this is normal. Just use "base" from u-boot to jump to the address in the incorrect line and "md.b" to get the few wrong bytes. This way you can replace wrong lines in your dump without needing to get an entirely new copy of the uImage dump.
Test if your image is valid:
Code:
```
mkimage -l uImage
```
. If not, you will have to get the whole dump again(or did you forget to add the 64 Bits of the U-Boot header to the data size when running md.b?)

Part 2: Extract initramfs from uImage

Don't worry, the rest is easy once you know how to do it. First of all, we need to extract the zImage from the uImage by stripping the 64-bytes uImage header:
Code:
```
dd if=uImage of=zImage bs=1 skip=64
```
Now let's uncompress the zImage.
Code:
```
grep -P -a -b --only-matching $'\x1f\x8b\x08\x00' < zImage
12896:�
```
will search for the zcat header(in my case at position 12896).
Then
Code:
```
dd if=zImage bs={number from above command} skip=1 | zcat - > Image
```
will give you the uncompressed image.
Now we use
Code:
```
grep -P -a -b --only-matching $'\x1f\x8b\x08' < Image
84448:�
2639420:�
```
to determine the start of the initramfs by searching for the gzip-header. Only the first number is interesting.
So now we can fetch the initramfs:
Code:
```
dd bs={your first number, in my case 84448} if=Image skip=1 | gzip -d -c > initramfs.cpio
```
Now extract initramfs.cpio. If you want to have device nodes created, make sure you do it as root:
Code:
```
sudo cpio -i --no-absolute-filenames < ../initramfs.cpio
```

yifanlu · 08-22-2010, 11:00 PM

I don't know which kindle version you're working with, but for extracting The uImage, all I had to do was download a fw upgrade from amazon, extract it, open the firmware upgrade script in a text editor and look at how it backs up the script (offsets are given in script). Or even easier (if you know how to use dd, view /test/firmware-tools/flash-kernel-1.sh (or something), get the offsets, and use dd from SSH.

choff · 08-23-2010, 04:34 AM

Quote:

Originally Posted by yifanlu

I don't know which kindle version you're working with, but for extracting The uImage, all I had to do was download a fw upgrade from amazon, extract it, open the firmware upgrade script in a text editor and look at how it backs up the script (offsets are given in script). Or even easier (if you know how to use dd, view /test/firmware-tools/flash-kernel-1.sh (or something), get the offsets, and use dd from SSH.

Yeah everything could have been really easy if I hadn't busted my Kindle

I fiddled with the root filesystem until all of a sudden my Kindle wouldn't boot any more. Since there are no firmware updates for the DXG out yet, all I could do was get the uImage from U-Boot directly.

I modified the initramfs a bit in order to mount a filesystem image on the large 3Gb USB-accessible partition and was able to get a regular Debian Linux to run, but I will blog about that later when everything is up and running.

scenox · 08-23-2010, 01:57 PM

Quote:

Originally Posted by choff

I modified the initramfs a bit in order to mount a filesystem image on the large 3Gb USB-accessible partition and was able to get a regular Debian Linux to run, but I will blog about that later when everything is up and running.

nice, looking forward to it!

twobob · 10-24-2012, 08:04 PM

Quote:

Originally Posted by choff

As chinaet already implied, the newer Kindles use an initramfs instead of an initrd. The Kindle's initramfs is linked statically into the Kernel image.

In this post I will describe how I managed to get the uImage from the device and extracted the initramfs from it.

Part 1: Get uImage from device
There are multiple ways to do this. chinaet use /dev/mtd1ro, but you can also fetch a memory dump from U-Boot if you have a serial connection to your Kindle(which will give you bootloader access).

Here are the instructions for fetching the uImage from the boot loader:

Boot your Kindle via serial console and enter U-Boot.

Type "imls" to get a list of all installed images on your device:

Code:

uboot> imls
Image at A0060000:
   Image Name:   s049546-1006081846-TN2.1~2.6.22.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1887264 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
Image at A0400000:
   Image Name:   s049546-1006081846-TN2.1~2.6.22.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1887264 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK

On my Kindle both recovery and normal image were identical, so we only have to get a dump of one of those images.
First, change the address offset to the address of one of those kernel images (I used image 1):
Code:
```
uboot> base A0060000
Base Address: 0xa0060000
```

To check the base address, let's display the u-Boot header of the image at this position:

Code:

uboot> md.b 0 40
a0060000: 27 05 19 56 07 97 c8 68 4c 0e f6 88 00 1c cc 20    '..V...hL...... 
a0060010: 80 00 80 00 80 00 80 00 6b 87 43 35 05 02 02 00    ........k.C5....
a0060020: 73 30 34 39 35 34 36 2d 31 30 30 36 30 38 31 38    s049546-10060818
a0060030: 34 36 2d 54 4e 32 2e 31 7e 32 2e 36 2e 32 32 2e    46-TN2.1~2.6.22.

md.b will display the memory from address 0x0 to 0x40 relative to the base address. If your are interested in the U-Boot header format, look at include/image.h in the U-Boot sources(included in Amazon's source code release).

imls(or the above memory dump of the header) will give you the data size of your image. In my case, the data size is 1887264=0x001ccc20 Bytes.
Add 64 Bits(the size of the header) to the data size and you get the size of your uImage.
Now we will pull a dump of the whole uImage via the serial line. Minicom has a nice capture mode which can be enabled by typing CTRL-A, then Z and then L.
After you have started capturing, we can get us the dump:
Code:
```
md.b 0 {size of uImage in hex, see above}
```
And then allow some time to pass for the transmission(about 15 Mins).
Now for the difficult part: First of all, stop capturing by pressing the same keys in Minicom again.
Then let's have a look at your captured file. It should look something like this:
Code:
```
uboot> md.b 0 1ccc60
a0060000: 27 05 19 56 07 97 c8 68 4c 0e f6 88 00 1c cc 20    '..V...hL...... 
{very many lines}
a022cc50: 44 4c 1d 00 00 00 00 00 00 00 00 00 00 00 00 00    DL..............
```
Delete everything from the file that does not belong to the dump(in my case that would be the first line).
Now that we have the uImage as memory dump, it would be nice to convert this output into a real file.
I have written a C program which does this task for you(attached), but you still need to compile it with gcc or an IDE. I am too lazy too look up how to do this from command line via gcc, but there are probably tons of info on this in the internet.
Now you can run the whole thing:
Code:
```
./UBootMemeryDumpParser {path to dumpfile} > uImage
```
It will probably complain about a few errors in you dump, but this is normal. Just use "base" from u-boot to jump to the address in the incorrect line and "md.b" to get the few wrong bytes. This way you can replace wrong lines in your dump without needing to get an entirely new copy of the uImage dump.
Test if your image is valid:
Code:
```
mkimage -l uImage
```
. If not, you will have to get the whole dump again(or did you forget to add the 64 Bits of the U-Boot header to the data size when running md.b?)

Part 2: Extract initramfs from uImage

Don't worry, the rest is easy once you know how to do it. First of all, we need to extract the zImage from the uImage by stripping the 64-bytes uImage header:
Code:
```
dd if=uImage of=zImage bs=1 skip=64
```
Now let's uncompress the zImage.
Code:
```
grep -P -a -b --only-matching $'\x1f\x8b\x08\x00' < zImage
12896:�
```
will search for the zcat header(in my case at position 12896).
Then
Code:
```
dd if=zImage bs={number from above command} skip=1 | zcat - > Image
```
will give you the uncompressed image.
Now we use
Code:
```
grep -P -a -b --only-matching $'\x1f\x8b\x08' < Image
84448:�
2639420:�
```
to determine the start of the initramfs by searching for the gzip-header. Only the first number is interesting.
So now we can fetch the initramfs:
Code:
```
dd bs={your first number, in my case 84448} if=Image skip=1 | gzip -d -c > initramfs.cpio
```
Now extract initramfs.cpio. If you want to have device nodes created, make sure you do it as root:
Code:
```
sudo cpio -i --no-absolute-filenames < ../initramfs.cpio
```

Kudos for this info. Eternally Helpful.

knc1 · 10-24-2012, 08:11 PM

Looks very familar:
http://minimodding.com/BinaryDecomposition

With minor changes in the choice of binary search commands.
But that is *nix in general, there are always multiple ways to do the same thing.

twobob · 10-24-2012, 08:38 PM

Quote:

Originally Posted by knc1

Looks very familar:
http://minimodding.com/BinaryDecomposition

With minor changes in the choice of binary search commands.
But that is *nix in general, there are always multiple ways to do the same thing.

Excellent. two references is always better than one. and three... well don't get me excited.

knc1 · 10-24-2012, 08:51 PM

Three?
OK, here is the third:
http://minimodding.com/FirmwareComparison

- - - -

It has been years since I had a real life.

kocoman · 04-19-2013, 02:28 AM

Has anyone edited the cpio initramfs file directly and then embed it back into the kernel and have it still work?

08-14-2009, 07:53 AM	#1
chinaet Member Posts: 14 Karma: 84 Join Date: Sep 2006 Device: iliad Kindle DX	extract initramfs from kindle dx kernel image Code: dd if=/dev/mtd1ro of=uImage bs=1024 count=3584 dd if=uImage of=img.gz bs=1 skip=$((0x32a0)) gunzip img.gz dd if=img of=initramfs.cpio.gz bs=1 skip=$((0x14a40)) Last edited by chinaet; 08-23-2009 at 06:12 PM.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Compiling the Linux Kernel for the Kindle	yifanlu	Kindle Developer's Corner	82	12-12-2016 09:35 PM
Image sizes in Kindle	chrisborg	Amazon Kindle	2	05-17-2010 01:49 AM
Image optimization for Kindle 2	thelostemperor	Amazon Kindle	10	03-13-2009 05:34 PM
Observations from Kindle 2 kernel sources	TadW	Kindle Developer's Corner	3	03-13-2009 05:29 PM
[REQ] Extract the first PDF page as image	Format C:	PDF	2	02-09-2009 10:53 AM

08-15-2009, 03:36 AM	#2
rfog Guru Posts: 694 Karma: 2383012 Join Date: Aug 2007 Location: Schiedam (The Netherlands) Device: Lots of eInk devices and iOS stuff	Forgive my ignorance of Linux. And what is it for?

08-15-2009, 09:07 AM	#3
chinaet Member Posts: 14 Karma: 84 Join Date: Sep 2006 Device: iliad Kindle DX	Kindle dx kernel embedded initramfs filesystem.just for developer

08-18-2009, 09:15 AM	#5
rfog Guru Posts: 694 Karma: 2383012 Join Date: Aug 2007 Location: Schiedam (The Netherlands) Device: Lots of eInk devices and iOS stuff	Thank you, ebs!

08-22-2010, 11:00 PM	#8
yifanlu Kindle Dissector Posts: 662 Karma: 475607 Join Date: Jul 2010 Device: Amazon Kindle 3	I don't know which kindle version you're working with, but for extracting The uImage, all I had to do was download a fw upgrade from amazon, extract it, open the firmware upgrade script in a text editor and look at how it backs up the script (offsets are given in script). Or even easier (if you know how to use dd, view /test/firmware-tools/flash-kernel-1.sh (or something), get the offsets, and use dd from SSH.

10-24-2012, 08:11 PM	#12
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Looks very familar: http://minimodding.com/BinaryDecomposition With minor changes in the choice of binary search commands. But that is *nix in general, there are always multiple ways to do the same thing.

10-24-2012, 08:51 PM	#14
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Three? OK, here is the third: http://minimodding.com/FirmwareComparison - - - - It has been years since I had a real life.

04-19-2013, 02:28 AM	#15
kocoman Connoisseur Posts: 97 Karma: 28464 Join Date: Dec 2006	Has anyone edited the cpio initramfs file directly and then embed it back into the kernel and have it still work?

Advert

Advert