exe与dll几乎没什么区别，唯一区别就是一个字段标识出这个文件是exe还是dll
32位叫PE32，64位叫PE32+
PE主要定义在winnt.h
vc搜索：image format，定义PE结构
PE文件分32和64位之分：IMAGE_NT_HEADERS32或IMAGE_NT_HEADERS64
第二张图，百度搜索：PE文件格式示意图
GetModuleHandle（LPCTSTR lpModuleName）；获取模块句柄的地址
MS-DOS头部
IMAGE_DOS_HEADER STRUCT
{
+0h WORD e_magic // Magic DOS signature MZ(4Dh 5Ah) DOS可执行文件标记
+2h WORD e_cblp // Bytes on last page of file
+4h WORD e_cp // Pages in file
+6h WORD e_crlc // Relocations
+8h WORD e_cparhdr // Size of header in paragraphs
+0ah WORD e_minalloc // Minimun extra paragraphs needs
+0ch WORD e_maxalloc // Maximun extra paragraphs needs
+0eh WORD e_ss // intial(relative)SS value DOS代码的初始化堆栈SS
+10h WORD e_sp // intial SP value DOS代码的初始化堆栈指针SP
+12h WORD e_csum // Checksum
+14h WORD e_ip // intial IP value DOS代码的初始化指令入口[指针IP]
+16h WORD e_cs // intial(relative)CS value DOS代码的初始堆栈入口
+18h WORD e_lfarlc // File Address of relocation table
+1ah WORD e_ovno // Overlay number
+1ch WORD e_res[4] // Reserved words
+24h WORD e_oemid // OEM identifier(for e_oeminfo)
+26h WORD e_oeminfo // OEM information;e_oemid specific
+29h WORD e_res2[10] // Reserved words
+3ch DWORD e_lfanew // Offset to start of PE header 指向PE文件头
} IMAGE_DOS_HEADER ENDS
结构体第一个最后一个变量，偏移为100
PE头文件
IMAGE_NT_HEADERS STRUCT
{
+0h DWORD Signature //
+4h IMAGE_FILE_HEADER FileHeader //
+18h IMAGE_OPTIONAL_HEADER32 OptionalHeader //
} IMAGE_NT_HEADERS ENDS
Signature 字段：
在一个有效的 PE 文件里，Signature 字段被设置为00004550h, ASCII 码字符是“PE00”。标志这 PE 文件头的开始。
“PE00” 字符串是 PE 文件头的开始，DOS 头部的 e_lfanew 字段正是指向这里。
如下图所示：
IMAGE_FILE_HEADER 结构
typedef struct _IMAGE_FILE_HEADER { +04h WORD Machine; // 运行平台 +06h WORD NumberOfSections; // 文件的区块数目 +08h DWORD TimeDateStamp; // 文件创建日期和时间 +0Ch DWORD PointerToSymbolTable; // 指向符号表(主要用于调试) +10h DWORD NumberOfSymbols; // 符号表中符号个数(同上) +14h WORD SizeOfOptionalHeader; // IMAGE_OPTIONAL_HEADER32 结构大小 +16h WORD Characteristics; // 文件属性 } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
该结构如下图所示：
（1）Machine：可执行文件的目标CPU类型。
| Value | Meaning |
|---|---|
| IMAGE_FILE_MACHINE_I386 0x014c |
x86 |
| IMAGE_FILE_MACHINE_IA64 0x0200 |
Intel Itanium |
| IMAGE_FILE_MACHINE_AMD64 0x8664 |
x64 |
（2）NumberOfSection: 区块的数目。（注：区块表是紧跟在 IMAGE_NT_HEADERS 后边的）
（3）TimeDataStamp: 表明文件是何时被创建的。
这个值是自1970年1月1日以来用格林威治时间（GMT）计算的秒数，这个值是比文件系统（FILESYSTEM）的日期时间更加精确的指示器。如何将这个值翻译请看：http://home.fishc.com/space.php?uid=9&do=blog&id=555
提示：VC的话可以用_ctime 函数或者 gmtime 函数。
（4）PointerToSymbolTable: COFF 符号表的文件偏移位置，现在基本没用了。
（5）NumberOfSymbols: 如果有COFF 符号表，它代表其中的符号数目，COFF符号是一个大小固定的结构，如果想找到COFF 符号表的结束位置，则需要这个变量。
（6）SizeOfOptionalHeader: 紧跟着IMAGE_FILE_HEADER 后边的数据结构（IMAGE_OPTIONAL_HEADER）的大小。(对于32位PE文件，这个值通常是00E0h；对于64位PE32+文件，这个值是00F0h )。
（7）Characteristics: 文件属性，有选择的通过几个值可以运算得到。( 这些标志的有效值是定义于 winnt.h 内的 IMAGE_FILE_** 的值，具体含义见下表。普通的EXE文件这个字段的值一般是 0100h，DLL文件这个字段的值一般是 210Eh。)温馨提示：多种属性可以通过 “或运算” 使得同时拥有！
IMAGE_OPTIONAL_HEADER32
typedef struct _IMAGE_OPTIONAL_HEADER
{
//
// Standard fields.
//
+18h WORD Magic; // 标志字, ROM 映像（0107h）,普通可执行文件（010Bh）
+1Ah BYTE MajorLinkerVersion; // 链接程序的主版本号
+1Bh BYTE MinorLinkerVersion; // 链接程序的次版本号
+1Ch DWORD SizeOfCode; // 所有含代码的节的总大小
+20h DWORD SizeOfInitializedData; // 所有含已初始化数据的节的总大小
+24h DWORD SizeOfUninitializedData; // 所有含未初始化数据的节的大小
+28h DWORD AddressOfEntryPoint; // 程序执行入口RVA
+2Ch DWORD BaseOfCode; // 代码的区块的起始RVA
+30h DWORD BaseOfData; // 数据的区块的起始RVA
//
// NT additional fields. 以下是属于NT结构增加的领域。
//
+34h DWORD ImageBase; // 程序的首选装载地址
+38h DWORD SectionAlignment; // 内存中的区块的对齐大小
+3Ch DWORD FileAlignment; // 文件中的区块的对齐大小
+40h WORD MajorOperatingSystemVersion; // 要求操作系统最低版本号的主版本号
+42h WORD MinorOperatingSystemVersion; // 要求操作系统最低版本号的副版本号
+44h WORD MajorImageVersion; // 可运行于操作系统的主版本号
+46h WORD MinorImageVersion; // 可运行于操作系统的次版本号
+48h WORD MajorSubsystemVersion; // 要求最低子系统版本的主版本号
+4Ah WORD MinorSubsystemVersion; // 要求最低子系统版本的次版本号
+4Ch DWORD Win32VersionValue; // 莫须有字段，不被病毒利用的话一般为0
+50h DWORD SizeOfImage; // 映像装入内存后的总尺寸
+54h DWORD SizeOfHeaders; // 所有头 + 区块表的尺寸大小
+58h DWORD CheckSum; // 映像的校检和
+5Ch WORD Subsystem; // 可执行文件期望的子系统
+5Eh WORD DllCharacteristics; // DllMain()函数何时被调用，默认为 0
+60h DWORD SizeOfStackReserve; // 初始化时的栈大小
+64h DWORD SizeOfStackCommit; // 初始化时实际提交的栈大小
+68h DWORD SizeOfHeapReserve; // 初始化时保留的堆大小
+6Ch DWORD SizeOfHeapCommit; // 初始化时实际提交的堆大小
+70h DWORD LoaderFlags; // 与调试有关，默认为 0
+74h DWORD NumberOfRvaAndSizes; // 下边数据目录的项数，这个字段自Windows NT 发布以来， 一直是16
+78h IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
// 数据目录表 16个数组
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
● 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字段指定了节被装入内存后的对齐单位。也就是说，每个节被装入的地址必定是本字段指定数值的整数倍。（默认1000H）
FileAlignment字段指定了节存储在磁盘文件中时的对齐单位。（默认200H)
● Subsystem字段
指定使用界面的子系统，它的取值如表17.3所示。这个字段决定了系统如何为程序建立初始的界面，链接时的/subsystem:**选项指定的就是这个字段的值，在前面章节的编程中我们早已知道：如果将子系统指定为Windows CUI，那么系统会自动为程序建立一个控制台窗口，而指定为Windows GUI的话，窗口必须由程序自己建立。
界面子系统的取值和含义
| 取 值 |
Windows.inc中的预定义值 |
含 义 |
| 0 |
IMAGE_SUBSYSTEM_UNKNOWN |
未知的子系统 |
| 1 |
IMAGE_SUBSYSTEM_NATIVE |
不需要子系统（如驱动程序） |
| 2 |
IMAGE_SUBSYSTEM_WINDOWS_GUI |
Windows图形界面 |
| 3 |
IMAGE_SUBSYSTEM_WINDOWS_CUI |
Windows控制台界面 |
| 5 |
IMAGE_SUBSYSTEM_OS2_CUI |
OS2控制台界面 |
| 7 |
IMAGE_SUBSYSTEM_POSIX_CUI |
POSIX控制台界面 |
| 8 |
IMAGE_SUBSYSTEM_NATIVE_WINDOWS |
不需要子系统 |
| 9 |
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI |
Windows CE图形界面 |
● DataDirectory字段
这个字段可以说是最重要的字段之一，它由16个相同的IMAGE_DATA_DIRECTORY结构组成，虽然PE文件中的数据是按照装入内存后的页属性归类而被放在不同的节中的，但是这些处于各个节中的数据按照用途可以被分为导出表、导入表、资源、重定位表等数据块，这16个IMAGE_DATA_DIRECTORY结构就是用来定义多种不同用途的数据块的（如表17.4所示）。IMAGE_DATA_DIRECTORY结构的定义很简单，它仅仅指出了某种数据块的位置和长度。
IMAGE_DATA_DIRECTORY STRUCT
VirtualAddress DWORD ? ；数据的起始RVA
isize DWORD ? ；数据块的长度
IMAGE_DATA_DIRECTORY ENDS
数据目录列表的含义
| 索 引 |
索引值在Windows.inc中的预定义值 |
对应的数据块 |
| 0 |
IMAGE_DIRECTORY_ENTRY_EXPORT |
导出表 |
| 1 |
IMAGE_DIRECTORY_ENTRY_IMPORT |
导入表 |
| 2 |
IMAGE_DIRECTORY_ENTRY_RESOURCE |
资源 |
| 3 |
IMAGE_DIRECTORY_ENTRY_EXCEPTION |
异常（具体资料不详） |
| 4 |
IMAGE_DIRECTORY_ENTRY_SECURITY |
安全（具体资料不详） |
| 5 |
IMAGE_DIRECTORY_ENTRY_BASERELOC |
重定位表 |
| 6 |
IMAGE_DIRECTORY_ENTRY_DEBUG |
调试信息 |
| 7 |
IMAGE_DIRECTORY_ENTRY_ARCHITECTURE |
版权信息 |
| 8 |
IMAGE_DIRECTORY_ENTRY_GLOBALPTR |
具体资料不详 |
| 9 |
IMAGE_DIRECTORY_ENTRY_TLS |
Thread Local Storage |
| 10 |
IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG |
具体资料不详 |
| 11 |
IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT |
具体资料不详 |
| 12 |
IMAGE_DIRECTORY_ENTRY_IAT |
导入函数地址表 |
| 13 |
IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT |
具体资料不详 |
| 14 |
IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR |
具体资料不详 |
| 15 |
未使用 |
在PE文件中寻找特定的数据时就是从这些IMAGE_DATA_DIRECTORY结构开始的，比如要存取资源，那么必须从第3个IMAGE_DATA_DIRECTORY结构（索引为2）中得到资源数据块的大小和位置；同理，如果要查看PE文件导入了哪些DLL文件的哪些API函数，那就必须首先从第2个IMAGE_DATA_DIRECTORY结构得到导入表的位置和大小。
区块表（节表）和区块（节）
到此为止，和大家已经学了许多关于 DOS header 和 PE header 的知识。接下来就该轮到SectionTable (区块表，也成节表)。
PE文件到内存的映射
在执行一个PE文件的时候，windows 并不在一开始就将整个文件读入内存的，而是采用与内存映射文件类似的机制。也就是说，windows 装载器在装载的时候仅仅建立好虚拟地址和PE文件之间的映射关系。
当且仅当真正执行到某个内存页中的指令或者访问某一页中的数据时，这个页面才会被从磁盘提交到物理内存，这种机制使文件装入的速度和文件大小没有太大的关系。
但是要注意的是，系统装载可执行文件的方法又不完全等同于内存映射文件。
当使用内存映射文件的时候，系统对“原著”相当忠实，如果将磁盘文件和内存映像比较的话，可以发现不管是数据本身还是数据之间的相对位置它丫丫的都是完全相同的。
而我们知道，在装载可执行文件的时候，有些数据在装入前会被预处理，如重定位等，正因此，装入以后，数据之间的相对位置可能发生微妙的变化。
Windows 装载器在装载DOS部分、PE文件头部分和节表（区块表）部分是不进行任何特殊处理的，而在装载节（区块）的时候则会自动按节（区块）的属性做不同的处理。
一般情况下，它会处理以下几个方面的内容：
- 内存页的属性；
- 节的偏移地址；
- 节的尺寸；
- 不进行映射的节。
内存页的属性：
对于磁盘映射文件来说，所有的页都是按照磁盘映射文件函数指定的属性设置的。但是在装载可执行文件时，与节对应的内存页属性要按照节的属性来设置。所以，在同属于一个模块的内存页中，从不同节映射过来的的内存页的属性是不同的。
节的偏移地址：
节的起始地址在磁盘文件中是按照 IMAGE_OPTIONAL_HEADER32 结构的 FileAlignment 字段的值进行对齐的，而当被加载到内存中时是按照同一结构中的 SectionAlignment 字段的值对其的，两者的值可能不同，所以一个节被装入内存后相对于文件头的偏移和在磁盘文件中的偏移可能是不同的。
注意，节事实上就是相同属性数据的组合！当节被装入到内存中的时候，相同一个节所对应的内存页都将被赋予相同的页属性， 事实上，Windows 系统对内存属性的设置是以页为单位进行的，所以节在内存中的对齐单位必须至少是一个页的大小。（温馨提示：对于32位操作系统来说，这个值一般是4KB==1000H; 对于64位操作系统这个值一般是8KB==2000H）
在磁盘中就没有这个**，因为在磁盘中排放是以什么为主？肯定是以空间为主导，在磁盘只是存放，不是使用，所以不用设置那么详细的属性。试想想看，如果在磁盘中都是以4KB为大小对齐的话，不够就用0来填充，那么一个只占20字节的数据就要消耗4KB的空间来存放，是不是浪费？有木有？？
节的尺寸：
对节的尺寸的处理主要分为两个方面：
第一个方面，正如刚刚我们所讲的，由于磁盘映像和内存映像中节对齐存储单位的不同而导致了长度扩展不同（填充的0数量不同嘛~）；
第二个方面，是对于包含未初始化数据的节的处理问题。既然是未初始化，那么没有必要为其在磁盘中浪费空间资源，但在内存中不同，因为程序一运行，之前未初始化的数据便有可能要被赋值初始化，那么就必须为他们留下空间。
不进行映射的节：
有些节并不需要被映射到内存中，例如.reloc节，重定位数据对于文件的执行代码来说是透明的，无作用的，它只是提供Windows 装载器使用，执行代码根本不会去访问到它们，所以没有必要将他们映射到物理内存中。
节表（区块表）：
PE文件中所有节的属性都被定义在节表中，节表由一系列的IMAGE_SECTION_HEADER结构排列而成，每个结构用来描述一个节，结构的排列顺序和它们描述的节在文件中的排列顺序是一致的。全部有效结构的最后以一个空的IMAGE_SECTION_HEADER结构作为结束，所以节表中总的IMAGE_SECTION_HEADER结构数量等于节的数量加一。节表总是被存放在紧接在PE文件头的地方。
另外，节表中 IMAGE_SECTION_HEADER 结构的总数总是由PE文件头 IMAGE_NT_HEADERS 结构中的 FileHeader.NumberOfSections 字段来指定的。
typedef struct _IMAGE_SECTION_HEADER
{
BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 节表名称,如“.text”
//IMAGE_SIZEOF_SHORT_NAME=8
union
{DWORD PhysicalAddress; // 物理地址
DWORD VirtualSize; // 真实长度，这两个值是一个联合结构，可以使用其中的任何一个，一
// 般是取后一个
} Misc;
DWORD VirtualAddress; // 节区的 RVA 地址
DWORD SizeOfRawData; // 在文件中对齐后的尺寸
DWORD PointerToRawData; // 在文件中的偏移量
DWORD PointerToRelocations; // 在OBJ文件中使用，重定位的偏移
DWORD PointerToLinenumbers; // 行号表的偏移（供调试使用地）
WORD NumberOfRelocations; // 在OBJ文件中使用，重定位项数目
WORD NumberOfLinenumbers; // 行号表中行号的数目
DWORD Characteristics; // 节属性如可读，可写，可执行等
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Name：区块名。这是一个由8位的ASCII 码名，用来定义区块的名称。多数区块名都习惯性以一个“.”作为开头（例如：.text），这个“.” 实际上是不是必须的。值得我们注意的是，如果区块名超过 8 个字节，则没有最后的终止标志“NULL” 字节。并且前边带有一个“$” 的区块名字会从连接器那里得到特殊的待遇，前边带有“$” 的相同名字的区块在载入时候将会被合并，在合并之后的区块中，他们是按照“$” 后边的字符的字母顺序进行合并的。
另外童鞋要跟大家啰嗦一下的是：每个区块的名称都是唯一的，不能有同名的两个区块。但事实上节的名称不代表任何含义，他的存在仅仅是为了正规统一编程的时候方便程序员查看方便而设置的一个标记而已。所以将包含代码的区块命名为“.Data” 或者说将包含数据的区块命名为“.Code” 都是合法的。
因此，建议大家：当我们要从PE 文件中读取需要的区块时候，不能以区块的名称作为定位的标准和依据，正确的方法是按照 IMAGE_OPTIONAL_HEADER32 结构中的数据目录字段结合进行定位。
Virtual Size：该表对应的区块的大小，这是区块的数据在没有进行对齐处理前的实际大小。
Virtual Address：该区块装载到内存中的RVA 地址。这个地址是按照内存页来对齐的，因此它的数值总是 SectionAlignment 的值的整数倍。在Microsoft 工具中，第一个快的默认 RVA 总为1000h。在OBJ 中，该字段没有意义地，并被设为0。
SizeOfRawData：该区块在磁盘中所占的大小。在可执行文件中，该字段是已经被FileAlignment 潜规则处理过的长度。
PointerToRawData：该区块在磁盘中的偏移。这个数值是从文件头开始算起的偏移量哦。
PointerToRelocations：这哥们在EXE文件中没有意义，在OBJ 文件中，表示本区块重定位信息的偏移值。（在OBJ 文件中如果不是零，它会指向一个IMAGE_RELOCATION 结构的数组）
PointerToLinenumbers：行号表在文件中的偏移值，文件的调试信息，于我们没用，鸡肋。
NumberOfRelocations：这哥们在EXE文件中也没有意义，在OBJ 文件中，是本区块在重定位表中的重定位数目来着。
NumberOfLinenumbers：该区块在行号表中的行号数目，鸡肋。
Characteristics：该区块的属性。该字段是按位来指出区块的属性（如代码/数据/可读/可写等）的标志。
举出最常用的一些属性值：
具体内容可以参考MSDN在线文档：http://msdn.microsoft.com/en-us/library/ms680341%28v=vs.85%29.aspx
| IMAGE_SCN_CNT_CODE 0x00000020 |
The section contains executable code. 包含代码，常与 0x10000000一起设置。 |
| IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 |
The section contains initialized data. 该区块包含以初始化的数据。 |
| IMAGE_SCN_CNT_UNINITIALIZED_DATA 0x00000080 |
The section contains uninitialized data. 该区块包含未初始化的数据。 |
| IMAGE_SCN_MEM_DISCARDABLE 0x02000000 |
The section can be discarded as needed. 该区块可被丢弃，因为当它一旦被装入后， 进程就不在需要它了，典型的如重定位区块。 |
| IMAGE_SCN_MEM_SHARED 0x10000000 |
The section can be shared in memory. 该区块为共享区块。 |
| IMAGE_SCN_MEM_EXECUTE 0x20000000 |
The section can be executed as code. 该区块可以执行。通常当0x00000020被设置 时候，该标志也被设置。 |
| IMAGE_SCN_MEM_READ 0x40000000 |
The section can be read. 该区块可读，可执行文件中的区块总是设置该 标志。 |
| IMAGE_SCN_MEM_WRITE 0x80000000 |
The section can be written to. 该区块可写。 |
通常，区块中的数据在逻辑上是关联的。PE 文件一般至少都会有两个区块：一个是代码块，另一个是数据块。每一个区块都需要有一个截然不同的名字，这个名字主要是用来表达区块的用途。例如有一个区块叫.rdata，表明他是一个只读区块。注意：区块在映像中是按起始地址（RVA）来排列的，而不是按字母表顺序。
另外，使用区块名字只是人们为了认识和编程的方便，而对操作系统来说这些是无关紧要的。微软给这些区块取了个有特色的名字，但这不是必须的。当编程从PE 文件中读取需要的内容时，如输入表、输出表，不能以区块名字作为参考，正确的方法是按照数据目录表中的字段来进行定位。
下表中的区块名称以及意义：
当然我们在Visual C++ 中也可以自己命名我们的区块，用#pragma 来声明，告诉编译器插入数据到一个区块内，格式如下：
#pragma data_msg( "FC_data" )
以上语句告诉编译器将数据都放进一个叫“FC_data” 的区块内，而不是默认的.data 区块。区块一般是从OBJ 文件开始，被编译器放置的。链接器的工作就是合并左右OBJ 和库中需要的块，使其成为一个最终合适的区块。链接器会遵循一套相当完整的规则，它会判断哪些区块将被合并以及如何被合并。
合并区块：
链接器的一个有趣特征就是能够合并区块。如果两个区块有相似、一致性的属性，那么它们在链接的时候能被合并成一个单一的区块。这取决于是否开启编译器的 /merge 开关。事实上合并区块有一个好处就是可以节省磁盘的内存空间……注意：我们不应该将.rsrc、.reloc、.pdata 合并到**的区块里。
区块的对齐值：
之前我们简单了解过区块是要对齐的，无论是在内存中存放还是在磁盘中存放~但他们一般的对齐值是不同的。
PE 文件头里边的FileAligment 定义了磁盘区块的对齐值。每一个区块从对齐值的倍数的偏移位置开始存放。而区块的实际代码或数据的大小不一定刚好是这么多，所以在多余的地方一般以00h 来填充，这就是区块间的间隙。
例如，在PE文件中，一个典型的对齐值是200h ，这样，每个区块都将从200h 的倍数的文件偏移位置开始，假设第一个区块在400h 处，长度为90h，那么从文件400h 到490h 为这一区块的内容，而由于文件的对齐值是200h，所以为了使这一区块的长度为FileAlignment 的整数倍，490h 到 600h 这一个区间都会被00h 填充，这段空间称为区块间隙，下一个区块的开始地址为600h 。
PE 文件头里边的SectionAligment 定义了内存中区块的对齐值。PE 文件被映射到内存中时，区块总是至少从一个页边界开始。
一般在X86 系列的CPU 中，页是按4KB（1000h）来排列的；在IA-64 上，是按8KB（2000h）来排列的。所以在X86 系统中，PE文件区块的内存对齐值一般等于 1000h，每个区块按1000h 的倍数在内存中存放。
RVA 和文件偏移的转换
在前边我们探讨过RVA 这个词，但对于初次接触PE 文件的朋友来说，显得尤其陌生和无奈。中国人不喜欢老外的缩写，但总要**着接受……不过，在有了前边知识的铺垫之后，现在来谈这个概念大家伙应该能够得心应手了。起码不用显得那么的费解和无奈~
RVA 是相对虚拟地址（Relative Virtual Address）的缩写，顾名思义，它是一个“相对地址”。PE 文件中的各种数据结构中涉及地址的字段大部分都是以 RVA 表示的，有木有？？
更为准确的说，RVA 是当PE 文件被装载到内存中后，某个数据位置相对于文件头的偏移量。举个例子，如果 Windows 装载器将一个PE 文件装入到 00400000h 处的内存中，而某个区块中的某个数据被装入 0040**xh 处，那么这个数据的 RVA 就是（0040**xh - 00400000h ）= **xh，反过来说，将 RVA 的值加上文件被装载的基地址，就可以找到数据在内存中的实际地址。
很明显，我们发现，DOS 文件头、PE 文件头和区块表的偏移位置与大小均没有变化。而各个区块映射到内存后，其偏移位置就发生了变化。
如何换算 RVA 和文件偏移呢？
当处理PE 文件时候，任何的 RVA 必须经过到文件偏移的换算，才能用来定位并访问文件中的数据，但换算却无法用一个简单的公式来完成，事实上，唯一可用的方法就是最土最笨的方法：
步骤一：循环扫描区块表得出每个区块在内存中的起始 RVA（根据IMAGE_SECTION_HEADER 中的VirtualAddress 字段），并根据区块的大小（根据IMAGE_SECTION_HEADER 中的SizeOfRawData 字段）算出区块的结束 RVA（两者相加即可），最后判断目标 RVA 是否落在该区块内。
步骤二：通过步骤一定位了目标 RVA 处于具体的某个区块中后，那么用目标 RVA 减去该区块的起始 RVA ，这样就能得到目标 RVA 相对于起始地址的偏移量 RVA2.
步骤三：在区块表中获取该区块在文件中所处的偏移地址（根据IMAGE_SECTION_HEADER 中的PointerToRawData 字段）, 将这个偏移值加上步骤二得到的 RVA2 值，就得到了真正的文件偏移地址。