從Android boot.img與recovery.img的解包中瞭解其資料


又到了忙碌的季節，一次要處理N多事情。最近需要從boot.img中取出ramdisk。不同的專案中kernel是一樣的，ramdisk中的資源不一樣，直接取ramdisk與新編譯的kernel打包在一起，方便又快捷。下面就看看boot.img的結構。

在網上搜索了一遍，找到幾個文章，說得都挺明白的了。boot.img由四部分組成：1 page的header，n page的kernel，m page的ramdisk，o page的second stage。幾個部分是緊密接合在一起的，大小不夠一個page的填充0補齊。還有完整的perl指令碼來解包，真的是一應俱全。知其然還要知其所以然，下來就看看其資料究竟是怎麼分佈的，也當是留給自己的備註資訊。

先是 1 page的頭部資訊：
    page的單位是多少？一般文章都只說了是2K的檔案頭。這個是標準如此定死了還是有跡可尋呢？先別管這塊，取2K的資料看一下吧。分析指令碼所得，具體資料偏移如下：(這部分的資訊是定義在android-src/system/core/mkbootimg/bootimg.h中，也可以從此檔案獲得。)
    1)偏移0x00，8 byte，總是"ANDROID!"，相當於magic number吧。
    2)偏移0x08，8 byte，前4byte是kernel的大小，後4byte是kernel載入記憶體的地址。
    3)偏移0x10，8 byte，結構同kernel，前4byte是ramdisk的大小，後4byte是載入地址。
    4)偏移0x18，8 byte，結構同上，前4byte是second stage的大小，後4byte是載入地址。這部分一般都沒有，大小是0。
    5)偏移0x24，4 byte，頁(page)大小，一般是0x800，也就是2K。
    6)偏移0x30，16 byte，boot name，貌似沒怎麼用上。
    7)偏移0x40，512 byte，cmdline核心引數，這個不多說了，懂什麼是核心的都明白吧。

後續的kernel和ramdisk，都可以根據檔案頭中的資訊算出地址和大小，直接分解出來即可。注意填充的0要去掉，可能對第二次打包產生影響。