PE 学习之路 —— DOS 头、NT 头

时间：2018-12-28 20:39:48 阅读：211 评论：0 收藏：0 [点我收藏+]

1. 前述

可执行文件的格式是操作系统本身执行机制的反映，理解它有助于对操作系统的深刻理解，掌握可执行文件的数据结构及其一些机理，是研究软件安全的必修课。`PE（Portable Executable File Format）`是目前 windows 平台上的主流可执行文件格式。PE 文件衍生于早期的 COFF 文件格式，描述 PE 格式及 COFF 文件的主要地方在 winnt.h 这个头文件，其中有一节叫 Image Format，如下：

技术分享图片

该节给出了 DOS MZ 格式和 windows 3.1 的 NE 格式文件头，之后就是 PE 文件的内容，在这个头文件中，几乎能找到关于 PE 文件的每一个数据结构的定义、枚举类型、常量定义。winnt.h 这个头文件是 PE 文件定义的最终决定者。DLL 和 EXE 文件之间的区别完全是语义上的，它们使用完全相同的 PE 格式。唯一的区别就是用一个字段标识出这个文件是 EXE 还是 DLL。同时也包括其它的 DLL 扩展，比如 OCX 控件和控制面板程序（CPL 文件）。另外，64 位 windows 只是对 PE 格式做了一些简单的修饰，新格式叫 PE32+，没有新的结构加进去，其余的改变只是简单地将以前的 32 位字段扩展成64位，比如 `IMAGE_NT_HEADERS`，如下：

技术分享图片

2. PE 文件大体结构

结构的选择依赖于用户正在编译的模式（尤其是 `_WIN64` 是否被定义），在具体学习 PE 之前，先大概清楚下 PE 格式布局是怎样子的，如下：

技术分享图片

PE 文件使用的是一个平面地址空间，所有代码和数据都被合并在一起，组成一个很大的结构，文件的内容被分割为不同的区块，区块包含代码和数据，各个区块按页边界来对齐，区块没有大小限制，是一个连续结构，每个块都有它自己在内存中的一套属性。PE 文件是由 PE 加载器加载到内存中的，这个 PE 加载器也就是 windows 加载器，它并不是将 PE 文件作为单一内存映射文件装入到内存中，而是去遍历 PE 文件，决定将哪一部分进行映射，这种映射方式是将文件较高的偏移位置映射到较高的内存地址，当磁盘文件装入到内存中，其数据结构布局是一致的，但是数据之间的相对位置可能会改变，如下：

技术分享图片

3. 模块和基地址

下面需要理清两个概念，那就是 **模块** 和 **基地址**，当 PE 文件通过 windows 加载器加载到内存后，内存中的版本被称为模块（Module），映射文件的起始地址被称为模块句柄（hModule），可以通过模块句柄来访问在内存中其它的数据结构，这个初始地址也被称为基地址（ImageBase）。在 32 位 windows 系统中可以直接调用 `GetModuleHandle` 以取得指向 DLL 的指针，通过指针访问该 DLL Module 的内容，函数原型为：`HMODULE WINAPI GetModuleHandle(LPCTSTR lpModuleName)`

功能：获取一个应用程序或动态链接库的模块句柄。

参数：传递一个可执行文件或 DLL 文件名字符串

返回值：若执行成功，则返回模块的句柄，也就是加载的基地址，若返回零，则表示失败。如果传递参数为 NULL，则返回调用的可执行文件的基地址。

注意事项：只有在当前进程中，这个句柄才会有效，也就是说已映射到调用该函数的进程内，才会正确得到模块句柄。

 1 #include <windows.h>
 2 #include <iostream>
 3 
 4 int main()
 5 
 6 {
 8     HMODULE hModule = GetModuleHandle(NULL);
 9 
10     std::cout << hModule << std::endl;
11 
12     return 0;
14 }

