zImage 是编译内核后在 arch/arm/boot 目录下生成的一个已经压缩过的内核映像。通常我们不会使用编译生成的原始内核映像 vmlinux，因其体积很大。因此，zImage 是我们最常见的内核二进制，可以直接嵌入到固件，也可以直接使用 qemu 进行调试。当然，在 32 位嵌入式领域还能见到 uImage，这是在 zImage 首位增加 64B 的头，描述映像文件类型、加载位置、内核大小等信息。

有些嵌入式设备的文件系统直接嵌入到内核中，这种内置文件系统的机制被称为 ramdisk/initramfs，如果只是使用 extract-vmlinux/binwalk 解压固件，释放大量 shell 脚本和配置文件，是很容易做到的，但是如果想要修改这些文件，并进行重新打包，生成实际设备可以运行的 zImage 内核映像可能不是那么简单。

本文将演示如何在 32位 ARM zImage 中替换 piggy 中的文件系统，我们以 openWRT 的某个版本固件为例进行讲解。

初始设置

下载 OpenWRT ARM zImage-initramfs 映像，这是一个基于 ramdisk 的典型内核映像，不需要额外的文件系统，实际上也无法使用 binwalk 直接提取我们想要修改的操作系统启动提示信息。

$ wget https://downloads.openwrt.org/releases/17.01.0/targets/armvirt/generic/lede-17.01.0-r3205-59508e3-armvirt-zImage-initramfs -O zImage-initramfs
$ openssl dgst zImage-initramfs
SHA256(zImage-initramfs)= 5ad269e95b2db16aea3794dd0e97dabb6f9712184d79b0764bb10a810f8d7639

使用 qemu 启动

$ qemu-system-arm -M virt -m 1024 -kernel zImage-initramfs -append "console=ttyAMA0" -nographic

最小 shell 控制台

BusyBox v1.25.1 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01.0, r3205-59508e3)
    \________\/    -----------------------------------------------------------

=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@LEDE:/#

查看内核版本，找到对应的源码，因为我们有可能会根据内核解压缩的源码，调整重打包方式。

root@LEDE:/# uname -a
Linux LEDE 4.4.50 #0 SMP Mon Feb 20 17:13:44 2017 armv7l GNU/Linux

找到相应版本的内核，推荐在线浏览 https://elixir.bootlin.com/linux/v4.4.50/source/，版本匹配也没有那么重要，因为内核解压缩的核心代码其实一直以来变化不大，位于源码目录 arch/arm/boot/compressed。

提取 Piggy

使用 binwalk 分析固件，就像我们在开始说的，binwalk 可能可以提取其中的配置文件，也有可能无法提取，即使提取，也都是归在一个文件夹下，并没有常见的 squashfs 文件系统

$ binwalk zImage-initramfs         

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Linux kernel ARM boot executable zImage (little-endian)
15400         0x3C28          xz compressed data
15632         0x3D10          xz compressed data

毫无疑问，固件开始部分是可以直接运行的未经压缩的用于解压内核的 head.o 和 misc.o，使用 dd 命令提取该部分进行分析，或者直接将整个固件拖入 IDA，选择 arm，并只反汇编固件头部部分。

运行上述 IDC 脚本，即可得到解压内核代码部分。可以对比内核源码，我们需要找到固件中，内核压缩映像文件的起始地址和结束地址。piggy.S 使用 incbin 关键字引入 piggy.gz。其中全局变量 input_data 和 input_data_end 分别是 piggy 的起始地址和结束地址。

	.section .piggydata,#alloc
	.globl	input_data
input_data:
	.incbin	"arch/arm/boot/compressed/piggy.gz"
	.globl	input_data_end
input_data_end:

毫无疑问，内核解压代码需要这些全局变量，这样才能够解压真正压缩的内核。

putstr("Uncompressing Linux...");
ret = do_decompress(input_data, input_data_end - input_data,
    output_data, error);
if (ret)
    error("decompressor returned an error");
else
    putstr(" done, booting the kernel.\n");

IDA 反编译的固件头部，寻找 Uncompressing Linux...，对比源码很容易知道 piggy 的实际偏移。

继续分析汇编，找到全局变量存放的位置

对比原始固件二进制时，发现压缩结束 magic YZ 后面多出了 4B 数据，这 4B 其实是原始未经压缩的xz大小。实际上 YZ 才是压缩文件的结尾。因此使用 xz 解压时，估计会出现 Unexpected end of input 错误，只需要添加参数即可。

dd 截取 piggy

$ dd if=zImage-initramfs of=vmlinux.xz bs=1 skip=$[0x3d10] count=$[0x2bb404]                     
2864132+0 records in
2864132+0 records out
2864132 bytes (2.9 MB, 2.7 MiB) copied, 13.595 s, 211 kB/s

解压 piggy

$ unxz --verbose --single-stream < vmlinux.xz > /tmp/vmlinux
  100 %   2,797.0 KiB / 8,883.5 KiB = 0.315 

我们发现解压后的 vmlinux 内核映像大小果然是 28 c3 8a 00

$ ls -l /tmp/vmlinux                
-rw-r--r-- 1 kali kali 9096744 Dec 20 04:04 /tmp/vmlinux

