我正在尝试分析运行Linux并连接各种家庭自动化和安全设备的系统的固件。每次引导时,运行ARMv5TE的GM8125处理器都会从SPI闪存加载固件映像。我用Bus Pirate连接到闪光灯,并拔出了固件映像。当我在其上运行binwalk时,会得到以下信息。

$ binwalk spidump.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
271284        0x423B4         Sega MegaDrive/Genesis raw ROM dump, Name: "ETIR_ON", "ECCAS",
744708        0xB5D04         CRC32 polynomial table, big endian
786432        0xC0000         gzip compressed data, maximum compression, from Unix, last modified: 1970-01-04 16:05:57 (bogus date)
917760        0xE0100         Linux kernel ARM boot executable zImage (big-endian)
9306332       0x8E00DC        Zlib compressed data, compressed
9307424       0x8E0520        Zlib compressed data, compressed
9308196       0x8E0824        Zlib compressed data, compressed
9309036       0x8E0B6C        Zlib compressed data, compressed
9310040       0x8E0F58        Zlib compressed data, compressed
9310220       0x8E100C        Zlib compressed data, compressed
9311200       0x8E13E0        Zlib compressed data, compressed
9312104       0x8E1768        JFFS2 filesystem, little endian
9317132       0x8E2B0C        Zlib compressed data, compressed
9317428       0x8E2C34        JFFS2 filesystem, little endian
9318332       0x8E2FBC        Zlib compressed data, compressed
[...]


如果运行binwalk -Mre,它将为我提取的ZlibJFFS2数据提供近6000个文件和数百个文件夹。在分析了这些内容之后,我想我应该看一下启动映像。

我通过运行dd if=spidump.bin of=carved.bin bs=1 skip=917760 count=8388572雕刻了zImage。运行file将返回carved.bin: Linux kernel ARM boot executable zImage (big-endian)。到目前为止,一切都很好。这是我迷路的地方。

通过阅读这里和其他地方的其他文章,似乎我应该搜索压缩开始的魔术字节-由于这是big-endian,因此我运行objdump结果很多(仅列出了前几行)。

$ arm-none-eabi-objdump -EB -D -m armv5te -b binary carved.bin | grep 1f8b
    9b38:   1f8b3c36    svcne   0x008b3c36
   1f8b0:   bf2e3abe    svclt   0x002e3abe
   1f8b4:   0811cabb    ldmdaeq r1, {r0, r1, r3, r4, r5, r7, r9, fp, lr, pc}
   1f8b8:   baaee7f4    blt 0xfebd9890
   1f8bc:   fc3711aa    ldc2    1, cr1, [r7], #-680 ; 0xfffffd58
   20c38:   f3b1f8b9            ; <UNDEFINED> instruction: 0xf3b1f8b9
   233c0:   d1f8badf    ldrsble fp, [r8, #175]! ; 0xaf
   2c7d8:   011f8b05    tsteq   pc, r5, lsl #22
   2d990:   e9ff1f8b    ldmib   pc!, {r0, r1, r3, r7, r8, r9, sl, fp, ip}^  ; <UNPREDICTABLE>
我从运行魔术字节的第一个出现开始雕刻文件,方法是运行dd if=carved.bin of=arm.gz bs=1 skip=39736file返回arm.gz: gzip compressed data, unknown method, has CRC, extra field, has comment, encrypted, last modified: Mon Sep 15 08:57:49 1975,而gunzip拒绝解压缩,说unknown method 60 -- not supported。以后出现的大多数1f8b在字节的开头都没有对齐,因此我认为它们不是雕刻和解压缩的理想选择。似乎是第一次出现,以及随后出现的情况,可能都是偶然的。

这真的是zImage,还是binwalkfile会混淆?我怎么知道?

很遗憾,我无法提供二进制文件供您自己阅读。

更新-2019/6/25


>按照julian的要求,我包括了文件熵的图表。看起来确实是该节的内容已压缩。



更新-7/5/2019

经过专家的进一步审查,似乎binwalk错误地识别了文件类型。看来有一个自定义拆包器,我需要反汇编或运行它,然后从内存中取出解压缩的映像。

评论

我想我缺少了一些东西。为什么要尝试反汇编压缩的数据?

查看可疑zImage的熵图以确定其是否被压缩

@IgorSkochinsky我以为,如果文件结构不包含我想要的内容,则启动映像将具有有关特定打开的端口的更多信息以及与这些端口相关的信息。

@julian我添加了一个熵图,它看起来确实经过了合法压缩。

如果对压缩数据进行binwalk扫描未返回任何真实/合法的签名,则可能需要手动对数据的前几个字节进行十六进制转储,以查找指向特定压缩算法的任何信息。 >