PE文件加载的基地址（ImageBase）：EXE 默认基地址为 `0x00400000H`，DLL 默认基地址为 `0x10000000H`，这个值可以在链接应用时使用链接程序的 `/BASE` 选项设定，或者通过 REBASE 应用程序进行设置。说完基地址，再来说下相对虚拟地址，由于 PE 文件中里的东西可以载入到空间的任何位置，所以不能依赖于 PE 的载入点，必须有一个方法来指定地址而不依赖于 PE 载入点的地址，所以出现相对虚拟地址（RVA）概念，RVA 只是内存中的一个简单的相对于 PE 文件装入地址的偏移位置，例如，假设一个 EXE 文件从地址 `0x400000H` 处装入，并且它的代码区块开始于 `0x401000H`，代码区块的 RVA 就是：`0x401000H - 0x400000H = 0x1000H`，在这里，`0x401000H` 是实际的内存地址，这个地址被称为虚拟内存地址（VA），另外也可以把虚拟地址想象为加上首选装入地址的RVA。

4. 文件偏移地址

当PE文件储存在磁盘上，某个数据的位置相对于文件头的偏移量，称为文件偏移地址或物理地址。文件偏移地址从PE文件的第一个字节开始计数，起始值为0，用十六进制文本编辑器打开文件，里头显示的就是文件偏移地址。

5. IMAGE_DOS_HEADER 结构

技术分享图片

在这个结构体中，有两个字段非常重要，分别是第一个和最后一个，其它的不重要，其中第一个 e_magic 字段需要被设置为 0x5A4DH。它也被称为魔术数字。

技术分享图片

这个值有个宏定义，名为 `IMAGE_DOS_SIGNATURE`，它的 ASCII 值为 MZ，是 MS-DOS 的最初创建者之一 `Mark Zbikowski` 字母的缩写。

技术分享图片

e_lfanew 字段是真正PE文件头的相对偏移（RVA），那么，这个字段在哪呢？

技术分享图片

上图已经说明了，为了验证是否正确，如下：

技术分享图片

在 3CH 偏移处，显示 0x00000110H（由于 Intel CPU 属于 Little-Endian 类，字符存储时低位在前，高位在后，反序排列，将顺序恢复后便是 0x00000110H），这个是 e_lfanew 字段所存储的值，它占4 个字节。后面就是 PE 头了。

6. IMAGE_NT_HEADERS 结构

技术分享图片

在一个有效的 PE 文件里，Signature 字段被设置为 0x00004550H，ASCII 码字符是 PE00

技术分享图片

宏定义为 `IMAGE_NT_SIGNATURE`

技术分享图片

