PE Header中的FIleHeader(文件头)
IMAGE_FILE_HEADER STRUCT
Machine WORD ?
NumberOfSections WORD ?
TimeDateStamp dd ?
PointerToSymbolTable dd ?
NumberOfSymbols dd ?
SizeOfOptionalHeader WORD ?
Characteristics WORD ?
IMAGE_FILE_HEADER ENDS
| Field name | Meanings |
|---|---|
| Machine | 该文件运行所要求的CPU。对于Intel平台，该值是IMAGE_FILE_MACHINE_I386 (14Ch)。我们尝试了LUEVELSMEYER的pe.txt声明的14Dh和14Eh，但Windows不能正确执行。看起来，除了禁止程序执行之外，本域对我们来说用处不大。 |
| NumberOfSections | 文件的节数目。如果我们要在文件中增加或删除一个节，就需要修改这个值。 |
| TimeDateStamp | 文件创建日期和时间。我们不感兴趣。 |
| PointerToSymbolTable | 用于调试。 |
| NumberOfSymbols | 用于调试。 |
| SizeOfOptionalHeader | 指示紧随本结构之后的 OptionalHeader结构大小，必须为有效值。 |
| Characteristics | 关于文件信息的标记，比如文件是exe还是dll。 |
但如果要遍历节表就得使用NumberOfSections。
为了更好阐述 NumberOfSections 的用处，这里简要介绍一下节表。
节表是一个结构数组，每个结构包含一个节的信息。因此若有3个节，数组就有3个成员。我们需要NumberOfSections值来了解该数组中到底有几个成员。也许您会想检测结构中的全0成员起到同样效果。Windows确实采用了这种方法。为了证明这一点，可以增加NumberOfSections的值，Windows仍然可以正常执行文件。据我们的观察，Windows读取NumberOfSections的值然后检查节表里的每个结构，如果找到一个全0结构就结束搜索，否则一直处理完NumberOfSections指定数目的结构。
为什么我们不能忽略NumberOfSections的值? 有几个原因。
1、PE说明中没有指定节表必须以全0结构结束。
2、Thus there may be a situation where the last array member is contiguous to the first section, without empty space at all. （首尾相连，会导检验出的节的数量变多，也就是原因3）
3、Another reason has to do with bound imports. The new-style binding puts the information immediately following the section table's last structure array member.（在节表后面有非全0的数据）
因此您仍然需要NumberOfSections。
