0

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

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

我们可以进一步验证这是文件头，因为它的4 字节签名：'PE'后跟两个NULL字节。显然，该格式似乎是用小端表示的，因为如果我们要显式编写 PE，我们将使用 hex 50 45。

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

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

我是否缺少更明确定义的字节顺序？为什么字段之间的字节顺序似乎不一致？

4

1 回答 1

0

您的 hexdump 使用了误导性格式。使用字节格式重试（-c选项）

在您拥有的转储中，输出已经进行了字节交换。事物按顺序出现

(byte1)(byte0) ' ' (byte3)(byte2) ' ' (byte5)(byte4) ' '

等等。

正如您提到的，PE 标头是

50 45

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

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

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

于 2018-02-04T18:39:41.217 回答