View Single Post
Old 04-09-2016, 03:32 PM   #8
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Extraction of the 2.5.4 initramfs

My notes on how I got the file attachments out of the 2.5.4 uImage file.
Only for the truely bored, with nothing else to read.
Spoiler:

Copy all after the uImage header:
Code:
NOR $ dd if=uImage-1 of=kImage-1 bs=64 skip=1
29488+1 records in
29488+1 records out
1887240 bytes (1.9 MB) copied, 0.114397 s, 16.5 MB/s
At the time this kernel+initramfs binary was built, the most commonly used compression was gzip.
So check for gzip signature:
Code:
NOR $ od -A d -t x1 kImage-1 | grep '1f 8b 08 00'
0012896 1f 8b 08 00 45 5d 21 4c 02 03 9c bd 0d 78 54 c5
That 12,896 bytes is too small to be the expected kernel, so we have a different than expected composite file here.

From the console port messages, this system uses a self-extracting, compressed kernel, so the first part is the decompressor.
Copy out the compressor part of the image:
Code:
NOR $ dd if=kImage-1 of=compressor-1 bs=32 count=403
403+0 records in
403+0 records out
12896 bytes (13 kB) copied, 0.00157493 s, 8.2 MB/s
Copy out everything after the de-compressor:
Code:
NOR $ dd if=kImage-1 of=payload-1 bs=32 skip=403
58573+1 records in
58573+1 records out
1874344 bytes (1.9 MB) copied, 0.225707 s, 8.3 MB/s
Check that second part:
Code:
NOR $ file payload-1
ramfs-1: gzip compressed data, from Unix, last modified: Tue Jun 22 20:03:01 2010, max compression
A rename and a bit of zcat so we have a copy of both the compressed and non-compressed ramfs binary.
Code:
NOR $ mv payload-1 payload-1.gz
NOR $ zcat payload-1.gz payload-1

gzip: payload-1.gz: decompression OK, trailing garbage ignored
That 'trailing garbage' may be something that we need.
But to continue on blindly - -

Check the output file:
Code:
NOR $ file payload-1
payload-1: data
Data? Well, strings shows that we have finally reached the kernel.
See if there are any more attachments:
Code:
NOR $ od -A d -t x1 payload-1 | grep '1f 8b 08 00'
0084448 1f 8b 08 00 3f 5d 21 4c 02 03 bc 5b 0d 4c 5c 57
2639344 00 00 00 00 49 4b 43 46 47 5f 53 54 1f 8b 08 00
Two of them:

First part:
Code:
NOR $ dd if=payload-1 of=payload-1a bs=4 count=21112
21112+0 records in
21112+0 records out
84448 bytes (84 kB) copied, 0.0801735 s, 1.1 MB/s
Middle part:
Code:
NOR $ dd if=payload-1 of=payload-1b bs=4 skip=21112 count=638724
638724+0 records in
638724+0 records out
2554896 bytes (2.6 MB) copied, 2.4713 s, 1.0 MB/s
Check it:
Code:
NOR $ file payload-1b
payload-1b: gzip compressed data, from Unix, last modified: Tue Jun 22 20:02:55 2010, max compression
Give it the proper extension:
Code:
NOR $ mv payload-1b payload-1b.gz
Last part:
Code:
NOR $ dd if=payload-1 of=payload-1c bs=4 skip=659839
171309+0 records in
171309+0 records out
685236 bytes (685 kB) copied, 0.646588 s, 1.1 MB/s
Check it:
Code:
NOR $ file payload-1c
payload-1c: gzip compressed data, from Unix, last modified: Tue Jun 22 19:49:33 2010, max compression
Fix the extension:
Code:
NOR $ mv payload-1c payload-1c.gz
Which should have split "payload-1" into a kernel and its two attachments:
Where/What/Why/How those extra 12 bytes got into the mess ...
Will deal with that later, if it becomes a problem.

Un-compress and check:
Code:
NOR $ zcat payload-1b.gz >payload-1b
gzip: payload-1b.gz: decompression OK, trailing garbage ignored

NOR $ file payload-1b
payload-1b: ASCII cpio archive (SVR4 with no CRC)
That is the initial file system we are looking for.
Code:
NOR $ zcat payload-1c.gz >payload-1c
gzip: payload-1c.gz: decompression OK, trailing garbage ignored

NOR $ file payload-1c
payload-1c: ASCII text
NOR $ less payload-1c
And that is the configuration file the kernel was built with.

Turn that archive back into a file system:
Code:
NOR $ mkdir initramfs-2.5.4
NOR $ cd initramfs-2.5.4
initramfs-2.5.4 $ sudo cpio -i -d -m --no-absolute-filenames -I ../payload-1b
cpio: Removing leading `/' from member names
2012 blocks

initramfs-2.5.4 $ ls -l
total 28
drwxr-xr-x 2 61967  502 4096 2016-04-09 13:59 bin
drwxr-xr-x 7 root  root 4096 2016-04-09 13:59 dev
lrwxrwxrwx 1 root  root   18 2016-04-09 13:59 init -> /bin/recovery-util
drwxr-xr-x 3 61967  502 4096 2016-04-09 13:59 lib
drwxr-xr-x 2 root  root 4096 2010-06-22 20:02 proc
drwx------ 2 root  root 4096 2010-06-22 20:02 root
drwxr-xr-x 2 61967  502 4096 2010-06-22 20:02 sbin
drwxr-xr-x 2 root  root 4096 2010-06-22 20:02 sys

initramfs-2.5.4 $ ls -l bin/recovery-util
-rwxr-xr-x 1 61967 502 189651 2010-06-22 20:02 bin/recovery-util

initramfs-2.5.4 $ file bin/recovery-util
bin/recovery-util: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked (uses shared libs), not stripped


They (lab126) went to all of that trouble to compress everything multiple times (which only makes things bigger than the first compression) and yet they included the configuration file and failed to strip the compiled binaries of the unneeded symbol tables.

The interesting parts are attached below (they are GPLv2, just like the kernel because they where statically linked with the kernel).
Attached Files
File Type: gz initramfs-2.5.4.tar.gz (510.7 KB, 160 views)
File Type: gz config.gz (7.7 KB, 175 views)
knc1 is offline   Reply With Quote