那么这两个重要的字段（e_lfanew 和 Signature）有什么用呢？这个在以后解析PE文件，判断一个文件是否是一个 PE 文件时提供重要依据，即判断这两个字段的值是否为 0x5A4DH 和 0x00004550H，你也可以用它们的宏定义，分别为 `IMAGE_DOS_SIGNATURE` 和 `IMAGE_NT_SIGNATURE`，如果相等，则为一个 PE 文件，如果不相等，则不是一个 PE 文件。

 1 #include <windows.h>
 2 #include <iostream>
 3 
 4 int main()
 5 {
 6     // 1.首先须打开一个文件
 7     HANDLE hFile = CreateFile(
 8         TEXT("test.png"),
 9         GENERIC_ALL,
10         NULL,
11         NULL,
12         OPEN_EXISTING,
13         NULL,
14         NULL
15     );
16     // 2.判断文件句柄是否有效，若无效则提示打开文件失败并退出
17     if (hFile == INVALID_HANDLE_VALUE)
18     {
19         std::cout << "打开文件失败！" << std::endl;
20         CloseHandle(hFile);
21         exit(EXIT_SUCCESS);
22     }
23     // 3.若打开文件成功，则获取文件的大小
24     DWORD dwFileSize = GetFileSize(hFile, NULL);
25     // 4.申请内存空间，用于存放文件数据
26     BYTE * FileBuffer = new BYTE[dwFileSize];
27     // 5.读取文件内容
28     DWORD dwReadFile = 0;
29     ReadFile(hFile, FileBuffer, dwFileSize, &dwReadFile, NULL);
30     // 6.判断这个文件是不是一个有效的PE文件
31     //    6.1 先检查DOS头中的MZ标记，判断e_magic字段是否为0x5A4D，或者是IMAGE_DOS_SIGNATURE
32     DWORD dwFileAddr = (DWORD)FileBuffer;
33     auto DosHeader = (PIMAGE_DOS_HEADER)dwFileAddr;
34     if (DosHeader->e_magic != IMAGE_DOS_SIGNATURE)
35     {
36         // 如果不是则提示用户，并立即结束
37         MessageBox(NULL, TEXT("这不是一个有效PE文件"), TEXT("提示"), MB_OK);
38         delete FileBuffer;
39         CloseHandle(hFile);
40         exit(EXIT_SUCCESS);
41     }
42     //    6.2 若都通过的话再获取NT头所在的位置，并判断e_lfanew字段是否为0x00004550，或者是IMAGE_NT_SIGNATURE
43     auto NtHeader = (PIMAGE_NT_HEADERS)(dwFileAddr + DosHeader->e_lfanew);
44     if (NtHeader->Signature != IMAGE_NT_SIGNATURE)
45     {
46         // 如果不是则提示用户，并立即结束
47         MessageBox(NULL, TEXT("这不是一个有效PE文件"), TEXT("提示"), MB_OK);
48         delete FileBuffer;
49         CloseHandle(hFile);
50         exit(EXIT_SUCCESS);
51     }
52     // 7.若上述都通过，则为一个有效的PE文件
53     MessageBox(NULL, TEXT("这是一个有效PE文件"), TEXT("提示"), MB_OK);
54     delete FileBuffer;
55     CloseHandle(hFile);
56     // 8.结束程序
57     return 0;
58 }

以上代码就是简单实现判断一个文件是不是有效的 PE 文件。在上述代码中，运用了 CreateFile()、GetFileSize()、ReadFile() 来获取文件内容，得到文件的基址 dwFileAddr，只需将该变量转换成 `PIMAGE_DOS_HEADER` 类型，那么就能获取到NT头的开始位置，NT头的位置可同 (PIMAGE_NT_HEADERS)((PIMAGE_DOS_HEADER)dwFileAddr->e_lfanew + dwFileAddr) 获取，有了这个，后面的工作就变得简单多了。

7. IMAGE_FILE_HEADER 结构

技术分享图片

该结构体描述的是文件的一般性质，有 7 个字段，共占 20 个字节，20 相当于十六进制的 14H，下图已标出实际位置，如下：

技术分享图片

这里标记的是 Machine 字段，占两个字节，它的值为 0x014CH，代表的是 Intel i386 平台。
这里标记的是 NumberOfSections 字段，占两个字节，它的值为 0x0006H，代表的是有 6 个区块，也可以说有 6 个节。
这里标记的是 TimeDateStamp 字段，占四个字节，它的值为 0x5C0748D5H，代表的是文件创建日期和时间。

技术分享图片

由上图可以看出，该文件创建时间为 2018-12-05 / 11:41:09。

这个值以0填充，用不到。
这个值以0填充，用不到。
这个字段就比较重要，划重点，SizeOfOptionalHeader，占两个字节，它的值为 0x00E0H，代表的是 `IMAGE_OPTIONAL_HEADER32` 结构的大小，在 32 位系统，它的值为 0x00E0H，在 64 位系统，它的值为 0x00F0H，
最后一个字段 Characteristics，占两个字节，它的值为 0x0102H，代表的是文件的属性。这个值是由 0x0100H 和 0x0002H 两者之和，0x0100H 这个值代表的是目标平台为 32 位机器，0x0002H 这个值代表文件可执行，如果为0，一般是链接出现了问题。

