[Android Software/Hacking General [Developers Only]] k02a:
Abstract

This tutorial will debug a corrupted boot.img and is an answer to a question/request.

Background

I took the time to look at a corrupted boot.img, posted on the HTC One X forum [1].

Since the Android boot image structure is general for all devices,

I thought this could be of some help for all of you who is trying to find out why your boot.img doesn't work.

Downloading, hashing, and unpacking the helpingehsan.rar file.

The MD5 hash sum of the original rar-file is of course not necessary...

j@akleja:~$ j@akleja:~$ mkdir helpingehsan; cd helpingehsan; wget https://dl.dropbox.com/s/72wgogz9ll62s0w/ helpingehsan.rar?dl=1 -O helpingehsan.rar; md5sum helpingehsan.rar; rar x helpingehsan.rar; ls -la
--2012-09-16 21:46:06-- https://dl.dropbox.com/s/72wgogz9ll62s0w/helpingehsan.rar?dl=1
Resolving dl.dropbox.com (dl.dropbox.com)... 23.23.133.20, 50.19.106.181, 107.20.134.222, ...
Connecting to dl.dropbox.com (dl.dropbox.com)|23.23.133.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17250294 (16M) [application/rar]
Saving to: 'helpingehsan.rar'

100%[=====================================================>] 17,250,294 1.01MB/s in 21s

2012-09-16 21:46:29 (807 KB/s) - 'helpingehsan.rar' saved [17250294/17250294]

ea9840823ad5cf2b865a4eb5be86eb5d helpingehsan.rar

RAR 4.20 Copyright (c) 1993-2012 Alexander Roshal 9 Jun 2012
Trial version Type RAR -? for help

Extracting from helpingehsan.rar

Extracting boot.img OK
Extracting boot.img-kernel.gz OK
Extracting ramdisk.cpio.gz OK
All OK
total 37636
drwxr-xr-x 2 j users 4096 Sep 16 21:46 ./
drwx--x--x 34 j users 4096 Sep 16 21:46 ../
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
-rw-r--r-- 1 j users 4104448 Sep 2 08:48 boot.img-kernel.gz
-rw-r--r-- 1 j users 17250294 Sep 16 21:46 helpingehsan.rar
-rw-r--r-- 1 j users 8781519 Sep 2 08:51 ramdisk.cpio.gz

Initial preview

At a first look, the boot.img looks suspicioucly big for being a boot image.

The ramdisk.cpio.gz is also even greater than the boot.img, while the compressed kernel seems to have a realistic size.

Dumping the boot.img start with a hex editor reveals that the real header seems to start at offset 0x100 (256 bytes) and

the initial data seems to be irrelevant junk.

