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
,它将为我提取的Zlib
和JFFS2
数据提供近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=39736
。 file
返回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,还是
binwalk
和file
会混淆?我怎么知道? 很遗憾,我无法提供二进制文件供您自己阅读。
更新-2019/6/25
>按照julian的要求,我包括了文件熵的图表。看起来确实是该节的内容已压缩。
更新-7/5/2019
经过专家的进一步审查,似乎
binwalk
错误地识别了文件类型。看来有一个自定义拆包器,我需要反汇编或运行它,然后从内存中取出解压缩的映像。
评论
我想我缺少了一些东西。为什么要尝试反汇编压缩的数据?查看可疑zImage的熵图以确定其是否被压缩
@IgorSkochinsky我以为,如果文件结构不包含我想要的内容,则启动映像将具有有关特定打开的端口的更多信息以及与这些端口相关的信息。
@julian我添加了一个熵图,它看起来确实经过了合法压缩。
如果对压缩数据进行binwalk扫描未返回任何真实/合法的签名,则可能需要手动对数据的前几个字节进行十六进制转储,以查找指向特定压缩算法的任何信息。 >