本来打算国庆去上海观看世博会最后精彩去的，因为有些事要做，所以就没去了，
还是在家呆着吧，给大家重温一下PE文件的知识，国庆七天每天都会更新，我会从最基础的PE理论再结合编程给大家详细讲解，参考书籍主要两本：看雪《加密与解密》第三版，老罗《Windows下32位汇编程序设计》第二版，如果大家看了我的PE文件详解能给大家一点点小的帮助，我想国庆的努力也没白费，呵呵~~其实论坛上，这样的文章也讲了不少，这里给大家复习复习，熟能生巧嘛！！如果您对PE文件已经很熟悉了，就可以直接跳过了总复习一，后面的会更加精彩，呵呵，免得浪费你保贵的时间~~
PE格式是Windows下最常用的可执行文件格式，在DOS时代COM文件是最早的也是结构最简单的可执行文件，COM文件中仅包含可执行代码，没有附带任何“支持性”数据，所以，第一句执行指令必须安排在文件头部：再就是没有重定位的信息，这样代码中不能有跨段操作数据的指令，造成代码和数据，甚至包括堆栈只能限制在同一个64KB的段中，由于这个原因，DOS系统中又定义了一种可执行文件---EXE文件，EXE文件在代码的前面加了一个文件头，文件头中包括各种说明数据，如文件入口，堆栈位置，重定位表等，操作系统根据文件头的信息将代码部分装入内存，根据重定位表修正代码，最后在设置好堆栈后从文件头中指定的入口开始执行。
当Windows3.X出现的时候，可执行文件中出现了32位代码，程序运行时转到保护模式之前需要在实模式下做一些初始化，这样实模式的16位代码必须和32位代码一起放在可执行文件中，旧的DOS可执行文件格式无法满足需要，所以Windows3.X执行文件使用新的LE格式的可执行文件(Linear executable/线性可执行文件)，Window9x中的VxD程序也是使用LE格式，因为这些驱动程序中也同时包括16位和32位代码。
而在Windows 9x，Windows NT,Windows 2000下，纯32位可执行文件都使用微软设计的一种新格式——PE格式(Portable Executable File Format/可移值的执行体）。
在学习的同时建议用Stud_PE工具配合！！！
PE文件的框架结构如下图所示：
PE基本概念：
PE文件使用的是一个平面地址空间，所有代码和数据都被合并在一起，组成一个很大的结构。文件的内容被分割为不同的区块（Section)，区块中包含代码或数据，各个区块按页边界来对齐，区块没有大小限制，是一个连续结构，每个块都有它自己在内存中的一套属性，比如：这个块是否包含代码，是否只读或可读/写等。
认识PE文件不是作为单一内存映射文件被装入内存。Windows加载器（又称PE装载器）遍历PE文件并决定文件的哪一部分被映射，这种映射方式是将文件较高的偏移位置映射到较高的内存地址中。当磁盘文件一旦被装入内存中，磁盘上的数据结构布局和内存中的数据结构布局是一致的。这样如果在磁盘的数据结构中寻找一些内容，那么几乎都能在被装入到内存中找到相同的信息。但数据之间的相对位置可能改变，其某项的偏移地址可能区别于原始的偏移地置，不管怎样，所有表现出来的信息都允许从磁盘文件偏移到内存偏移的转换，如图所示：
从图中可以看出映射方式为：低位到低位，高位到高位的方式
这里一定要强调一点：RVA（虚拟地址），FileOffset（文件偏移地址），VA（虚拟地址），
ImageBase（基地址）,入口点(Entry Point)
RVA（Relative Virtual Address)的缩写，相对虚拟地址，这是一个“相对”地址，PE文件的各种数据结构中涉及地址的字段大部分都是以RVA表示的。
FileOffset（文件偏移地址）
FileOffset是当PE文件储存在磁盘上时，各数据的地址称做为文件偏移地址（File Offset)。文件偏移地址从PE文件的第一个字节开始计数，起始值为0
VA（虚拟地址）
VA程序访问存储器所使用的逻辑地址称为虚拟地址（Virtual Address)，又称为内存偏移地址
ImageBase（基地址）
ImageBase文件执行时将被映射到指定内存地址中，这个初始内存地址称为基地址(ImageBase)。这个值是由PE文件决定的，按照默认设置。Visual C++建立的EXE文件的基地址为00400000h,DLL文件基地址是10000000h，但可以改变这个地址，有很多种方法，以后在慢慢给大家介绍，书上说的是在链接程序的/BASE选项中改为你的程序的入口函数名称就行了。
Entry Point（入口点）
Entry Point是指PE文件执行时的入口点(Entry Point)。也就是说，程序在执行时的第一行代码的地址应该就是这个值。大家用LoadPE工具就可以查看PE文件的区段表！
汇编中虚拟地址(VRA)与文件偏移地址(FileOffset)的相互转换:
+---------+---------+---------+---------+---------+---------+---------+--------------------+
| 段名称 虚拟地址 虚拟大小 物理地址 物理大小 标志
|+---------+---------+---------+---------+---------+---------+----------+--------------------+
| Name VOffset VSize ROffset RSize Flags
|+---------+---------+---------+---------+---------+---------+-----------+--------------------+
|| .text 00001000 00000092 00000400 00000200 60000020
|| .rdata 00002000 000000F6 00000600 00000200 40000040
|| .data 00003000 0000018E 00000800 00000200 C0000040
|| .rsrc 00004000 000003A0 00000A00 00000400 C0000040
|+---------+---------+---------+---------+---------+---------+-----------+----------------------+
将RVA转换为File Offset，给大家一个非常经典的公式：
设：VK为相对虚拟地址RVA与文件偏移地址File Offset的差值
VA=ImageBase+RVA
File Offset = RVA ---VK
File Offset = VA---ImageBase---VK
大家如果不想自己去算，也可以用LoadPE中的转换工具来计算，如图所示：
好了，上面基本上把基础知识介绍了一遍，下面我们要着手去研究PE的内部各个部分结构。
DOS文件头和DOS块
PE文件中还包括一个标准的DOS可执行文件部分，如图17.1中左边的①所示，这看上去有些奇怪，但是这对于可执行文件的向下兼容性来说却是不可缺少的。
但是这种方法也存在一个问题，假如一个PE格式的可执行文件在Windows中执行，那没有任何异常，因为Windows能够识别PE文件头并正确装入，但如果将PE文件放入DOS执行，那么DOS系统肯定无法识别PE文件头，假如PE文件的头部不包括一个DOS部分的话，那么按照前面介绍的规则，PE文件头的数据会被DOS系统作为代码装入并执行，这种操作几乎可以肯定会让系统立刻挂起。
为了避免这种情况，PE文件的头部包括了一个标准的DOS MZ格式的可执行部分，这样万一在DOS下执行一个PE文件，系统可以将文件解释为DOS下的.exe可执行格式，并执行DOS部分的代码。
一般来说，DOS部分的执行代码只是简单地显示一个“This program cannot be run in DOS mode.”就退出了，这段简单的代码是编译器自动生成的。
PE文件中的DOS部分由MZ格式的文件头和可执行代码部分组成，可执行代码被称为“DOS块”（DOS stub）。MZ格式的文件头由IMAGE_DOS_HEADER结构定义：
IMAGE_DOS_HEADER STRUCT
e_magic WORD ? ；DOS可执行文件标记，为“MZ”
e_cblp WORD ?
e_cp WORD ?
e_crlc WORD ?
e_cparhdr WORD ?
e_minalloc WORD ?
e_maxalloc WORD ?
e_ss WORD ? ；DOS代码的初始化堆栈段
e_sp WORD ? ；DOS代码的初始化堆栈指针
e_csum WORD ?
e_ip WORD ? ；DOS代码的入口IP
e_cs WORD ? ；DOS代码的入口CS
e_lfarlc WORD ?
e_ovno WORD ?
e_res WORD 4 dup(?)
e_oemid WORD ?
e_oeminfo WORD ?
e_res2 WORD 10 dup(?)
e_lfanew DWORD ? ；指向PE文件头
IMAGE_DOS_HEADER ENDS
DOS文件头的前面部分并不陌生，第一个字段e_magic被定义成字符“MZ”（在Windows.inc文件中已经预定义为IMAGE_DOS_SIGNATURE）作为识别标志，后面的一些字段指明了入口地址、堆栈位置和重定位表位置等。
其中我们还要关心的是e_lfanew这个字段，e_lfanew字段是真正PE文件头的相对偏移（RVA），其指出真正PE头的文件偏移位置，它占用四个字节，位于文件开始偏移3Ch字节中。
分析如图所示：
从图中我们可以看到e_lfanew的值为000000c0，也就是说000000c0处是我们的PE文件头的位置。
PE文件头
紧跟在DOS stub的是PE文件头，从DOS文件头的e_lfanew字段（文件偏移003ch)得到真正PE文件头位置后，现在来看看它的定义，PE文件头是由IMAGE_NT_HEADERS结构定义的：
IMAGE_NT_HEADERS STRUCT
Signature DWORD ? ；PE文件标识
FileHeader IMAGE_FILE_HEADER <>
OptionalHeader IMAGE_OPTIONAL_HEADER32 <>
IMAGE_NT_HEADERS ENDS
PE文件头的第一个双字是一个标志，它被定义为00004550h，也就是字符“P”，“E”加上两个0，这也是“PE”这个称呼的由来，大部分的文件属性由标志后面的IMAGE_FILE_HEADER和IMAGE_OPTIONAL_HEADER32结构来定义，从名称看，似乎后面的这个PE文件表头结构是可选的（Optional），但实际上这个名称是名不符实的，因为它总是存在于每个PE文件中。
Signature字段：
在一个有效的PE文件里，Signature字段被设置为00004550h。ASCII码字符是"PE00",
#define IMAGE_NT_SIGNATURE定义了这个信息。
#define IMAGE_NT_SIGNATURE 0x00004550
"PE\0\0"字段是PE文件头的开始，DOS头部的e_lfanew字段正是指向"PE\0\0"。
IMAGE_FILE_HEADER结构
IMAGE_FILE_HEADER STRUCT
Machine WORD ? ；0004h - 运行平台
NumberOfSections WORD ? ；0006h - 文件的节数目
TimeDateStamp DWORD ? ；0008h - 文件创建日期和时间
PointerToSymbolTable DWORD ? ；000ch - 指向符号表（用于调试）
NumberOfSymbols DWORD ? ；0010h - 符号表中的符号数量（用于调试）
SizeOfOptionalHeader WORD ? ；0014h - IMAGE_OPTIONAL_HEADER32结构的长度
Characteristics WORD ? ；0016h - 文件属性
IMAGE_FILE_HEADER ENDS
Machine字段
用来指定文件的运行平台，常见的定义值见表17.1所示。Windows可以运行在Intel和SUN等几种不同的硬件平台上，不同平台指令的机器码是不同的，为不同平台编译的可执行文件显然无法通用。如果Windows检测到这个字段指定的适用平台与当前的硬件平台不兼容，它将拒绝装入这个文件。
NumberOfSections字段
指出文件中存在的节的数量（如图17.1中的④所示），同样，节表的数量（如图17.1中的③所示）也等于节的数量。
TimeDateStamp字段
编译器创建此文件的时间，它的数值是从1969年12月31日下午4：00开始到创建时间为止的总秒数。
PointerToSymbolTable和NumberOfSymbols字段
这两个字段并不重要，它们与调试用的符号表有关。
SizeOfOptionalHeader字段
紧接在当前结构下面的IMAGE_OPTIONAL_HEADER32结构的长度，这个值等于00e0h。
Characteristics字段
属性标志字段，它的不同数据位定义了不同的文件属性，具体内容如表17.2所示，这是一个很重要的字段，不同的定义将影响系统对文件的装入方式，比如，当位13为1时，表示这是一个DLL文件，那么系统将使用调用DLL入口函数的方式调用文件入口，否则的话，表示这是一个普通的可执行文件，系统直接跳到入口处执行。对于普通的可执行PE文件，这个字段的值一般是010fh，而对于DLL文件来说，这个字段的值一般是210eh。
如图所示：
IMAGE_OPTIONAL_HEADER32结构
定义IMAGE_OPTIONAL_HEADER32结构的本意在于让不同的开发者能够在PE文件头中使用自定义的数据，这就是结构名称中“Optional”一词的由来，但实际上IMAGE_FILE_HEADER结构不足以用来定义PE文件的属性，反而在这个“可选”的部分中有着更多的定义数据，对于读者来说，可以完全不必考虑这两个结构的区别在哪里，只要把它们当成是连在一起的“PE文件头结构”就可以了。
IMAGE_OPTIONAL_HEADER32 STRUCT
Magic WORD ? ;0018h 107h＝ROM Image,10Bh=exe Image
MajorLinkerVersion BYTE ? ;001ah 链接器版本号
MinorLinkerVersion BYTE ? ;001bh
SizeOfCode DWORD ? ;001ch 所有含代码的节的总大小
SizeOfInitializedData DWORD? ;0020h所有含已初始化数据的节的总大小
SizeOfUninitializedData DWORD ? ;0024h 所有含未初始化数据的节的大小
AddressOfEntryPoint DWORD ? ;0028h 程序执行入口RVA
BaseOfCode DWORD ? ;002ch 代码的节的起始RVA
BaseOfData DWORD ? ;0030h 数据的节的起始RVA
ImageBase DWORD ? ;0034h 程序的建议装载地址
SectionAlignment DWORD ? ;0038h 内存中的节的对齐粒度
FileAlignment DWORD ? ;003ch 文件中的节的对齐粒度
MajorOperatingSystemVersion WORD ? ;0040h 操作系统主版本号
MinorOperatingSystemVersion WORD ? ;0042h 操作系统副版本号
MajorImageVersion WORD ? ;0044h可运行于操作系统的最小版本号
MinorImageVersion WORD ? ;0046h
MajorSubsystemVersion WORD ?;0048h 可运行于操作系统的最小子版本号
MinorSubsystemVersion WORD ? ;004ah
Win32VersionValue DWORD ? ;004ch 未用
SizeOfImage DWORD ? ;0050h 内存中整个PE映像尺寸
SizeOfHeaders DWORD ? ;0054h 所有头＋节表的大小
CheckSum DWORD ? ;0058h
Subsystem WORD ? ;005ch 文件的子系统
DllCharacteristics WORD ? ;005eh
SizeOfStackReserve DWORD ? ;0060h 初始化时的堆栈大小
SizeOfStackCommit DWORD ? ;0064h 初始化时实际提交的堆栈大小
SizeOfHeapReserve DWORD ? ;0068h 初始化时保留的堆大小
SizeOfHeapCommit DWORD ? ;006ch 初始化时实际提交的堆大小
LoaderFlags DWORD ? ;0070h 未用
NumberOfRvaAndSizes DWORD ? ;0074h 下面的数据目录结构的数量
DataDirectory IMAGE_DATA_DIRECTORY 16 dup(<>) ;0078h
IMAGE_OPTIONAL_HEADER32 ENDS
这个结构的字段比较多，我就不一一介绍了，具体请参考《加密与解密》第三版第十章PE文件格式，下面介绍几个比较重要的：
AddressOfEntryPoint字段
指出文件被执行时的入口地址，这是一个RVA地址（RVA的含义在下一节中详细介绍）。如果在一个可执行文件上附加了一段代码并想让这段代码首先被执行，那么只需要将这个入口地址指向附加的代码就可以了。
ImageBase字段
指出文件的优先装入地址。也就是说当文件被执行时，如果可能的话，Windows优先将文件装入到由ImageBase字段指定的地址中，只有指定的地址已经被其他模块使用时，文件才被装入到其他地址中。链接器产生可执行文件的时候对应这个地址来生成机器码，所以当文件被装入这个地址时不需要进行重定位操作，装入的速度最快，如果文件被装载到其他地址的话，将不得不进行重定位操作，这样就要慢一点。
对于EXE文件来说，由于每个文件总是使用独立的虚拟地址空间，优先装入地址不可能被其他模块占据，所以EXE总是能够按照这个地址装入，这也意味着EXE文件不再需要重定位信息。对于DLL文件来说，由于多个DLL文件全部使用宿主EXE文件的地址空间，不能保证优先装入地址没有被其他的DLL使用，所以DLL文件中必须包含重定位信息以防万一。因此，在前面介绍的IMAGE_FILE_HEADER 结构的Characteristics字段中，DLL文件对应的IMAGE_FILE_RELOCS_STRIPPED位总是为0，而EXE文件的这个标志位总是为1。
在链接的时候，可以通过对link.exe指定/base:address选项来自定义优先装入地址，如果不指定这个选项的话，一般EXE文件的默认优先装入地址被定为00400000h，而DLL文件的默认优先装入地址被定为10000000h。
SectionAlignment字段和FileAlignment字段
SectionAlignment字段指定了节被装入内存后的对齐单位。也就是说，每个节被装入的地址必定是本字段指定数值的整数倍。而FileAlignment字段指定了节存储在磁盘文件中时的对齐单位。
DataDirectory字段
这个字段可以说是最重要的字段之一，它由16个相同的IMAGE_DATA_DIRECTORY结构组成，虽然PE文件中的数据是按照装入内存后的页属性归类而被放在不同的节中的，但是这些处于各个节中的数据按照用途可以被分为导出表、导入表、资源、重定位表等数据块，这16个IMAGE_DATA_DIRECTORY结构就是用来定义多种不同用途的数据块的（如表17.4所示）。IMAGE_DATA_DIRECTORY结构的定义很简单，它仅仅指出了某种数据块的位置和长度。
IMAGE_DATA_DIRECTORY STRUCT
VirtualAddress DWORD ? ；数据的起始RVA
Size DWORD ? ；数据块的长度
IMAGE_DATA_DIRECTORY ENDS
一共有十六个IMAGE_DATA_DIRECTORYENDS结构
IMAGE_DIRECTORY_ENTRY_EXPORT 导出表
IMAGE_DIRECTORY_ENTRY_IMPORT 导入表
IMAGE_DIRECTORY_ENTRY_RESOURCE 资源
IMAGE_DIRECTORY_ENTRY_EXCEPTION 异常（具体资料不详）
IMAGE_DIRECTORY_ENTRY_SECURITY 安全（具体资料不详）
IMAGE_DIRECTORY_ENTRY_BASERELOC 重定位表
IMAGE_DIRECTORY_ENTRY_DEBUG 调试信息
IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 版权信息
IMAGE_DIRECTORY_ENTRY_GLOBALPTR 具体资料不详
IMAGE_DIRECTORY_ENTRY_TLS Thread Local Storage
IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 具体资料不详
IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 具体资料不详
IMAGE_DIRECTORY_ENTRY_IAT 导入函数地址表
IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 具体资料不详
IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 具体资料不详
未使用保留
PE文件中定位输出表，输入表和资源等重要数据时，就是从IMAGE_DATA_DIRECTORY结构开始的。
如图所示：
由于数据结构太多，这里只给出部分，具体请参考《加密与解密》第三版
如图七所示，数据目录表位于138---1b07h之间，每个成员占8个字节，分别指向相关的结构，前面四个字节代表VirtualAddress（数据块的起始RVA），后面四个字节代表Size（数据块的长度），比如上面程序中没有输出表，有输入表，且在00000140h处，我们就可以得出此程序的输入表RVA为00002090,Size为0000003Ch
上面得到的结果和用LoadPE查看的结果一样，呵呵，如图所示：
上面将PE文件结构的文件头介绍了一下，下面我们开始重点讲解PE中的各个区块
区块表
紧跟在IMAGE_NT_HEADERS后面的是区块表，它是一个IMAGE_SECTION_HEADER结构数组。每个IMAGE_SECTION_HEADER结构包含了它所关联区块的信息，如位置，长度，属性；该数组的数目由IMAGE_NT_HEADERS.FileHeader.NumberOfSections指出。
IMAGE_SECTION_HEADERS结构
IMAGE_SECTION_HEADER STRUCT
Name1 db IMAGE_SIZEOF_SHORT_NAME dup(?) ；8个字节的节区名称
union Misc
PhysicalAddress dd ?
VirtualSize dd ? ；节区的尺寸
ends
VirtualAddress dd ? ；节区的RVA地址
SizeOfRawData dd ? ；在文件中对齐后的尺寸
PointerToRawData dd ? ；在文件中的偏移
PointerToRelocations dd ? ；在OBJ文件中使用
PointerToLinenumbers dd ? ；行号表的位置（供调试用）
NumberOfRelocations dw ? ；在OBJ文件中使用
NumberOfLinenumbers dw ? ；行号表中行号的数量
Characteristics dd ? ；节的属性
IMAGE_SECTION_HEADER ENDS
Name1字段
这个字段的字段名原来应该是“Name”，但是这个名称和MASM中的关键字冲突，所以在定义的时候改为“Name1”，Name1字段定义了节的名称，字段的长度为8个字节。
PE文件中的节的名称是一个由ANSI字符组成的字符串，但并没有规定以0结束，如果节的名称字符串长度小于8个字节的话，后面以0补齐，但是字符串长度达到8个字节的话，后面就没有0字符了，所以在处理的时候要注意字符串的结束方式。
每个节的名称是惟一的，不能有同名的两个节，但是节的名称不代表任何含义，它仅仅是为了查看方便而设置的一个标记而已，可以选择任何名称甚至将它空着也可以，将包含代码的节命名为“DATA”或者将包含数据的节命名为“CODE”都是合法的。
各种编译器都以自己的方式对节进行命名，所以，在PE文件中可以看到各式各样的节名称，比如，在MASM32产生的可执行文件中，代码节被命名为“.text”；可读写的数据节被命名为“.data”；包含只读数据、导入表以及导出表的节被命名为“.rdata”；而资源节被命名为“.rsrc”等。但是在其他一些编译器中，导入表被单独放在“.idata”中；而代码节可能被命名为“.code”。
当从PE文件中读取需要的节时，不能以节的名称作为定位标准，正确的方法是按照IMAGE_OPTIONAL_HEADER32结构中的数据目录字段定位。
VirtualSize字段
代表节的大小，这是节的数据在没有进行对齐处理前的实际大小。
VirtualAddress字段
指出节被装载到内存中后的偏移地址，这是一个RVA地址。这个地址是按照内存页对齐的，它的数值总是SectionAlignment的值的整数倍。
PointerToRawData字段
指出节在磁盘文件中的所处的位置。这个数值是从文件头开始算起的偏移量。
SizeOfRawData字段
指出节在磁盘文件中所占的空间大小，这个数值等于VirtualSize字段的值按照FileAlignment的值对齐以后的大小。
依靠这4个字段的值，装载器就可以从PE文件中找出某个节（从PointerToRawData偏移开始的SizeOfRawData字节）的数据，并将它映射到内存中去（映射到从模块基地址开始偏移VirtualAddress的地方，并占用以VirtualSize的值按照页的尺寸对齐后的空间大小）。
Characteristics字段
这是节的属性标志字段，其中的不同数据位代表了不同的属性，具体的定义如表17.5所示，这些数据位组合起来描述了节的属性。
结合上面的讲解，对照下面的图示，看就会很清楚，如图所示：
下面给大家讲几个学习区块的重要概念：
区块对齐值：
区块的大小是要对齐的，有两种对齐值，一种用于磁盘文件内，另一种用于内存文件中。PE文件头指出了这两个值，它们可以不同。
PE文件头里FileAlignment定义了磁盘区块的对齐值，每一个区块从对齐值的倍数的偏移位置开始。而区块的实际代码或数据的大小不一定刚好就是这么多，所以不足的地方一般以00h来填充，这就是区块间的间隙。
PE文件头里SectionAlignment定义了内存中区块的对齐值。PE文件被映射到内存中，区块总是至少从一个页边界开始，也就是说，当一个PE文件映射到内存中，每个区块的第一个字节对应于某个内存页。
内存页的属性：
对于磁盘映射文件来说，所有的页都是按照磁盘映射文件函数指定的属性设置的，但是装载可执行文件时，与节对应的内存页的属性要按照节的属性来设置。所以在同一属性模块的内存页中，从不同映射过来的内存页的属性是不同的。
节的偏移地址：
节的起始地址在磁盘文件中要按照IMAGE_OPTIONAL_HEADER32结构的FileAlignment字段的值对齐，而被装载到内存中时是按照同一结构中的SectionAlignment字段的值来对齐，两者的值可能不同，所以一个节被装入内存后相对于文件头的偏移和在磁盘文件中的偏移量可能是不同的。
节的尺寸：
对节的尺寸的处理有两个方面：首先是由于磁盘映像和内存映像中节对齐单位不同而造成的长度扩展；其次是对包含未初始化数据的节的处理。
对于未初始化数据来说，没必要为它们在磁盘文件中预留空间，只要在可执行文件被装载到内存中后为它们分配空间就可以了，所以包含未初始化数据的节在磁盘文件中的长度被定义为0，但是装载到内存中的地址和大小是被明确指定的。
不进行映射的节：
有些节中包含的数据仅仅在装载的时候用到，当文件装载完毕时候，它们不会被递交到物理内存页。
今天就讲到这里吧，也有点累了，写文章很累的，用了三个多小时，不过没事，只要能给大家一点帮助，付出的就是值得的，明天咱们继续学习输入表，输出表，基址重定位，资源，我打算在两天之类，把PE资源的理论介绍完毕，后面几天我重点讲解PE方面的编程知识，这样理论与实践相结合，学起来会更清楚明白一点！！
格式经较乱，大家将就的看吧~~~不好意思了