首先，我有一个映像称为firmware.bin，而file命令向我显示它是一个LIF文件：
firmware.bin: lif file
之后，我用binwalk对其进行分析：
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
84992 0x14C00 ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 65616, compressed size: 16606, uncompressed checksum: 0xBA2A, compressed checksum: 0x913E, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
85043 0x14C33 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 65616 bytes
128002 0x1F402 GIF image data, version 8"9a", 200 x 50
136194 0x21402 GIF image data, version 8"7a", 153 x 55
349184 0x55400 ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 3113824, compressed size: 733298, uncompressed checksum: 0x3B9C, compressed checksum: 0xBBBA, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
349235 0x55433 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3113824 bytes
您可以看到有2个LZMA，2个ZynOS（LZMA也被剪切）和2个图像。提取LZMA后，我将其解压缩，第一个是单个二进制文件，但第二个是其中包含127个文件的另一个LZMA文件，并且每个文件中都有很多新文件。
我想我没有按照正确的步骤解压缩它，所以我想知道如何清理主文件系统？
#1 楼
您可能已经猜到，文件实用程序的输出是误报。 firmware.bin文件的开头包含看似基本的标头（请注意文件开头附近的“ SIG”字符串）和一堆MIPS可执行代码，很可能是引导程序：DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
196 0xC4 MIPS instructions, function epilogue
284 0x11C MIPS instructions, function epilogue
372 0x174 MIPS instructions, function epilogue
388 0x184 MIPS instructions, function epilogue
416 0x1A0 MIPS instructions, function epilogue
424 0x1A8 MIPS instructions, function prologue
592 0x250 MIPS instructions, function epilogue
712 0x2C8 MIPS instructions, function epilogue
720 0x2D0 MIPS instructions, function prologue
832 0x340 MIPS instructions, function epilogue
840 0x348 MIPS instructions, function prologue
912 0x390 MIPS instructions, function epilogue
920 0x398 MIPS instructions, function prologue
976 0x3D0 MIPS instructions, function epilogue
984 0x3D8 MIPS instructions, function epilogue
1084 0x43C MIPS instructions, function epilogue
1192 0x4A8 MIPS instructions, function epilogue
1264 0x4F0 MIPS instructions, function epilogue
...
固件上运行的字符串。bin二进制文件似乎支持了该假设，并涉及许多校验和和解压缩错误：
>快速检查您发现的两个解压缩的LZMA文件中的字符串，发现较小的字符串（偏移量为0x14C33）似乎包含一些调试接口代码，可能是通过设备的UART访问的：
checksum error! (cal=%04X, should=%04X)
signature error!
(Compressed)
start: %p
unmatched objtype between memMapTab and image!
Length: %X, Checksum: %04X
Version: %s,
Compressed Length: %X, Checksum: %04X
memMapTab Checksum Error! (cal=%04X, should=%04X)
memMapTab Checksum Error!
%3d: %s(%s), start=%p, len=%X
%s Section:
memMapTab: %d entries, start = %p, checksum = %04X
$USER Section:
signature error!
ROMIO image start at %p
code length: %X
code version: %s
code start: %p
Decompressed image Error!
Decompressed image Checksum Error! (cal=%04X, should=%04X)
ROM length(%X) > RAM length (%X)!
Can't find %s in $ROM section.
Can't find %s in $RAM section.
RasCode
第二个较大的文件（偏移量为0x55433）似乎包含Green Hills编写的ThreadX RTOS：
UART INTERNAL LOOPBACK TEST
UART EXTERNAL LOOPBACK TEST
ERROR
======= HTP Command Listing =======
< press any key to continue >
macPHYCtrl.value=
MAC INTERNAL LOOPBACK TEST
MAC EXTERNAL LOOPBACK TEST
MAC INTERNAL LOOPBACK
MAC EXTERNAL LOOPBACK
LanIntLoopBack ...
Tx Path Full, Drop packet:%d
0x%08x
tx descrip %d:
rx descrip %d:
%02X
%08X:
< Press any key to Continue, ESC to Quit >
0123456789abcdefghijklmnopqrstuvwxyz
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
<NULL>
) Register Dump *****
***** ATM SAR Module: VC(
Reset&Identify reg =
Traffic Sched. TB reg=
TX Data ctrl/stat reg=
RX Data ctrl/stat reg=
Last IRQ Status reg =
IRQ Queue Entry len =
VC IRQ Mask register =
TX Data Current descr=
RX Data Current descr=
TX Traffic PCR =
TX Traffic MBS/Type =
TX Total Data Count =
VC IRQ CC Mask reg =
TX CC Current descr =
TX CC Total Count =
RX Miss Cell Count =
***** ATM SAR Module: Common Register Dump *****
虽然不熟悉RTOS，但它们通常只是一个大内核，没有用户空间与内核空间或普通文件系统的概念，尽管它们将包含例如该设备Web界面的图像和HTML文件（请参见此处，以了解在某些VxWorks系统中如何存储/访问这些类型的文件的示例）。
我要说的是，您已经将该固件提取到其基本部分中了。为了进一步分析引导加载程序或两个提取的LZMA文件，您需要开始反汇编这些文件，这需要确定引导时将它们加载到的内存地址，识别代码/数据段，查找可能的符号表，识别通用功能，并可能编写一些脚本来帮助实现上述所有功能。
评论
哇，这正是我所需要的，非常感谢，一如既往地很棒。还有一个问题，是否有识别标头的指南？我在这个领域还很新（事实上，我是在阅读了WAG120N上的文章之后才开始的），有时很难检测到误报或奇怪的FS /文件。问候。
– Nucklear
13年7月30日在7:15
它会根据您要查看的文件而有所不同，但是文件/固件标头通常由2-4个“魔术”字节组成，其后是一些结构化数据，通常包括文件大小，创建日期，校验和，以及可能的内容可读的ASCII描述。将每个偏移量解释为各种数据类型（大/小端长，短，日期代码等）以识别未知标头中的这些字段通常很有用（我使用binwalk的-C选项，但是任何好的十六进制编辑器都具有此功能能力）。
–devttys0
13年7月30日在12:09
是的，我理解这一点，但是一旦确定了这些标头，我将如何确定几乎有0年经验的FS /文件？是否有任何资源可以比较标头并进行标识？我在您的博客中看到您有时会说“哦，这是LZMA标头”，甚至是“奇怪的LZMA标头”，您如何在没有先验知识的情况下识别这些标头？问候。
– Nucklear
13年8月1日在10:36
我将从查看数据的熵开始，如果数据是加密的，压缩的或两者都不加密，则可以为您提供一个好主意。例如，如果看起来已压缩，那么我将开始比较标题的开头与已知的常见压缩类型（lzma，zlib等）。失败的话，您可能需要反转负责访问/解压缩该数据的代码。
–devttys0
13年8月1日在17:11
评论
要在此处解决此问题以及其他ZyNOS问题，我的固件工具现已完成。 github.com/dev-zzo/router-tools/blob/master/zynos.py它既可以解包也可以打包固件映像；我已经在BiPAC5102SAv27023_UE0B1C_3325图像上进行了测试，以确保它可以对其进行处理。玩得开心！