1 // 获取文件头
2     auto FileHeader = NtHeader->FileHeader;
3     // 接下来就是解析各字段
4     std::cout << "运行平台：0x" << std::hex << FileHeader.Machine << std::endl;
5     std::cout << "区块数目：0x" << std::hex << FileHeader.NumberOfSections << std::endl;
6     std::cout << "文件创建日期和时间：0x" << std::hex << FileHeader.TimeDateStamp << std::endl;
7     std::cout << "IMAGE_OPTIONAL_HEADER32结构大小：0x" << std::hex << FileHeader.SizeOfOptionalHeader << std::endl;
8     std::cout << "文件属性：0x" << std::hex << FileHeader.Characteristics << std::endl;

将上述代码插入到 return 0; 之前，运行如下：

技术分享图片

再将上面文件创建日期和时间进行转换，代码如下：

 1 // 获取文件头
 2     auto FileHeader = NtHeader->FileHeader;
 3     // 进行时间转换
 4     tm * FileCreateTime = gmtime((time_t*)&FileHeader.TimeDateStamp);
 5     // 接下来就是解析各字段
 6     std::cout << "运行平台：0x" << std::hex << FileHeader.Machine << std::endl;
 7     std::cout << "区块数目：0x" << std::hex << FileHeader.NumberOfSections << std::endl;
 8     std::cout << "文件创建日期和时间：" << std::dec << FileCreateTime->tm_year + 1900 << "-"
 9     << FileCreateTime->tm_mon + 1<< "-"
10     << FileCreateTime->tm_mday << " "
11     << FileCreateTime->tm_hour + 8 << ":"
12     << FileCreateTime->tm_min << ":"
13     << FileCreateTime->tm_sec << std::endl;
14     std::cout << "IMAGE_OPTIONAL_HEADER32结构大小：0x" << std::hex << FileHeader.SizeOfOptionalHeader << std::endl;

上面是用到了tm的结构，以及 gmtime 这个函数进行转换，在用之前需要包含头文件 time.h，运行如下：

技术分享图片

不过还是要注意下，首先 tm_year 这个值为十六进制，需转成十进制，而且要加上 1900，因为时间是从 1900 开始算，它的值为偏移，其次月是从 0 开始算的，所以要加 1，最后是时区问题，因为我这里位于东八区，所以小时需加上 8。另外关于调试的那两个字段，没有必要去对它深究，因为微软的VS已用了新的 Debug 格式，这个只是用来设置 COFF 符号，跟 COFF 符号有关，一般这个值都为 0，所以不探讨它。关于运行平台代码和文件属性代码可以去网上查表就行，这里就省略。

8. IMAGE_OPTIONAL_HEADER 结构

技术分享图片

上图展示的是 `IMAGE_OPTIONAL_HEADER32` 结构体各字段，这个结构体相对来说就比较大，我已经分析好了，这个是 32 位的，64 位的大体结构没变，只是有几个字段改成的 ULONGLONG 类型，那么它在实际内部是怎么样的呢？下面这张图是验证上面图片所叙述的。

技术分享图片

上图所标记的，为 `IMAGE_OPTIONAL_HEADER32` 结构所有成员，你也注意到了，在结尾处，有 .text，说明已经到了该结构体的末尾了，算了一下，恰好占了 224 个字节，这个值其实在 `IMAGE_FILE_HEADER` 中倒数第二个字段已经指出了，值为 0xE0，这个值相当于十进制中的 224。为了更好的说明，我用序号标记了各个字段，其中有一些为透明，一是没地方标，二是能看清实际数值大小，这样便于分析。

技术分享图片

以下是各字段解析：

