Question

我有一个Windows二进制文件的hexdump，并通过查看COFF偏移量来识别此可执行文件中的COFF标头：

0000080: 4550 0000 014c 0003 6ec8 3add 0000 0000
0000090: 0000 0000 00e0 010f 010b 0301 2000 0000

我们可以进一步验证这是文件头，因为其4 byte signature：'PE'后跟两个NULL个字节。很明显，格式似乎用小端表示，因为如果我们要明确地写PE，我们将使用十六进制50 45。

如果我们查看the PE format specification并执行此观察，NumberOfSections字段（从Machine字段跳过的签名末尾偏移2个字节），我们确定有768个部分（小端的03 00）。这与规范相矛盾，声明Windows加载程序将节数限制为96。

此外，Timestamp字段（接下来的4个字节）中的字节排序似乎很奇怪，因为只有排列3add 6ec8才会生成过去的Unix时间戳。

是否有更明确定义的字节顺序我错过了？为什么字段之间的字节顺序看起来不一致？

Answer 1

您的hexdump使用的是误导性格式。再次尝试使用字节格式（-c选项）

在您拥有的转储中，输出已经是字节交换的。事情出现在订单中

（byte1）（byte0）＆＃39; ＆＃39; （byte3）（byte2）＆＃39; ＆＃39; （byte5）（byte4）＆＃39; ＆＃39;

等等。

正如您所提到的那样，PE标题是

50 45

Hexdump的默认显示规则采用这两个字节并将它们解释为16位小端整数0x4550，这就是显示为4550的原因

部分数量为3，（文件中为03 00）。我不知道为什么你说03 00是小端的768，因为那是错的。在这种情况下，16位LE默认格式的hexdump实际上有效，因为它是一个16位字段，0x0003的解码是正确的。

时间戳显示为6ec8 3add，但文件中的实际字节为c8 6e dd 3a。现在32位字段大小和16位hexdump格式不匹配，导致您完全混淆。