binwalk 提取bootimg_使用IDA处理U-Boot二进制流文件

原标题：使用IDA处理U-Boot二进制流文件

最近在研究IoT设备的过程中遇到一种情况。

一个IoT设备，官方不提供固件包，网上也搜不到相关的固件包，所以我从flash中直接读取。因为系统是VxWorks，能看到flash布局，所以能很容易把uboot/firmware从flash中分解出来。对于firmware的部分前一半左右是通过lzma压缩，后面的一半，是相隔一定的区间有一部分有lzma压缩数据。而固件的符号信息就在这后半部分。因为不知道后半部分是通过什么格式和前半部分代码段一起放入内存的，所以对于我逆向产生了一定的阻碍。所以我就想着看看uboot的逻辑，但是uboot不能直接丢入ida中进行分析，所以有了这篇文章，分析uboot格式，如何使用ida分析uboot。

uboot格式

正常的一个uboot格式应该如下所示：

$ binwalk bootimg.binDECIMAL HEXADECIMAL DEION-------------------------------------------------------------------------------- 136480x3550 CRC32 polynomial table, big endian 149080x3A3C uImage header, header size: 64bytes, header CRC: 0x25ED0948, created: 2019-12-02 03:39:51, image size: 54680bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0x3DFB76CD, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"149720x3A7C LZMA compressed data, properties: 0x5D, dictionary size: 33554432bytes, uncompressed size: 161184bytes

而这uboot其实还得分为三部分：

1.从0×00 – 0x346C是属于bootstrap的部分

2.0x346C-0x34AC有0×40字节的uboot image的头部信息

3.从0x34AC到结尾才是uboot image的主体，经过lzma压缩后的结果

那么uboot是怎么生成的呢？Github上随便找了一个uboot源码: https://github.com/OnionIoT/uboot ，编译安装了一下，查看uboot的生成过程。

1.第一步，把bootstrap和uboot源码使用gcc编译成两个ELF程序，得到bootstrap和uboot

2.第二步，使用objcopy把两个文件分别转换成二进制流文件。$ mips-openwrt-linux-uclibc-objcopy --gap-fill

=0xff -O binary bootstrap bootstrap.bin$ mips-openwrt-linux-uclibc-objcopy --gap-fill

=0xff -O binary uboot uboot.bin$ binwalk u-boot/b