我有4个文件： />
我们可以看到
02和04是可执行文件。 01可能是某种引导程序（我从字符串分析中假设它）。 03是某种伪FS。我从分析
03开始（我将其张贴在这里）： br /> 7B 02作为16位给出635，它是二进制文件的数量（已使用strings进行了验证）。然后有635个部分描述每个文件（称为目录），最后是文件内容。有一个我找到的第一个GIF文件的目录条目。我之所以选择GIF，是因为它易于识别（有标题GIF8X和页脚0x3B）。
文件具有二进制和文件大小，但是我不太确定如何解释该值。
我在目录后找到第一个GIF并手动提取（从页眉到页脚），这给了我文件大小528字节，因此将
www\um\public_sys-resources\Buttun_Current.gif读取为16位无符号，就可以得到该数字。我尝试将10 02视为16位无符号以获得偏移量，但是它与我从文件中手动读取的偏移量不同。但是，18 22的文件的偏移量与实际偏移量之间存在恒定差。所以我创建了解压缩此二进制文件的脚本（我得到了偏移量并添加到1286864中）。脚本仅部分起作用。它重新创建了目录结构，但只能将文件提取到一个特定的目录（我使用GIF的目录作为参考）中。在检查文件的不同部分之后，似乎不同子目录中的offset偏移量是此GIF目录中的另一个偏移量。因此，我的猜测是我在解释偏移量错误（但是将偏移量视为32位则无济于事）。
用法：
1286864 所以我的问题是：我在做什么错？也许我应该读取其他数据类型作为偏移量/大小？哪一个？
#1 楼
我设法解决了问题。目录中的第一个文件是
ZSP.bin。此文件的偏移量是16位还是32位都没有关系，因为在两种情况下均为0。据我所知，目录结束位置，目录之后的第一个文件应为ZSP.bin。下面最后一个目录条目的最后两行以及我怀疑应该是
ZSP.bin的第一行。每个目录条目都以FF EE结尾，因此我检查了下一个字节的偏移量和假设它将从ZSP.bin开始。偏移量是0x2a2d0。然后我检查了ZSP.bin的大小。我知道它在哪里，但是我不知道它是16位还是32位（
B4 C3或B4 C3 0C 00）。当我将16位B4 C3添加到我已知的偏移量0x2a2d0中时，它的地址不像XML文件的开头（目录中的第三个，但第二个的长度为0），它的地址为0x36684。因此，我尝试将0xcc3b4（32位值）添加到我的偏移量中，从而得到0xf6684，并且在此地址处是XML文件的开头... :) 所以我修改了代码：
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC 94 6D 00 53 25 01 00 00 00 00 00 00 00 FF EE
11 00 10 00 30 00 00 00 10 00 00 00 00 00 00 00
手动检查了一些随机的非二进制文件后，所有文件都没问题（正确的HTML和XML开头和结尾，将GIF标识为GIF）...
顺便说一句，我醒来后首先想到了检查目录中的第一个文件而不是此GIF的想法... :)
#2 楼
我无法评论正确的格式..因此，请原谅这是一个新的答复。可以使用以下命令进行读取：offset:length description
------------- -----------
0x00 : 4 unknown, probably 2 16-byte words for a version or file ID
0x04 : 4 size of the data block containing file data
0x08 : 4 unknown
0x0C : 4 offset to the data block
0x10 : 4 number of file entries
0x14 : 12 unknown / padding
每个文件条目如下所示：
size_of_data, offset_to_data, number_of_files = struct.unpack("< 4x L 4x L L 12x", header)
然后每个文件条目：
offset:length description
------------- -----------
0x000 : 256 file path
0x100 : 4 offset to file in data block
0x104 : 4 size of file data
0x108 : 8 unknown
文件的最终偏移量是：
filepath, offset, size = struct.unpack("< 256s L L 8x", body)
评论
感谢您的反馈。假设报头中存在数据块偏移量是合理的，我不知道为什么我没有想到它。但是当我找到它时，我再也没有看过标题。关于目录中的条目：对我来说很奇怪，在每个条目的末尾都有“结束标记”：FF EE，因为所有条目的长度都相同。实际上，您可以从offset_to_data / number_of_files计算每个目录条目的长度，因此不需要此分隔符...再次感谢。您的代码绝对可以使我的脚本更漂亮... :)
– pbm
2013年9月8日19:01
#3 楼
我知道这是一个旧线程，但是我想补充一下，您的Hauwei E586可能基于HiSierrra芯片组和固件。 （也就是说，使用Huawei Modem Flasher时，华为固件以“ 21”开头。）这是使用嵌入式Linux服务器，这与那些基于高通芯片且固件以“ 11”开头的MiFi固件不同。这是关于其中一个固件（E589）的另一个有趣的反转线程。我的问题是，您是否还必须处理整个二进制文件的校验和？
（您知道如何计算它以及它的位置吗？）
PS。这只是一个评论，但我仍然没有要求的代表来这样做。
评论
我的路由器不是Linux，而是VxWorks，我对此很确定。我没有更改文件中的任何内容，因此无需重新计算校验和，而且我也不知道它位于何处...
– pbm
2014年3月6日16:02
评论
此文件部分与文章中描述的文件类似：devttys0.com/2011/06/mystery-file-system，但内部文件未打包，我也无法匹配目录中的偏移量和大小。