PE文件笔记二 PE文件的两种状态

lyl610abc 发表于 2021-3-16 16:43

本帖最后由 lyl610abc 于 2021-4-3 11:50 编辑

PE笔记索引可前往：
PE文件笔记一 PE介绍
# PE两种状态

一个PE文件可以分为两种状态：运行态和非运行态

非运行态：当一个PE文件尚未被运行时，其数据**存储在磁盘中**，也就是(https://www.52pojie.cn/thread-1391994-1-1.html)中PE的状态

运行态：当一个PE文件被打开后，PE文件的相关数据将被**装载到内存中**，此时为运行态

------

在细讲PE两种状态前，回顾先前在笔记一中的相关内容：

## 整体结构图

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316164115579.png)

## 整体结构表

| 结构                      | 对应C数据结构                | 默认占用空间大小（单位字节） |
| --------------------------- | ------------------------------ | ---------------------------- |
| DOS MZ头                | _IMAGE_DOS_HEADER          | 64                         |
| DOS Stub                | 仅在MS-DOS系统下有效，不作研究 | 不固定                   |
| PE文件头                | _IMAGE_NT_HEADERS          | 4+20+224=248             |
| PE文件头标志             | Signature                   | 4                         |
| PE文件表头/标准PE头       | _IMAGE_FILE_HEADER          | 20                         |
| PE文件表头可选部分/扩展PE头 | _IMAGE_OPTIONAL_HEADER       | 224                      |
| 块表/节表                | _IMAGE_SECTION_HEADER       | 40                         |
| 块/节                   | 无                         | 由块表/节表决定          |

------

# 非运行态

## 回顾

先前的笔记一中只是简单介绍了非运行态下如何判断一个文件是否为PE文件

接下来讲讲为何能通过之前的方法来判断PE文件

------

**判断PE文件的流程**可概括为如下三步：

1. 判断头2个字节是否为4D 5A（ASCII码为MZ）
2. 找到3Ch位置数据
3. 根据第二步中的位置数据再找到对应的地址，判断这个地址是否为50 45 00 00（对应ACSII码为PE..）

------

| 地址 | 长度（单位字节） | 对应C的数据结构                      | 说明             | 值       | ASCII |
| ---- | ---------------- | --------------------------------------- | -------------------- | ----------- | ----- |
| 0 | 2             | _IMAGE_DOS_HEADER的第一个成员e_magic | DOS MZ头的第一个成员 | 4D 5A    | MZ |
| 3C | 2             | _IMAGE_DOS_HEADER的最后一个成员e_lfanew | 指出PE头文件偏移位置 | 不定    | 不定|
| | 4             | Signature                            | PE文件头标志       | 50 45 00 00 | PE..|

------

下面结合实例再来分析：

这次使用WinHex这个工具来进行查看

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315210005799.png)

------

此时对应的表格数据为：

| 地址 | 说明             | 值       | ASCII |
| ---- | -------------------- | ----------- | ----- |
| 0 | DOS MZ头的第一个成员 | 4D 5A    | MZ |
| 3C | 指出PE头文件偏移位置 | F0       |    |
| F0 | PE文件头标志       | 50 45 00 00 | PE..|

------

上面对一个PE文件的判断只涉及了DOS MZ头和PE文件头中的PE文件头标志

下面继续分析其它结构

------

## 后续分析

### PE文件头标志和标准PE头

从先前的PE的结构继续向后看24个字节（PE文件头标志的大小+标准PE头大小 4+20）得到扩展PE头的首地址

先前的地址为：F0

后来的地址为：0xF0+24=240+24=264=0x108

所以从F0～108为PE文件头标志和标准PE头

从108开始就是扩展PE头了

PE文件头标志和标准PE头：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315212241373.png)

------

### 扩展PE头

从先前得到的扩展PE头地址继续向后看224个字节（扩展PE头大小）得到块表的首地址

先前的地址为：108

后来的地址为：0x108+224=264+224=488=0x1E8

所以从108~1E8为扩展PE头

从1E8开始就是块表了

扩展PE头：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315213947563.png)

------

### 块表

从先前得到的块表头地址继续向后看40个字节（块表大小）得到第二个块表的首地址

先前的地址为：1E8

后来的地址为：0x1E8+40=488+40=528=0x210

