PE 格式的可执行文件中的 COFF 字节顺序
COFF byte ordering in PE formatted executable
我有一个 Windows 二进制文件的 hexdump，并通过查看 COFF 偏移量识别了此可执行文件中的 COFF header：
0000080: 4550 0000 014c 0003 6ec8 3add 0000 0000
0000090: 0000 0000 00e0 010f 010b 0301 2000 0000
我们可以进一步验证这是文件 header 因为它的 4 byte signature: 'PE' 后跟两个 NULL 字节。显然，该格式似乎是用小端表示的，因为如果我们要显式编写 PE，我们将得到十六进制 50 45.
如果我们查看 the PE format specification 并进行此观察，NumberOfSections 字段（从 Machine 字段跳过的签名末尾偏移 2 个字节），我们确定有 768 个部分（03 00 in little endian）。这与规范相矛盾，指出 Windows 加载程序将部分数限制为 96。
此外，Timestamp 字段（接下来的 4 个字节）中的字节顺序看起来很奇怪，因为只有排列 3add 6ec8 会产生过去的 Unix 时间戳。
是否有我缺少的更明确定义的字节顺序？为什么字段之间的字节顺序看起来不一致？
您的 hexdump 使用了误导性的格式。使用字节格式重试（-c 选项）
在您的转储中，输出已经进行了字节交换。事物出现顺序
(byte1)(byte0) ' ' (byte3)(byte2) ' ' (byte5)(byte4) ' '
等等。
PE header 如您所述
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 格式不匹配，导致您完全混淆。
我有一个 Windows 二进制文件的 hexdump，并通过查看 COFF 偏移量识别了此可执行文件中的 COFF header：
0000080: 4550 0000 014c 0003 6ec8 3add 0000 0000
0000090: 0000 0000 00e0 010f 010b 0301 2000 0000
我们可以进一步验证这是文件 header 因为它的 4 byte signature: 'PE' 后跟两个 NULL 字节。显然，该格式似乎是用小端表示的，因为如果我们要显式编写 PE，我们将得到十六进制 50 45.
如果我们查看 the PE format specification 并进行此观察，NumberOfSections 字段（从 Machine 字段跳过的签名末尾偏移 2 个字节），我们确定有 768 个部分（03 00 in little endian）。这与规范相矛盾，指出 Windows 加载程序将部分数限制为 96。
此外，Timestamp 字段（接下来的 4 个字节）中的字节顺序看起来很奇怪，因为只有排列 3add 6ec8 会产生过去的 Unix 时间戳。
是否有我缺少的更明确定义的字节顺序？为什么字段之间的字节顺序看起来不一致？
您的 hexdump 使用了误导性的格式。使用字节格式重试（-c 选项）
在您的转储中，输出已经进行了字节交换。事物出现顺序
(byte1)(byte0) ' ' (byte3)(byte2) ' ' (byte5)(byte4) ' '
等等。
PE header 如您所述
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 格式不匹配，导致您完全混淆。