Magic：这个是一个标记，它的值为 0x010BH，代表的是普通的可执行映象，一般是 0x010BH，如果是 64 位，则为 0x020BH，如果为 ROM 映象，该值为 0x0107H。
MajorLinkerVersion：链接程序主版本号，值为 0x0EH。
MinorLinkerVersion：链接程序次版本号，值为 0x00H。
SizeOfCode：所有含有代码区块的总大小，该值为 0x0031D000H，这个代码区块是带有 `IMAGE_SCN_CNT_CODE` 属性，这个值是向上对齐某一个值的整数倍。通常情况下，多数文件只有一个 Code 块，所以这个字段和 .text 块的大小匹配。
SizeOfInitializedData：所有初始化数据区块总大小，该值为 0x000B4000H，这个是在编译时所构成的块的大小（不包括代码段），一般这个值是不准确的。
SizeOfUninitializedData：所有未初始化数据区块总大小，该值为 0，这些块在程序开始运行时没有指定值，未初始化的数据通常在 .bss 块中。
AddressOfEntryPoint：程序执行入口 RVA，该值为 0x002B56D0H。在大多数可执行文件中，这个地址并不直接指向 Main、WinMain 或者是 DllMain，而是指向运行库代码并由它来调用上述函数。对于 DLL 来说，这个入口点是在程序初始化和关闭时以及线程创建和毁灭时被调用。
BaseOfCode：代码段的起始 RVA，该值为 0x00001000H，如果是用微软的链接器生成的，则该值通常是 0x00001000H。
BaseOfData：数据段的起始 RVA，该值为 0x0031E000H，数据段通常在内存的末尾，对于不同版本的微软链接器，这个值是不一致的，在64位可执行文件中是不出现的。
ImageBase：程序默认装入地址，该值为 0x00400000H，加载器试图在这个地址表装入 PE 文件，如果可执行文件是在这个地址装入的，那么加载器将跳过应用基址重定位的步骤。
SectionAlignment：内存中区块对齐大小，值为 0x00001000H，默认对齐尺寸是目标 CPU 的页尺寸，最小的对齐尺寸是一页 1000H（4KB），在 IA-64 上，这个值是 8KB。每个区块装入地址必定是本字段指定数值的整数倍。
FileAlignment：磁盘上 PE 文件内的区块对齐大小，值为 0x00000200H，对于 x86 的可执行文件，这个值通常是 200H 或 1000H，这是为了保证块总是从磁盘的扇区开始的，这个值必须是 2 的幂，最小为 200H。
MajorOpreatingSystemVersion：要求操作系统的最低版本号的主版本号，该值为 0x0006H，这个值似乎没什么用。
同上，没什么用。
同上，没什么用。
同上，没什么用。
同上，没什么用。
同上，没什么用。
同上，没什么用。
SizeOfImage：映象装入内存后的总尺寸，该值为 0x003D5000H，它指装入文件从 ImageBase 到最后一个块的大小，最后一个块根据其大小往上取整。
SizeOfHeaders：是 MS-DOS 头部、PE 头部、区块表的组合尺寸。该值为 0x00000400H。
CheckSum：校验和，IMAGEHLP.DLL 中的 CheckSumMappedFile 函数可以计算这个值，一般的EXE文件可以是 0，但一些内核模式的驱动程序和系统 DLL 必须有一个校验和。
Subsystem：一个标明可执行文件所期望的子系统的枚举值，这个值只对 EXE 是重要的。该值为 0x0003H。
DllCharacteristics：DllMain() 函数何时被调用，默认为 0。
SizeOfStackReserve：在 EXE 文件里，为线程保留的堆栈大小，它一开始只提交其中一部分，只有在必要时，才提交剩下的部分。
SizeOfStackCommit：在 EXE 文件里，一开始即被委派堆栈的内存数量，默认值为 4KB。
SizeHeapReserve：在 EXE 文件里，为进程的默认堆保留的内存，默认值为 1MB，但是在当前 Windows 里，堆值在用户不干涉的情况下就能增长超过这个值。
SizeOfHeapCommit：在 EXE 文件里，委派给堆的内存大小，默认值是 4KB。
LoaderFlag：与调试有关，默认为 0。
NumberOfRvaAndSizes：数据目录表的项数，这个字段一直以来都为 16。
DataDirectory[16]：数据目录表，由数个 `IMAGE_DATA_DIRECTORY` 结构组成，指向输入表、输出表、资源等数据。