所以从1E8~210为第一个块表

从210开始就是第二个块表了

第一个块表：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315234922585.png)

------

同理可得剩下的几个块表

第二个块表：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315235048573.png)

地址从210~238

------

第三个块表：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315235154581.png)

地址从238~260

------

第四个块表：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315235402774.png)

地址从260~288

------

第五个块表：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210315235504709.png)

地址从288~2B0

------

#### 汇总块表

| 块名称 | 块地址|
| ------ | ------- |
| .text| 1E8~210 |
| .rdata | 210~238 |
| .data| 238~260 |
| .rsrc| 260~288 |
| .reloc | 288~2B0 |

------

### 块表后的空隙

块表后面跟着的应该是块，但在块表后和块之前却多出了一段空间

这里为2B0~400

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316000131381.png)

------

先前的PE结构中间都没有空隙，为**连续存储**

但在**块表和块之间是可能存在空隙的**，这个空隙里一般被填充为编译器插入的数据（也可以没有,就是此时的情况）

这段空隙的修改并不会导致程序不可运行，因而可被拿来写入自己想要的代码来对程序进行修改

------

**为什么会存在这段空隙？**

这段空隙存在的原因在于块表和块并没有**连续存储**

所以这段空隙的存在与否及长度取决于 **块的起始位置**

而块的起始位置则**由扩展PE头中的某个成员决定**

------

给出扩展PE头在C中的定义：

```c
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// Standard fields.
//
WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint;
DWORD BaseOfCode;
DWORD BaseOfData;
//
// NT additional fields.
//
DWORD ImageBase;
DWORD SectionAlignment;
DWORD FileAlignment;                            //<--- 文件对齐
WORD MajorOperatingSystemVersion;
WORD MinorOperatingSystemVersion;
WORD MajorImageVersion;
WORD MinorImageVersion;
WORD MajorSubsystemVersion;
WORD MinorSubsystemVersion;
DWORD Win32VersionValue;
DWORD SizeOfImage;
DWORD SizeOfHeaders;                            //<--- 决定块的起始位置
DWORD CheckSum;
WORD Subsystem;
WORD DllCharacteristics;
DWORD SizeOfStackReserve;
DWORD SizeOfStackCommit;
DWORD SizeOfHeapReserve;
DWORD SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory;
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
```

------

找到结构体中的SizeOfHeaders成员（DWORD类型占4个字节）

SizeOfHeaders的含义为**3个头按照文件对齐后的大小**：（DOS头大小+PE头大小+块表大小）加完的结果进行**文件对齐**后得到的大小

头大小相加很好理解，按照之前得到的头大小和为：2B0，于是问题就在于文件对齐

#### 什么是文件对齐

讲到文件对齐就涉及到扩展PE头中的另一个成员：FileAlignment（DWORD类型占4个字节）

文件对齐就是要求SizeOfHeaders必须为FileAlignment的**整数倍**

------

知道了由来以后，验证一下

前面已经得知了扩展PE头的首地址为108

从108开始往后找36个字节（中间间隔了1个WORD，2个BYTE，8个DWORD，即1\*2+2\*1+8\*4=36）

FileAlignment的地址为：0x108+36=264+36=300=0x12C

FileAlignment：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316003503508.png)

FileAlignment为00 00 02 00=0x200（小端存储）

前面得到的头大小和为0x2B0显然不是FileAlignment的整数倍

于是将SizeOfHeaders设置为FileAlignment的整数倍：(2B0/200+1)*200=400

得出的SizeOfHeaders的大小应该为0x400

------

再来验证一下SizeOfHeaders的大小

前面得到的FileAlignment的地址为12C

从12C开始往后找24个字节（中间间隔了6个WORD，3个DWORD，即6\*2+3\*4=24）

SizeOfHeaders的地址为：0x12C+24=300+24=324=0x144

SizeOfHeaders：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316003735412.png)

SizeOfHeaders为 00 00 04 00=0x400（小端存储）

得到的大小和计算出来的大小一致，验证完毕

------

#### 为什么要文件对齐