j@akleja:~/helpingehsan$ ls -la boot.img; hexdump -C -n 2048 boot.img
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
00000000 51 16 28 f1 d1 b4 ae 77 fa 56 1f 79 49 ef cf a3 |Q.(ñÑ´®wúV.yIïÏ£|
00000010 92 4e ef 25 61 15 6f fe 80 9a b3 16 05 dd b8 87 |.Nï%a.oþ..³..Ý¸.|
00000020 88 d5 1c b1 5d fa 45 1a b4 2a b4 20 d7 e8 e3 84 |.Õ.±]úE.´*´ ×èã.|
00000030 62 a6 41 eb 83 3c 35 77 e3 44 31 6c 34 73 8a 57 |b¦Aë.<5wãD1l4s.W|
00000040 3d ba c0 dc 74 fe 5a 9d bd a1 da bd 20 f6 16 89 |=ºÀÜtþZ.½¡Ú½ ö..|
00000050 d4 ef 97 50 e5 46 f0 fc c5 07 af 13 14 b4 35 de |Ôï.PåFðüÅ.¯..´5Þ|
00000060 4f c8 c1 bd dc 05 67 95 85 76 70 63 88 eb 15 ea |OÈÁ½Ü.g..vpc.ë.ê|
00000070 7d da ac ad 6d c7 44 78 73 d3 8d 1b 37 ad cc 73 |}Ú¬*mÇDxsÓ..7*Ìs|
00000080 d5 a5 d6 e9 6d 0c 05 0a 64 49 d6 65 b3 98 f4 67 |Õ¥Öém...dIÖe³.ôg|
00000090 9c e1 90 64 c6 92 75 dc 55 fd da e5 c3 3c 35 d0 |.á.dÆ.uÜUýÚåÃ<5Ð|
000000a0 e5 7a 92 d5 e8 5f 65 8f f7 77 69 11 72 a6 f8 82 |åz.Õè_e.÷wi.r¦ø.|
000000b0 ee ad cc ad 2a 62 55 11 89 eb 4d dd 74 f2 f1 5b |î*Ì**bU..ëMÝtòñ[|
000000c0 ee 93 05 fe 94 b4 d8 28 09 2c 9b d1 3a d8 1e 60 |î..þ.´Ø(.,.Ñ:Ø.`|
000000d0 89 52 9e f9 3f ea af b5 c0 d0 b6 60 51 ba b6 ab |.R.ù?ê¯µÀÐ¶`Qº¶«|
000000e0 41 ab ab 1b e0 06 a3 ca bb 37 6f aa eb b6 6f c3 |A««.à.£Ê»7oªë¶oÃ|
000000f0 26 fa 28 f7 48 55 10 83 42 4e 02 37 9f be 5f d7 |&ú(÷HU..BN.7.¾_×|
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110 7c 8a 04 00 00 00 00 11 00 00 00 00 00 00 f0 10 ||.............ð.|
00000120 00 01 00 10 00 08 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000340 bf f4 50 e5 45 4b 2d 1b 13 40 2a be 0d fe 25 2e |¿ôPåEK-..@*¾.þ%.|
00000350 2b ef b4 07 00 00 00 00 00 00 00 00 00 00 00 00 |+ï´.............|
00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800

Kernel image analysis

Next up to be analysed is the compressed kernel image, a zImage file.

Also in this case, the image starts at offset 0x100.

The first 256 bytes are zeros and should be chopped off to work as a kernel image.

j@akleja:~/helpingehsan$ hexdump -C -n 512 boot.img-kernel.gz
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 |..*á..*á..*á..*á|
*
00000120 02 00 00 ea 18 28 6f 01 00 00 00 00 b0 9b 3e 00 |...ê.(o.....°.>.|
00000130 01 70 a0 e1 02 80 a0 e1 00 20 0f e1 03 00 12 e3 |.p*á..*á. .á...ã|
00000140 01 00 00 1a 17 00 a0 e3 56 34 12 ef 00 20 0f e1 |......*ãV4.ï. .á|
00000150 c0 20 82 e3 02 f0 21 e1 00 00 00 00 00 00 00 00 |À .ã.ð!á........|
00000160 44 47 9f e5 45 00 00 eb ec 00 8f e2 4e 1a 90 e8 |DG.åE..ëì..âN..è|
00000170 1c d0 90 e5 01 00 40 e0 00 60 86 e0 00 d0 8d e0 |.Ð.å..@à.`.à.Ð.à|
00000180 01 a8 8d e2 01 a9 8a e2 0a 00 54 e1 15 00 00 2a |.¨.â.©.â..Tá...*|
00000190 09 a0 84 e0 0f 00 5a e1 12 00 00 9a 02 ab 8a e2 |.*.à..Zá.....«.â|
000001a0 ff a0 ca e3 44 50 4f e2 1f 50 c5 e3 05 90 46 e0 |ÿ*ÊãDPOâ.PÅã..Fà|
000001b0 1f 90 89 e2 1f 90 c9 e3 05 60 89 e0 0a 90 89 e0 |...â..Éã.`.à...à|
000001c0 0f 5c 36 e9 05 00 56 e1 0f 5c 29 e9 fb ff ff 8a |.\6é..Vá.\)éûÿÿ.|
000001d0 06 60 49 e0 06 d0 8d e0 48 01 00 eb 7c 00 4f e2 |.`Ià.Ð.àH..ë|.Oâ|
000001e0 06 00 80 e0 00 f0 a0 e1 00 00 30 e3 08 00 00 0a |...à.ð*á..0ã....|
000001f0 00 b0 8b e0 00 c0 8c e0 00 20 82 e0 00 30 83 e0 |.°.à.À.à. .à.0.à|
00000200

Ramdisk image analysis

The last file is the gnuzipped ramdisk. A quick analysis of its header indicates that it seems to be fine.

The first two bytes (1f 8b) gives a hint of a gzip file [3].

j@akleja:~/helpingehsan$ hexdump -C -n 32 ramdisk.cpio.gz
00000000 1f 8b 08 00 7a 80 43 50 00 03 bc 3c 6b 6f db b8 |....z.CP..¼<koÛ¸|
00000010 b2 fb b5 f9 15 44 83 7b ef 2e ce ca b2 9d a4 e9 |²ûµù.D.{ï.ÎÊ².¤é|
00000020

An unpack of the huge ramdisk is necessary to better get an idea of its content.

j@akleja:~/helpingehsan$ mkdir ramdisk; cd ramdisk; gunzip -c ../ramdisk.cpio.gz | cpio -i; ls -al
25487 blocks
total 12272
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*

No wonder why the size!

The ramdisk contains even more you could wish for - and an incorrect directory structure.

By hashing the boot.img and the boot.img-kernel.gz in the compressed ramdisk

and comparing them with the included images in the helpingehsan.rar

will tell if those files are identical - which seems to be the case.

The only conlusion to make is that something went wrong.

j@akleja:~/helpingehsan/ramdisk$ md5sum ../boot.img boot.img ../boot.img-kernel.gz boot.img-kernel.gz
00aec167963e7d5df4b3fc9661439fa3 ../boot.img
00aec167963e7d5df4b3fc9661439fa3 boot.img
f5adbe66ef11e0d6a3cea6f0d04ec798 ../boot.img-kernel.gz
f5adbe66ef11e0d6a3cea6f0d04ec798 boot.img-kernel.gz

We also need to get a picture of the boot.img-ramdisk directory. How big is it? What does it contain?

j@akleja:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk/
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk/

j@akleja:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk; ls -la boot.img-ramdisk
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk
total 244
drwxrwxr-x 8 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rw-r--r-- 1 j users 1395 Sep 16 22:11 cwkeys
drwxrwx--x 2 j users 4096 Sep 16 22:11 data/
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop~
drwxr-xr-x 2 j users 4096 Sep 16 22:11 dev/
-rwxr-x--- 1 j users 111468 Sep 16 22:11 init*
-rwxr-x--- 1 j users 14390 Sep 16 22:11 init.endeavoru.common.rc*
-rwxr-x--- 1 j users 18122 Sep 16 22:11 init.endeavoru.rc*
-rwxr-x--- 1 j users 2344 Sep 16 22:11 init.goldfish.rc*
-rwxr-x--- 1 j users 22319 Sep 16 22:11 init.rc*
-rwxr-x--- 1 j users 6140 Sep 16 22:11 init.usb.rc*
drwxr-xr-x 2 j users 4096 Sep 16 22:11 proc/
drwxr-x--- 2 j users 4096 Sep 16 22:11 sbin/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 sys/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 system/
-rw-r--r-- 1 j users 1417 Sep 16 22:11 ueventd.endeavoru.rc
-rw-r--r-- 1 j users 272 Sep 16 22:11 ueventd.goldfish.rc
-rw-r--r-- 1 j users 4105 Sep 16 22:11 ueventd.rc

Identification of the kernel base address

The kernel base address = (hdr.kernel_addr - 0x00008000) [2].

We can from the boot.img see that the hdr.kernel_addr is set to the value 0x10008000.

This results in the base address 0x10000000.

j@akleja:~/helpingehsan/ramdisk$ hexdump -C -n 16 -s 256 boot.img
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110

Recompilation of the ramdisk

A recompilation into a new ramdisk (boot.img-ramdisk.cpio.gz) is the carried out [4],

even if we do not know if it works properly. It's all depending on the source.

j@akleja:~/helpingehsan/ramdisk$ cd boot.img-ramdisk; find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.cpio.gz; cd ..; ls -la
985 blocks
total 12564
drwxr-xr-x 3 j users 4096 Sep 16 23:44 ./
drwxr-xr-x 4 j users 4096 Sep 16 22:57 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rw-r--r-- 1 j users 297162 Sep 16 23:44 boot.img-ramdisk.cpio.gz
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*

Removal of the initial 256 zeros from the boot.img-kernel.gz

j@akleja:~/helpingehsan/ramdisk$ dd if=boot.img-kernel.gz of=boot.img-kernel.gz.new skip=256 iflag=skip_bytes
8016+0 records in
8016+0 records out
4104192 bytes (4.1 MB) copied, 0.03337 s, 123 MB/s

Creating a new boot.img

Remeber: the original boot.img header did not have a kernel command line.

j@akleja:~/helpingehsan/ramdisk$ mkbootimg --kernel boot.img-kernel.gz.new --ramdisk boot.img-ramdisk.cpio.gz --base 0x10000000 -o boot.img
j@akleja:~/helpingehsan/ramdisk$ ls -la boot.img; md5sum boot.img
-rwxrwxrwx 1 j users 4405248 Sep 16 23:58 boot.img*
dba17088ff533adec1fb5a92478fafe2 boot.img

Summary

With knowledge in the boot.img structure, some experience in using a hex editor

(my personal favourite is the KDE Okteta) and DIY-mentality, I think you could solve most of such problems.

I have no idea if theresulting boot.img will work, the content is based on the files that was found in the original tar-file.

Here is a copy of the original file in case the original file was deleted

The resulting boot.img is there too.

For those who wonders about the analysis environment: Linux (here: Slackware 13.37 / current).

Take care and good luck!

References:

[1] [HELP] Can anyone help me recompile this boot.img?, Sept 2012

[2] mkbootimg.c, bootimg.h by The Android Open Source Project, 2007

[3] GZIP file format specification version 4.3, RFC 1952, chapter 2.3.1., L. Peter Deutsch, 1996

[4] HOWTO: Unpack, Edit, and Re-Pack Boot Images, Android-DLS, 2012