$ python -c "print(0x8ace28)"
9096744

重打包

修改 vmlinux，例如修改启动界面字符串，找到需要修改信息的地址。这些信息显示 initramfs 嵌入在解压后的 vmlinux 中，该部分由一个没有校验和的未经压缩的 CPIO 文档组成（binwalk 可以识别）。

$ strings -t x /tmp/vmlinux | grep "WARNING\!" 
 76ac3a === WARNING! =====================================

使用 hexedit 编辑，回车键可快速定位此地址，tab 可切换 16 进制 / ASCII 码，ctrl+x 保存并退出。

0076AC3C   3D 20 57 41  52 4E 49 4E  47 21 20 4D  6F 64 69 66  69 63 61 74  = WARNING! Modificat
0076AC50   69 6F 6E 20  73 75 63 63  65 65 64 65  64 21 21 21  3D 3D 3D 3D  ion succeeded!!!====

如果直接使用 xz 压缩，我们会发现压缩后大小大于原始压缩文件 0x2bb404(2864132)，通过 Linux 源码可以找到压缩命令位于 xz_wrap.sh

xz --check=crc32 --arm --lzma2=$LZMA2OPTS,dict=32MiB

仅仅使用上述命令压缩还是不够的，压缩后的文件仍然较大，nice 可以达到最大压缩比。最终压缩命令如下

$ xz --check=crc32 --arm --lzma2=,dict=32MiB,nice=128 < /tmp/vmlinux > /tmp/vmlinux.xz             

$ ls -l /tmp/vmlinux.xz 
-rw-r--r-- 1 kali kali 2863832 Dec 20 04:26 /tmp/vmlinux.xz

显然小于原始压缩文件，符合要求。要记住，piggy 末尾 4 字节存放原始文件大小，而我们只是修改启动信息，并没有改变原始 vmlinux 大小

$ echo -en "\x28\xce\x8a\x00" >> /tmp/vmlinux.xz # piggy.gz

替换 piggy

$ cp zImage-initramfs zImage-initramfs-warnmod
$ dd if=/tmp/vmlinux.xz of=zImage-initramfs-warnmod bs=1 seek=$[0x3d10] conv=notrunc
2863836+0 records in
2863836+0 records out
2863836 bytes (2.9 MB, 2.7 MiB) copied, 11.1713 s, 256 kB/s

修改内核解压代码中的 piggy 结束地址，input_data_end = hex(0x3d10+2863836) = 0x2befec，原始大小为 0x2bf114

002BF124   EC EF 2B 00  68 F5 2B 00  10 3D 00 00  64 F5 2B 00  64 F1 2B 00  ..+.h.+..=..d.+.d.+.

尝试启动内核，修改成功！

BusyBox v1.25.1 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01.0, r3205-59508e3)
    \________\/    -----------------------------------------------------------

=== WARNING! Modification succeeded!!!============
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@LEDE:/# 

小结

如果需要增加而不是修改 initramfs 的内容，可能就没那么简单了。因为你需要准确掌握固件的每一个部分，而且需要注意的是 piggy 的 inflated size 也就是 xz 实际大小其实是 input_data_end - 4，这一部分代码位于 misc.c 的 LC0 对象

LC0:	.word	LC0			@ r1
		.word	__bss_start		@ r2
		.word	_end			@ r3
		.word	_edata			@ r6
		.word	input_data_end - 4	@ r10 (inflated size location)
		.word	_got_start		@ r11
		.word	_got_end		@ ip
		.word	.L_user_stack_end	@ sp
		.word	_end - restart + 16384 + 1024*1024
		.size	LC0, . - LC0

以本文中的固件为例，piggy 实际大小 0x2bf110，位于固件偏移 0x258，因此如果修改了 piggy 的大小，还需要修改此处地址对应的数据。

当然，实际还需要考虑各个部分的偏移，可参考 https://gist.github.com/jamchamb/243e6973aeb5c9a2e302a4d4f57f16e1

如果你需要增加内核内容并且改变了原有内核大小，而不只是简单修改，则需要掌握内核解压缩的详细流程，在这里，我们只将内核压缩映像生成流程简单呈现如下，详细流程可参见

vmlinux
   │
   │ -R.note
   │ -R.comment
   │
   └─arch/arm/boot/Image
       │
       │ gzip -f -9 < Image > piggy.gz
       │
       └─arch/arm/boot/compressed/piggy.gz
           │
           │ piggy.S 直接引入piggy.gz
           │
           └─arch/arm/boot/compressed/piggy.o
               │
               │ +head.o
               │ +misc.o
               │
               └─arch/arm/boot/compressed/vmlinux
                   │
                   │ -debuginfo
                   │
                   └─arch/arm/boot/compressed/zImage

内核代码中的 head.S 和 misc.c 用于内核自解压，所以，如果我们需要直接通过修改内核二进制的方式打 patch，则需要了解内核压缩和解压的流程。从上图也可以看出来，piggy 就是压缩过的内核的一部分，其实也是内核的主体部分。

参考文献

Modifying Embedded Filesystems in ARM Linux zImages
Linux内核源码分析–内核启动之zImage自解压过程
Linux2.6 内核启动分析
initramfs 在内核中的作用与实现