和内存对齐一样，都是为了使执行时的效率更高，有关内存对齐可参考：[逆向基础笔记十八汇编结构体和内存对齐](https://www.52pojie.cn/thread-1385641-1-1.html#37246226_%E5%86%85%E5%AD%98%E5%AF%B9%E9%BD%90)

PS：上面的内存对齐为程序中**局部的内存对齐**，主要针对的是编程时的变量、结构体等，和后面要讲的内存对齐要区别开

------

### 块

块的起始地址由块表中的PointerToRawData决定，**第一个块**的起始地址则由上面的SizeOfHeaders决定

块部分存储的为数据，如何存储由块表决定，这里主要探讨**每个块的起始地址、块大小、结束地址**，其它留作之后的笔记

给出块表在C中的定义

```c
#define IMAGE_SIZEOF_SHORT_NAME          8
typedef struct _IMAGE_SECTION_HEADER {
BYTE Name;
union {
         DWORD PhysicalAddress;
         DWORD VirtualSize;
} Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;                      //<--- 块的大小
DWORD PointerToRawData;             //<--- 块在磁盘文件中的偏移
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
```

------

#### 块的起始地址

找到结构体中的PointerToRawData成员（DWORD类型占4个字节）

PointerToRawData的含义为**该块在磁盘文件中的偏移**

前面已经知道第一个块表的首地址为1E8

从1E8开始往后找20个字节（中间间隔了1个BYTE，3个DWORD，即1\*8+3\*4=20）

PointerToRawData的地址为：0x1E8+20=488+20=508=0x1FC

PointerToRawData：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316011603629.png)

PointerToRawData为00 00 04 00=0x400

和通过SizeOfHeaders得到的一致，验证了**第一个**块的PointerToRawData由SizeOfHeaders决定

#### 块的大小

SizeOfRawData为块的大小（文件对齐后）

SizeOfRawData就在PointerToRawData前面

所以其地址为：PointerToRawData地址-4=0x1FC-4=0x1F8

SizeOfRawData：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316152420615.png)

SizeOfRawData为00 92 19 00=0x199200

块的大小和前面三个头(DOS部首+PE文件头+块表)的大小一样，也要**满足文件对齐**

先前得到的FileAlignment为0x200，这里的SizeOfRawData：0x199200为FileAlignment的整数倍，满足文件对齐

------

#### 块的结束地址(下一个块的起始地址)

块的结束地址为块的起始地址+块的大小

即块的结束地址=0x400+0x199200=199600

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316153738194.png)

------

可以看到第一个块和第二个块之前是**存在空隙**的，这段空隙也是由于**文件对齐**产生的

------

## 小总结

在非运行态下：

- DOS部首和PE文件头及块表连续存储，中间没有空隙
- 而块表和块之间由于**文件对齐**可能会存在空隙
- 块和块之间也由于**文件对齐**可能会存在空隙

------

相关数据结构成员：

| 数据结构成员 | 所属数据结构 | 说明                                                       |
| ---------------- | ------------ | ------------------------------------------------------------ |
| SizeOfHeaders | 扩展PE头 | 头大小（文件对齐后）                                     |
| FileAlignment | 扩展PE头 | 文件对齐                                                 |
| PointerToRawData | 块表       | 第一个块表的PointerToRawData由SizeOfHeaders决定，后面块表的PointerToRawData由前一个块表的PointerToRawData+SizeOfRawData决定 |
| SizeOfRawData | 块表       | 块表的大小（文件对齐后）                                  |

------

记录一下各结构的起始和结束位置，方便和运行态进行比较

| 结构    | 起始地址 | 结束地址 | 大小                |
| ---------- | -------- | -------- | ---------------------- |
| DOS部首 | 0    | F0    | 0xF0=240             |
| PE文件头 | F0    | 1E8    | 0xF8=244=224+40    |
| 块表    | 1E8    | 2B0    | 0xC8=200=5\*40       |
| 前三个结构 | 0    | 400    | 0x400（文件对齐后） |
| 第一个块 | 400    | 199600 | 0x199200（文件对齐后） |

------

# 运行态

前面介绍了非运行态（硬盘状态）下PE文件的结构，现在看看运行态（内存状态）下PE文件的结构

## 加载运行态的PE文件

**1.启动PE文件**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316132316337.png)

------

**2.然后返回WinHex，点击工具→打开RAM(R)... 或直接使用快捷键Alt+F9**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316132406704.png)

------

**3.打开后显示如下：**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316132549551.png)

**选中我们要分析的PE文件，使其展开**

------

**4.展开后显示如下：**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316132819269.png)

**选中.exe打开**

------

**5.最后确定即可**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316133031067.png)

------

## 分析运行态的PE文件

按照先前分析的流程，再分析一遍运行态下的PE文件

### DOS部首和PE头标志

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316134218062.png)

此时的DOS部首起始地址为400000，结束地址为4000F0

------

### PE文件头标志和标准PE头

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316134123745.png)

此时PE文件头的起始地址为4000F0，结束地址为400108

------

### 扩展PE头

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316134503765.png)

此时PE文件头的起始地址为400108，结束地址为4001E8

------

### 块表

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316134642926.png)

此时块表的起始地址为4001E8，结束地址为4002B0

------

### 块表后的空隙

从前面的分析来看，在块表前的结构在运行态和非运行态除了起始地址不同以外，其它地方并无不同

起始地址的由来等相关内容留作之后的笔记说明

按照经验，块表后的空隙也应该是持续到先前的400+400000=400400

于是前往查看：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316135241232.png)

------

发现并非如此，400400仍然为空隙

先前分析得知在非运行态块表后的空隙是因为文件对齐产生的

而在运行态中，显然就**不是由文件对齐决定的**

------

接着向下查看，找到**块的起始位置**

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316135922474.png)

------

发现此时块的起始位置为401000，偏移为1000，而不是非运行态的400

于是熟悉的问题又回来了：

**为什么会存在这段空隙？**

和先前的文件对齐类似，当程序处于运行态时，会有另一种对齐方式：**内存对齐**

和内存对齐相关的属性和文件对齐（FileAlignment）类似，也是取决于扩展PE头中的一个成员

------

再次给出扩展PE头在C中的定义：

```c
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// Standard fields.
//
WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint;
DWORD BaseOfCode;
DWORD BaseOfData;
//
// NT additional fields.
//
DWORD ImageBase;
DWORD SectionAlignment;                      //<--- 内存对齐
DWORD FileAlignment;                            //<--- 文件对齐
WORD MajorOperatingSystemVersion;
WORD MinorOperatingSystemVersion;
WORD MajorImageVersion;
WORD MinorImageVersion;
WORD MajorSubsystemVersion;
WORD MinorSubsystemVersion;
DWORD Win32VersionValue;
DWORD SizeOfImage;
DWORD SizeOfHeaders;                            //<--- 决定块的起始位置
DWORD CheckSum;
WORD Subsystem;
WORD DllCharacteristics;
DWORD SizeOfStackReserve;
DWORD SizeOfStackCommit;
DWORD SizeOfHeapReserve;
DWORD SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory;
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
```

------

找到结构体中的SectionAlignment成员，会发现它就在FileAlignment（文件对齐）成员的上面

知道了由来以后，验证一下

前面已经得知了扩展PE头的首地址为400108

从400108开始往后找32个字节（中间间隔了1个WORD，2个BYTE，7个DWORD，即1\*2+2\*1+7\*4=32）

SectionAlignment的地址为：0x400108+32=0x400000+264+32=0x400000+296=0x400128

SectionAlignment：

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316141510008.png)

SectionAlignment为00 10 00 00=0x1000（小端存储）

前面得到的头大小和为0x2B0显然不是SectionAlignment的整数倍

头大小应该设置为SectionAlignment的整数倍：(2B0/1000+1)*1000=1000

PS：这里的头大小不会被设置到SizeOfHeaders，因为SizeOfHeaders为文件对齐专用

### 块

在非运行态中，块的起始位置由PointerToRawData决定，且PointerToRawData必须为FileAlignment的整数倍

但在运行态中，块的起始位置则并不由PointerToRawData决定，PointerToRawData和SizeOfHeaders一样都为文件对齐专用

运行态块存储涉及内容较多，这里只查看一下第一个块的起始地址、结束地址和大小，**不作具体探究**，其它留作之后的笔记

#### 块的起始地址

第一个块的起始地址取决于（DOS部首+PE文件头+块表）的总大小进行内存对齐后的结果

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316162649154.png)

第一个块的起始地址=0x400000+0x1000=0x401000

------

#### 块的结束地址

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316162347979.png)

第一个块的结束地址=0x59B000

------

#### 块的大小

块的大小=块的结束地址-块的起始地址=0x59B000-0x401000=0x19A000（满足内存对齐）

------

**运行态时，块的大小满足内存对齐，非先前的文件对齐**

------

## 小总结

在运行态下：

- DOS部首和PE文件头及块表连续存储，中间没有空隙
- 而块表和块之间由于**内存对齐**可能会存在空隙
- 块和块之间也由于**内存对齐**可能会存在空隙

------

相关数据结构成员：

| 数据结构成员 | 所属数据结构 | 说明 |
| ---------------- | ------------ | -------- |
| SectionAlignment | 扩展PE头 | 内存对齐 |

------

各结构的起始和结束位置：

| 结构    | 起始地址 | 结束地址 | 大小                |
| ---------- | -------- | -------- | ---------------------- |
| DOS部首 | 400000 | 4000F0 | 0xF0=240             |
| PE文件头 | 4000F0 | 4001E8 | 0xF8=244=224+40    |
| 块表    | 4001E8 | 4002B0 | 0xC8=200=5\*40       |
| 前三个结构 | 400000 | 401000 | 0x1000（内存对齐后） |
| 第一个块 | 401000 | 59B000 | 0x19A000（内存对齐后） |

------

# 对比PE两种状态

本笔记主要针对PE两种状态中的文件对齐和内存对齐进行比较，**其它的内容暂时没有涉及**，将在后续笔记里陆续提到

## 相同点

无论是在运行态还是在非运行态，DOS部首、PE文件头、块表块表均为连续存储，中间没有空隙

第一个块表的首地址都受DOS部首大小+PE文件头大小+块表大小影响，都需要对齐

块和块之间也都需要对齐

## 不同点

运行态和非运行态的起始地址不同

在非运行态中，块表和块之间的空隙由**文件对齐**产生，块和块之间的空隙由**文件对齐**产生

在运行态中，块表和块之间的空隙由**内存对齐**产生，块和块之间的空隙由**内存对齐**产生

------

## 非运行态和运行态映射图

!(https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/image-20210316163800340.png)

# 附件

附上本笔记中分析的EverEdit文件：[点我下载](https://610-pic-bed.oss-cn-shenzhen.aliyuncs.com/EverEdit.zip?versionId=CAEQHhiBgID6g6vXxBciIDMxMjY5Y2Q0NGE5NTRkNmNiNTUwOGM0YjdmZTQxMTI3)

Ningcc 发表于 2023-7-8 13:32

对于文中提到的“验证了第一个块的PointerToRawData由SizeOfHeaders决定，感觉描述有误，微软对于SIzeOfHeaders的解释是这样的 The combined size of an MS-DOS stub, PE header, and section headers rounded up to a multiple of FileAlignment.，文中提到的两个地址都为0x400h，应该是凑巧得到的，我查看PE结构的时候，也有刚好两者相同的时候，但是二者没有联系；在尝试其他PE文件的时候，得到SizeOfHeader的值为400h，但是实际第一个节的地址为600h，节的地址应该是根据节表中的SizeOfRawData给出，跟SizeOfHeaders没有关系。

lyiann 发表于 2021-3-30 23:12

运行态的Section在内存中的位置和大小由SECTION_HEADER的VirtualAddress和VirtualSize决定，对齐是根据OPTIONAL_HEADER的SectionAlignment进行调整

帝班漢卿大牛 发表于 2021-3-16 16:45

这个不错哦感谢分享

yesyao123 发表于 2021-3-16 16:45

厉害，看不懂啊

qianshang666 发表于 2021-3-16 17:24

虽然我不是学这个的，但我还是来支持了{:301_998:}

冷月暗雾飞扬 发表于 2021-3-16 18:21

感谢lz分享，来学习了！

qmydate 发表于 2021-3-16 19:34

python小甲鱼 发表于 2021-3-16 19:58

这做的太棒了

diqi6688 发表于 2021-3-16 20:18

厉害厉害

plsm 发表于 2021-3-16 20:23

很牛逼，然而我对这方面不懂

tetrahedro 发表于 2021-3-16 20:41

感谢分享，之前只看过Linux的。

页: [1] 2 3 4

吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn's Archiver

PE文件笔记二 PE文件的两种状态