《PE总结 》– 重定位表

Posted 2020-12-23 chary

一、什么是重定位？

重定位就是你本来这个程序理论上要占据这个地址，但是由于某种原因，这个地址现在不能让你霸占，你必须转移到别的地址，这就需要基址重定位。

 

二、为什么需要重定位？

这个和上面的问题的解释是一样的。不是说过每个进程都有自己独立的虚拟地址空间吗？既然都是自己的，怎么会被占据呢？对于EXE应用程序来说，是这样的。但是动态链接库就不一样了，我们说过动态链接库都是寄居在别的应用程序的空间的，所以出现要载入的基地址被应用程序占据了也是很正常的，这时它就不得不进行重定位了。

 

三、重定位表的结构

1.重定位所需的数据

在开始分析重定位表的结构之前需要了解两个问题：第一，对一条指令进行重定位需要哪些信息？第二，这些信息中哪些应该被保存在重定位表中？

下面举例来说明这两个问题，请看下面的这段代码：
:00400FFC 0000 ；dwVar变量
:00401000 55    push ebp
:00401001 8BEC    mov ebp, esp
:0040100383C4FC    add esp, FFFFFFFC
:00401006 A1FC0F4000   mov eax, dword ptr [00400FFC] ；mov eax,dwVar
:0040100B 8B45FC    mov eax, dword ptr [ebp-04] ；mov eax,@dwLocal
:0040100E 8B4508    mov eax, dword ptr [ebp+08] ；mov eax,_dwParam
:00401011 C9    leave
:00401012 C20400    ret 0004
:00401015 68D2040000   push 000004D2
:0040101A E8E1FFFFFF   call 00401000 ；invoke Proc1,1234

其中地址为00401006h处的mov eax,dword ptr [00400ffc]就是一句需要重定位的指令，当整个程序的起始地址位于00400000h处的时候，这句代码是正确的，假如将它移到00500000h处的时候，这句指令必须变成mov eax,dword ptr [00500ffc]才是正确的。这就意味着它需要重定位。

让我们看看需要改变的是什么，重定位前的指令机器码是A1 FC0F 40 00，而重定位后将是A1 FC0F 50 00，也就是说00401007h开始的双字00400ffch变成了00500ffch，改变的正是起始地址的差值（00500000h－00400000h）＝00100000h。

所以，重定位的算法可以描述为：将直接寻址指令中的双字地址加上模块实际装入地址与模块建议装入地址之差。为了进行这个运算，需要有3个数据，

首先是需要修正的机器码地址；

其次是模块的建议装入地址；

最后是模块的实际装入地址。这就是第一个问题的答案。

在这3个数据中，模块的建议装入地址已经在PE文件头中定义了，而模块的实际装入地址是Windows装载器确定的，到装载文件的时候自然会知道，所以第二个问题的答案很简单，那就是应该被保存在重定位表中的仅仅是需要修正的代码的地址。

事实上正是如此，PE文件的重定位表中保存的就是一大堆需要修正的代码的地址。

2.重定位表的位置

重定位表一般会被单独存放在一个可丢弃的以“.reloc”命名的节中，但是和资源一样，这并不是必然的，因为重定位表放在其他节中也是合法的，惟一可以肯定的是，如果重定位表存在的话，它的地址肯定可以在PE文件头中的数据目录中找到。

3.重定位表的结构

虽然重定位表中的有用数据是那些需要重定位机器码的地址指针，但为了节省空间，PE文件对存放的方式做了一些优化。

在正常的情况下，每个32位的指针占用4个字节，如果有n个重定位项，那么重定位表的总大小是4×n字节大小。

直接寻址指令在程序中还是比较多的，在比较靠近的重定位表项中，32位指针的高位地址总是相同的，如果把这些相近表项的高位地址统一表示，那么就可以省略一部分的空间，当按照一个内存页来分割时，在一个页面中寻址需要的指针位数是12位（一页等于4096字节，等于2的12次方），假如将这12位凑齐16位放入一个字类型的数据中，并用一个附加的双字来表示页的起始指针，另一个双字来表示本页中重定位项数的话，那么占用的总空间会是4＋4＋2×n字节大小，计算一下就可以发现，当某个内存页中的重定位项多于4项的时候，后一种方法的占用空间就会比前面的方法要小。
PE文件中重定位表的组织方法就是采用类似的按页分割的方法，从PE文件头的数据目录中得到重定位表的地址后，这个地址指向的就是顺序排列在一起的很多重定位块，每一块用来描述一个内存页中的所有重定位项。

每个重定位块以一个IMAGE_BASE_RELOCATION结构开头，后面跟着在本页面中使用的所有重定位项，每个重定位项占用16位的地址（也就是一个word），结构的定义是这样的：
IMAGE_BASE_RELOCATION STRUCT
VirtualAddress dd ? ；重定位内存页的起始RVA
SizeOfBlock dd ? ；重定位块的长度
IMAGE_BASE_RELOCATION ENDS
VirtualAddress字段是当前页面起始地址的RVA值，本块中所有重定位项中的12位地址加上这个起始地址后就得到了真正的RVA值。SizeOfBlock字段定义的是当前重定位块的大小，从这个字段的值可以算出块中重定位项的数量，由于SizeOfBlock＝4＋4＋2×n，也就是sizeof IMAGE_BASE_RELOCATION＋2×n，所以重定位项的数量n就等于(SizeOfBlock－sizeof IMAGE_BASE_RELOCATION)÷2。
IMAGE_BASE_RELOCATION结构后面跟着的n个字就是重定位项，每个重定位项的16位数据位中的低12位就是需要重定位的数据在页面中的地址，剩下的高4位也没有被浪费，它们被用来描述当前重定位项的种类。虽然高4位定义了多种重定位项的属性，但实际上在PE文件中只能看到0和3这两种情况。

 

所有的重定位块最终以一个VirtualAddress字段为0的IMAGE_BASE_RELOCATION结构作为结束，读者现在一定明白了为什么可执行文件的代码总是从装入地址的1000h处开始定义的了（比如装入00400000h处的.exe文件的代码总是从00401000h开始，而装入10000000h处的.dll文件的代码总是从10001000h处开始），要是代码从装入地址处开始定义，那么第一页代码的重定位块的VirtualAddress字段就会是0，这就和重定位块的结束方式冲突了。

四、实例分析

我们来分析一个实例，简单分析一个DLL的重定位表，先反汇编：

 

根据上面的理论讲解，我们需要重定位的有两处：00402000和00403030

下面我们就来实例分析一下，是不是？首先找到重定位表的指针：

 

如果还不知道重定位表的RVA是怎么找的，前参照我前面加的内容。

从图中可以看出数据目录表指向重定位表的指针是5000h，换算成文件偏移地址就是0E00h，（也不要问我怎么来的，我前面已经说明三个步骤）我们在定位到File Offset为0E00处，可以得到IMAGE_BASE_RELOCATION结构如下图所示：

 

从图中可以看出:
VirtualAddress：00001000h
SizeOfBlock：00000010h（有四个重定位数据，(10h-8h)/2h=4h)
重定位数据1:300Fh
重定位数据2:3023h
重定位数据3:0000h（用于对齐）
重定位数据4:0000h（用于对齐)
重定位数据计算过程如下表所示：

 

 

 

 用十六进制工具查看实例文件，其中060Fh和623h分别指向402000h和403030h，如下图所示：

 

 

 

 和我们上面假设的完全一样！

执行PE文件前，加载程序在进行重定位的时候，会将PE文件在内存中的实际映像地址减去PE文件所要求的映像地址，得到一个差值，再将这一差值根据重定位类型的不同添加到地址数组中。

《PE总结 》– 资源表

一、资源简介

资源是PE文件中非常重要的部分，几乎所有的PE文件中都包含资源，与导入表和导出表相比，资源的组织方式要复杂的多。

我们知道，Windows 将程序的各种界面定义为资源，包括加速键（Accelerator）、位图（Bitmap）、光标（Cursor）、对话框（Dialog Box）、图标（Icon）、菜单（Menu）、串表（String Table）、工具栏（Toolbar）和版本信息（Version Information）等。除此之外，还可以使用自定义的类型。每种类型的资源中可能存在多个资源项，这些资源项用不同的ID或者名称来分辨，在某个资源ID下，还可以同时存在不同代码页的版本。但是要将这么多种类型的不同ID 的资源有序地组织起来是一件非常痛苦的事情，因此，我们采取类似于磁盘目录结构的方式保存。

我们来看看PE中资源的组织方式：

 

建立如上的结构后，如果我们要查找某个资源的话，那么按照根目录->资源目录->资源ID->资源代码页这样的步骤一层层地进入相应的子目录并找到正确的资源。不过第三层目录防止的代码页“文件”不是资源本身而是一个用来描述资源的结构罢了，通过这个结构中的指针才能最后找到资源数据。

二、资源的组织方式

1.获取资源的位置

资源数据块的位置和大小可以从PE文件头中的IMAGE_OPTIONAL_HEADER32结构的数据目录字段中获取。在获取资源块的时候，注意不要使用查找“.rsrc”节起始地址的方法，虽然在一般情况下总是在“.rsrc”节中，但这并不是必然的。

2.资源目录

不管是根目录，还是第2层或第3层中的每个目录都是由一个IMAGE_RESOUCE_DIRECTORY结构和紧跟其后的数个IMAGE_RESOUCE_DIRECTORY_ENTRY结构组成的，这两种结构一起组成一个目录块。

IMAGE_RESOUCE_DIRECTORY的结构如下：

IMAGE_RESOURCE_DIRECTORY STRUCT

Characteristics DWORD ? ;理论上为资源的属性，不过事实上总是0
TimeDateStamp DWORD ? ;资源的产生时刻
MajorVersion WORD ? ;理论上为资源的版本，不过事实上总是0
MinorVersion WORD ?
NumberOfNamedEntries WORD ? ;以名称（字符串）命名的入口数量
NumberOfIdEntries WORD ? ;以ID（整型数字）命名的入口数量

IMAGE_RESOURCE_DIRECTORY ENDS

在这个结构中最重要的是最后两个字段，它们说明了本目录中目录项的数量，为什么有两个字段？

因为不管是资源种类，还是资源名称都可以用名称或ID两种方式来定义。

NameberOfNamedEntries字段的值是以字符串命名的资源数量，而NumberOfIdEntries 字段的值是以ID命名的资源数量。两个加起来才是本目录中的目录项总和，也就是当前IMAGE_RESOURCE_DIRECTORY结构后面紧跟着的IMAGE_RESOUCE_DIRECTORY_ENTRY结构的数量。

IMAGE_RESOURCE_DIRECTORY_ENTRY STRUCT

Name1 DWORD ? ;目录项的名称字符串指针或ID
OffsetToData DWORD ? ;目录项指针

IMAGE_RESOURCE_DIRECTORY_ENTRY ENDS

①Name1 字段完全是个百变精灵，该字段定义的是目录项的名称或ID。

当结构用于第一层目录时，定义的是资源类型；

当结构定义于第二层目录时，定义的是资源的名称；

当结构用于第三层目录时，定义的是代码页编号。

当最高位为 0 的时候，表示字段的值作为 ID 使用；而最高位为 1 的时候，字段的低位作为指针使用（资源名称字符串是使用 UNICODE编码），但是这个指针不是直接指向字符串哦，而是指向一个 IMAGE_RESOURCE_DIR_STRING_U 结构的。

IMAGE_RESOURCE_DIR_STRING_U STRUCT

Length DWORD ? ; 字符串的长度
NameString DWORD ? ; UNICODE字符串，由于字符串是不定长的。由Length 制定长度

IMAGE_RESOURCE_DIR_STRING_U ENDS

如果长度为100的时候，数据定义为：NameString  dw  100  dup(?)

如果想要得到ANSI类型的以0结尾的字符串，需要将NameString字段包含的UNICODE字符串用WideCharToMultiByte函数作个转换。

②OffsetOfData 字段是一个指针。

当最高位为 1 时，低位数据指向下一层目录块的起始地址；也就是一个IMAGE_RESOURCE_DIRECTORY，这种情况一般出现在第1层和第2层中。

当最高位为 0 时，指针指向 IMAGE_RESOURCE_DATA_ENTRY 结构，这种情况出现在第3层目录中。

当将Name1字段和OffsetToData用作指针时需要注意两点，首先是不要忘记将最高位清楚(使用0x7fffffff来and一下)，其次就是这两个指针时从资源块开始的地方算起的偏移量，也就是根目录的起始位置算起的偏移量。不是RVA！！！

当IMAGE_RESOUCE_DIRECTORY_ENTRY用在第1层目录中的时候，它的Name1字段是作为资源类型来使用的。当资源类型以ID定义(最高位应等于0)，并且ID数值在1-16之间时，表示这是系统预定义的类型，否则，表示这是一个自定义的类型。

 

 

 3.资源数据入口

沿着资源目录树按照根目录->资源类型->资源ID的顺序到达第3层后，这一层目录的IMAGE_RESOUCE_DIRECTORY_ENTRY结构的OffsetData字段指向的是一个IMAGE_RESOURCE_DATA_ENTRY 结构。该结构描述了资源数据的位置和大小，定义如下：
IMAGE_RESOURCE_DATA_ENTRY STRUCT

OffsetToData DWORD ? ; 资源数据的RVA
Size1 DWORD ? ; 资源数据的长度
CodePage DWORD ? ; 代码页, 一般为0
Reserved DWORD ? ; 保留字段

IMAGE_RESOURCE_DATA_ENTRY ENDS

千山万水，此处的 IMAGE_RESOURCE_DATA_ENTRY 结构就是真正的资源数据了。结构中的OffsetOfData 指向资源数据的指针，其为 RVA 值。

《PE总结 》– 导出表

当PE文件被执行的时候，Windows装载器将文件装入内存并将导入表中登记的DLL文件一并装入，再根据DLL文件中的函数导出信息对被执行文件的IAT表进行修正。

Windows 在加载一个程序后就在内存中为该程序开辟一个单独的虚拟地址空间，这样的话在各个程序自己看来，自己就拥有几乎任意地址的支配权，所以他自身的函数想放在哪个地址自己说了算。有一些函数很多程序都会用到，为每一个程序写一个相同的函数看起来似乎有点浪费空间，因此Windows就整出了动态链接库的概念，将一些常用的函数封装成动态链接库，等到需要的时候通过直接加载动态链接库，将需要的函数整合到自身中，这样就大大的节约了内存中资源的存放。

动态链接库是被映射到其他应用程序的地址空间中执行的，它和应用程序可以看成是“一体”的，动态链接库可以使用应用程序的资源，它所拥有的资源也可以被应用程序使用，它的任何操作都是代表应用程序进行的，当动态链接库进行打开文件、分配内存和创建窗口等操作后，这些文件、内存和窗口都是为应用程序所拥有的。

导出表就是记载着动态链接库的一些导出信息。通过导出表，DLL 文件可以向系统提供导出函数的名称、序号和入口地址等信息，比便Windows 加载器通过这些信息来完成动态连接的整个过程。

扩展名为.exe 的PE 文件中一般不存在导出表，而大部分的.dll 文件中都包含导出表。但注意，这并不是绝对的。例如纯粹用作资源的.dll 文件就不需要导出函数啦，另外有些特殊功能的.exe 文件也会存在导出函数。

一、导出表的结构

1.获取导出表的位置

导出表的位置和大小可以从PE文件中IMAGE_OPTIONAL_HEADER32结构的数据目录字段中获取。从IMAGE_OPTIONAL_DIRECTORY结构的VirtualAddress字段得到的是导入表的RVA值，如果在内存中查找导入表，那么将RVA值加上PE文件装入的基址就是实际的地址，如果在PE文件中查找导入表，那么需要使用前面讲的将RVA转换成文件偏移的方法进行转换。           

2.导出表的组成

导出表中为每个导出函数定义了导出序号，但函数名的定义是可选的。对于定义了函数名的函数来说，既可以使用名称导出，也可以使用序号导出：对于没有定义函数名的函数来说，只能使用序号来导出。

导出表的起始位置有一个IMAGE_EXPORT_DIRECTORY结构，与导入表中有多个IMAGE_IMPORT_DESCRIPTOR结构不同，导出表中只有一个IMAGE_EXPORT_DIRECTORY结构，定义如下：

IMAGE_EXPORT_DIRECTORY STRUCT
Characteristics DWORD ? ; 未使用，总是定义为0
TimeDateStamp DWORD ?       ; 文件生成时间
MajorVersion WORD ? ; 未使用，总是定义为0
MinorVersion WORD ? ; 未使用，总是定义为0
Name      DWORD ? ; 模块的真实名称RVA
Base        DWORD ? ; 基数，加上序数就是函数地址数组的索引值
NumberOfFunctions DWORD ? ; 导出函数的总数
NumberOfNames DWORD ? ; 以名称方式导出的函数的总数
AddressOfFunctions DWORD ? ; 指向输出函数地址的RVA
AddressOfNames DWORD ? ; 指向输出函数名字的RVA
AddressOfNameOrdinals DWORD ? ; 指向输出函数序号的RVA

IMAGE_EXPORT_DIRECTORY ENDS

这个结构中的一些字段并没有被使用，有意义的字段说明如：

①Name

一个RVA 值，指向一个定义了模块名称的字符串。如即使Kernel32.dll 文件被改名为”Ker.dll”，仍然可以从这个字符串中的值得知其在编译时的文件名是”Kernel32.dll”。

②NumberOfFunctions

文件中包含的导出函数的总数。

③NumberOfNames

被定义函数名称的导出函数的总数，显然只有这个数量的函数既可以用函数名方式导出。也可以用序号方式导出，剩下的NumberOfFunctions 减去NumberOfNames 数量的函数只能用序号方式导出。该字段的值只会小于或者等于 NumberOfFunctions 字段的值，如果这个值是0，表示所有的函数都是以序号方式导出的。

④AddressOfFunctions

一个RVA 值，指向包含全部导出函数入口地址的双字数组。数组中的每一项是一个RVA 值，数组的项数等于NumberOfFunctions 字段的值。

⑤Base

导出函数序号的起始值，将AddressOfFunctions 字段指向的入口地址表的索引号加上这个起始值就是对应函数的导出序号。假如Base 字段的值为x，那么入口地址表指定的第1个导出函数的序号就是x；第2个导出函数的序号就是x＋1。总之，一个导出函数的导出序号等于Base 字段的值加上其在入口地址表中的位置索引值。

⑥AddressOfNames 和 AddressOfNameOrdinals

均为RVA 值。前者指向函数名字符串地址表。这个地址表是一个双字数组，数组中的每一项指向一个函数名称字符串的RVA。数组的项数等NumberOfNames 字段的值，所有有名称的导出函数的名称字符串都定义在这个表中；后者指向另一个word 类型的数组（注意不是双字数组）。数组项目与文件名地址表中的项目一一对应，项目值代表函数入口地址表的索引，这样函 数名称与函数入口地址关联起来。

举个例子，加入函数名称字符串地址表的第n 项指向一个字符串“MyFunction”，那么可以去查找 AddressOfNameOrdinals 指向的数组的第n 项，假如第n 项中存放的值是x，则表示AddressOfFunctions 字段描述的地址表中的第x 项函数入口地址(aaaa)对应的名称就是“MyFunction”，这时这个函数的全部信息就可以如下描述。

函数名称：MyFunction    导出序号：Base的值+x    入口地址：aaaa

可以看到，AddressOfNameOrdinals字段描述的数组仅仅起了一个桥梁的作用。

 

 3.从序号查找入口地址

已知函数的导出序号，如何得到入口地址呢？

①定位到PE 文件头。

②从PE 文件头中的 IMAGE_OPTIONAL_HEADER32 结构中取出数据目录表，并从第一个数据目录中得到导出表的RVA。

③从导出表的 Base 字段得到起始序号。

④将需要查找的导出序号减去起始序号，得到函数在入口地址表中的索引。

⑤检测索引值是否大于导出表的 NumberOfFunctions 字段的值，如果大于后者的话，说明输入的序号是无效的。

⑥用这个索引值在 AddressOfFunctions 字段指向的导出函数入口地址表中取出相应的项目，这就是函数入口地址的RVA 值，当函数被装入内存的时候，这个RVA 值加上模块实际装入的基地址，就得到了函数真正的入口地址。

4.从函数名称查找入口地址

已知导出函数的名称，如何得到入口地址呢？

①最初的步骤是一样的，那就是首先得到导出表的地址。

②从导出表的NumberOfNames 字段得到已命名函数的总数，并以这个数字作为循环的次数来构造一个循环。

③从AddressOfNames 字段指向得到的函数名称地址表的第一项开始，在循环中将每一项定义的函数名与要查找的函数名相比较，如果没有任何一个函数名是符合的，表示文件中没有指定名称的函数。

④如果某一项定义的函数名与要查找的函数名符合，那么记下这个函数名在字符串地址表中的索引值，然后在AddressOfNamesOrdinals 指向的数组中以同样的索引值取出数组项的值，我们这里假设这个值是x。

⑤最后，以 x 值作为索引值，在 AddressOfFunctions 字段指向的函数入口地址表中获取的 RVA 就是函数的入口地址。

一般情况下病毒程序就是通过函数名称查找入口地址的，因为病毒程序作为一段额外的代码被附加到可执行文件中的，如果病毒代码中用到某些 API 的话，这些 API 的地址不可能在宿主文件的导出表中为病毒代码准备好。因此只能通过在内存中动态查找的方法来实现获取API 的地址。

《PE总结 》– 导入表

一、导入表简介

在编程中常常用到“导入函数”(Import functions),导入函数就是被程序调用但其执行代码又不在程序中的函数，这些函数的代码位于一个或者多个DLL中，在调用者程序中只保留一些函数信息，包括函数名及其驻留的DLL名等。

于磁盘上的PE 文件来说，它无法得知这些输入函数在内存中的地址，只有当PE 文件被装入内存后，Windows 加载器才将相关DLL 装入，并将调用输入函数的指令和函数实际所处的地址联系起来。这就是“动态链接”的概念。动态链接是通过PE 文件中定义的“导入表”来完成的，导入表中保存的正是函数名和其驻留的DLL 名等。

1.调用导入函数的指令

程序被执行的时候是怎样使用导入函数的呢？我们来对一个简单的弹出一个MessageBox的程序反汇编一把，看看调用导入函数的指令都是什么样子的.

 

 

 灰常简单的一个小程序，如图双击程序只显示一个对话窗口，然后就结束~试验用小程序，我们尽量的将内部的结构删减，调试起来才方便些。我们这次体验的目的就是想靠所学的知识，试图来找到MessageBox 在内存中的地址。

注：MessageBox 是来自于USER32.DLL 动态链接库里的一个函数，我们通过对PE 文件的静态反编译分析来观察hello.exe 这个试验品是如何定位和调用MessageBox 这个在USER32.dll的函数的。
（MessageBox 有两个版本，一个是MessageBoxA 还有一个是MessageBoxW 分别代表ASCII码形式和UNICODE~）

需要反汇编的两句源码如下：

invoke  MessageBox,NULL,offset szText,offset szCaption,MB_OK

invoke  ExitProcess,NULL

我们直接对其反汇编：

 

 

 反汇编后，对MessageBox和ExitProcess函数的调用变成了对0040101A和00401020地址的调用，但是这两个地址显然是位于程序自身模块而不是DLL模块中，实际上，这是由编译器在程序所有代码的后面自动加上的Jmp dword ptr[xxxxxxxx]类型的指令，这个指令时一个间接寻址的跳转指令，xxxxxxxx地址中存放的才是真正的导入函数的地址。在这个例子中，00402000地址处存放的就是ExitProcess函数的地址。

那在没有装载到内存前，PE文件中的00402000地址处的内容又是什么呢？我们来分析一下它的节表。

 

 

 由于建议装入地址是00400000h，所以00402000地址实际上处于RVA为2000h的地方，再看看各个节的虚拟地址，可以发现2000h开始的地方位于.rdata节内，而这个节的Raw_偏移为600h，也就是00402000h的内容实际上对应于PE文件中偏移600h处的数据。

我们再来看看文件0600h处的内容是什么：

 

 

 查看的结果是0002076h，这显然不是内存中的ExitProcess函数的地址。不过，我们将它作为RVA看会怎么样？RVA地址00002076h也处于.rdata节内，减去节的其实地址00002000h后得到这个RVA相对于节首的偏移是76h，也就是对应文件0676h开始的地方，接下来会惊奇地发现，0676h再过去两个字节的内容正是函数名字符串“ExitProcess”！

是不是感觉有点不对？

如果我告诉你，当PE文件被装载的时候，Windows装载器会根据xxxxxxxx处的RVA得到函数名，再根据函数名在内存中找到函数地址，并且用函数地址将xxxxxxx处的内容替换成真正的函数地址，那么所有的疑惑就迎刃而解了。接下来看看如何获取导入表的位置。

2.获取导入表的位置

导入表的位置和大小可以从PE文件中IMAGE_OPTIONAL_HEADER32结构的数据目录字段中获取。从IMAGE_OPTIONAL_DIRECTORY结构的VirtualAddress字段得到的是导入表的RVA值，如果在内存中查找导入表，那么将RVA值加上PE文件装入的基址就是实际的地址，如果在PE文件中查找导入表，那么需要使用上一篇中讲的将RVA转换成文件偏移的方法进行转换。

 

二、导入表的结构

1.PE文件中的导入表

导入表由一系列的IMAGE_IMPORT_DESCRIPTOR结构组成，结构的数量取决于程序要使用的DLL文件的数量，每一个结构对应一个DLL文件，在所有这些结构的最后，由一个内容全为0的IMAGE_IMPORT_DESCRIPTOR结构作为结束。

IMAGE_IMPORT_DESCRIPTOR结构的定义：

IMAGE_IMPORT_DESCRIPTOR STRUCT 
union 
    Characteristics              DWORD   ? 
    OriginalFirstThunk        DWORD   ? 
ends 
TimeDateStamp                     DWORD   ? 
ForwarderChain                     DWORD   ? 
Name1                                    DWORD   ? 
FirstThunk                            DWORD   ?
IMAGE_IMPORT_DESCRIPTOR ENDS

①Name1

它表示DLL 名称的相对虚地址（译注：相对一个用null作为结束符的ASCII字符串的一个RVA，该字符串是该导入DLL文件的名称，如：KERNEL32.DLL）。

②OriginalFirstThunk和FirstThunk

现在可以看成是相同的（现在），它们都指向一个包含一系列IMAGE_THUNK_DATA结构的数组，数组中的每个IMAGE_THUNK_DATA结构定义了一个导入函数的信息，数组最后以一个内容为0的IMAGE_THUNK_DATA结构作为结束。

一个IMAGE_THUNK_DATA结构实际上就是一个双字，之所以把它定义成结构，是因为它在不同时刻有不同的含义：

IMAGE_THUNK_DATA STRUC
union u1
ForwarderString       DWORD  ?        ; 指向一个转向者字符串的RVA
Function                      DWORD  ?        ; 被输入的函数的内存地址
Ordinal                       DWORD  ?        ; 被输入的API 的序数值
AddressOfData         DWORD  ?        ; 指向 IMAGE_IMPORT_BY_NAME
ends
IMAGE_THUNK_DATA ENDS

当 IMAGE_THUNK_DATA 值的最高位为 1时，表示函数以序号方式输入，这时候低 31位被看作一个函数序号。（读者可以用预定义值IMAGE_ORDINAL_FLAG32或80000000h来对最高位进行测试）
当 IMAGE_THUNK_DATA 值的最高位为 0时，表示函数以字符串类型的函数名方式输入，这时双字的值是一个 RVA，指向一IMAGE_IMPORT_BY_NAME 结构。

IMAGE_IMPORT_BY_NAME STRUCT
Hint        WORD    ? 
Name1      BYTE      ?
IMAGE_IMPORT_BY_NAME ENDS

结构中的 Hint 字段也表示函数的序号，不过这个字段是可选的，有些编译器总是将它设置为 0，Name1字段定义了导入函数的名称字符串，这是一个以 0 为结尾的字符串。

我们来看一个例子：

 

 

2.内存中的导入表

为什么需要两个一样的IMAGE_THUNK_DATA 数组呢？

当PE文件被装入内存的时候，其中一个数组的值将被改作他用，正如上面分析的，Windows装载器会将指令Jmp dword ptr[xxxxxxxx]指定的xxxxxxxx处的RVA替换成真正的函数地址，其实xxxxxxx地址正是FirstThunk字段指向的那个数组的一员。

实际上，当PE文件被装入内存后，内存中的映象就被Windows装载器修正成了下图的样子，其中由FirstThunk字段指向的那个数组中的每个双字都被替换成了真正的函数入口地址，之所以在PE文件中使用两份IMAGE_THUNK_DATA 数组的拷贝并修改其中的一份，是为了最后还可以留下一份拷贝用来反过来查询地址所对应的导入函数名。

3.导入地址表(IAT)

暂把上面FirstThunk指向的真正导入函数地址数组称为导入地址数组。在PE文件中，所有DLL对应的导入地址数组是被排列在一起的，全部这些数组的组合也被称为导入地址表(Import Address Table),导入表中第一个IMAGE_IMPORT_DESCRIPTOR结构的FirstThunk字段指向的就是IAT的起始地址。也可以通过数据目录表的第13项找到IAT数据块的位置和大小。

 

 

 

《PE总结 》– DOS文件头、PE文件头、节表和表详解（一）

PE(Portable Executeable File Format，可移植的执行体文件格式)，使用该格式的目标是使链接生成的EXE文件能在不同的CPU工作指令下工作。

可执行文件的格式是操作系统工作方法的真实写照。Windows操作系统中可执行程序有好多种，比如COM、PIF、SCR、EXE等，这些文件的格式大部分都继承自PE。其中，EXE是最常见的PE文件，动态链接库(大部分以dll为扩展名的文件)也是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/可移值的执行体）。

PE文件的基本结构如图示：

 

 

 

一、DOS ME头IMAGE_DOS_HEADER

IMGAE_DOS_HEADER的具体定义如下：

IMAGE_DOS_HEADER STRUCT 

+00h WORD e_magic  // Magic DOS signature MZ(4Dh 5Ah)   DOS可执行文件标记 

+02h  WORD e_cblp   // Bytes on last page of file  

+04h WORD e_cp   // Pages in file

+06h WORD e_crlc   // Relocations

+08h 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代码的初始堆栈入口 CS

+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 LONG  e_lfanew  // Offset to start of PE header   指向PE文件头 

IMAGE_DOS_HEADER ENDS

第一个字段e_magic被定义成字符“MZ”作为识别标志，后面的一些字段指明了入口地址、堆栈位置和重定位表位置等。

对于PE文件来说，有用的是最后的e_lfanew字段，这个字段指出了真正的PE文件头在文件中的位置，这个位置总是以8字节为单位对齐的。

 

 

 从图中我们可以看到e_lfanew的值为000000E8，也就是说000000E8处是我们的PE文件头的位置。

二、PE文件头

PE文件头是由IMAGE_NT_HEADERS结构定义的：

IMAGE_NT_HEADERS STRUCT 

+0h DWORD Signature                    PE文件标识

+4h   IMAGE_FILE_HEADER  FileHeader

+18h IMAGE_OPTIONAL_HEADER32 OptionalHeader  

IMAGE_NT_HEADERS ENDS

PE文件头的第一个双字是一个标志，它被定义为00004550，也就是字符P E加上两个0，这也是PE这个称呼的由来。从名称来看似乎后面的这个PE文件表头结构是可选的，但实际上这个名称是名不符实的，因为它总是存在于每个PE文件中。

1.IMAGE_FILE_HEADER结构

IMAGE_FILE_HEADER STRUCT
+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 ENDS

 

 为大家详细解释各个成员的含义和用法：

①Machine：可执行文件的目标CPU类型。

 

 

 更多定义参见Windows.inc文件。

②NumberOfSection: 区块的数目。（注：区块表是紧跟在 IMAGE_NT_HEADERS 后边的）

③TimeDataStamp: 表明文件是何时被创建的。

这个值是自1970年1月1日以来用格林威治时间（GMT）计算的秒数，这个值是比文件系统（FILESYSTEM）的日期时间更加精确的指示器。

④PointerToSymbolTable: COFF 符号表的文件偏移位置，现在基本没用了。

⑤NumberOfSymbols: 如果有COFF 符号表，它代表其中的符号数目，COFF符号是一个大小固定的结构，如果想找到COFF 符号表的结束位置，则需要这个变量。

⑥SizeOfOptionalHeader: 紧跟着IMAGE_FILE_HEADER 后边的数据结构（IMAGE_OPTIONAL_HEADER）的大小。(对于32位PE文件，这个值通常是00E0h；对于64位PE32+文件，这个值是00F0h )。

⑦Characteristics: 文件属性，有选择的通过几个值可以运算得到。( 这些标志的有效值是定义于 winnt.h 内的 IMAGE_FILE_** 的值，具体含义见下表。普通的EXE文件这个字段的值一般是 0100h，DLL文件这个字段的值一般是 210Eh。)多种属性可以通过 “或运算” 使得同时拥有！

 

 

 2.IMAGE_OPTIONAL_HEADER32结构

IMAGE_OPTIONAL_HEADER32 STRUCT
+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
+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];  // 数据目录表
IMAGE_OPTIONAL_HEADER32 ENDS

事实上，这个结构中的大部分字段都不重要，大家可以从注释中理解它们的含义，我将比较重要的字段在下边跟大家详细讲解：

①AddressOfEntryPoint字段

指出文件被执行时的入口地址，这是一个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字段指定了节存储在磁盘文件中时的对齐单位。

④Subsystem字段

指定使用界面的子系统，它的取值如表所示。这个字段决定了系统如何为程序建立初始的界面，链接时的/subsystem:**选项指定的就是这个字段的值，在前面章节的编程中我们早已知道：如果将子系统指定为Windows CUI，那么系统会自动为程序建立一个控制台窗口，而指定为Windows GUI的话，窗口必须由程序自己建立。界面子系统的取值和含义如下：

 

 

 ⑤DataDirectory字段

这个字段可以说是最重要的字段之一，它由16个相同的IMAGE_DATA_DIRECTORY结构组成，虽然PE文件中的数据是按照装入内存后的页属性归类而被放在不同的节中的，但是这些处于各个节中的数据按照用途可以被分为导出表、导入表、资源、重定位表等数据块，这16个IMAGE_DATA_DIRECTORY结构就是用来定义多种不同用途的数据块的IMAGE_DATA_DIRECTORY结构的定义很简单，它仅仅指出了某种数据块的位置和长度。

IMAGE_DATA_DIRECTORY STRUCT

VirtualAddress DWORD ?    ;数据的起始RVA

isize DWORD ?    ;数据块的长度

IMAGE_DATA_DIRECTORY ENDS

数据目录列表的含义如下：

 

 

 在PE文件中寻找特定的数据时就是从这些IMAGE_DATA_DIRECTORY结构开始的，比如要存取资源，那么必须从第3个IMAGE_DATA_DIRECTORY结构（索引为2）中得到资源数据块的大小和位置；同理，如果要查看PE文件导入了哪些DLL文件的哪些API函数，那就必须首先从第2个IMAGE_DATA_DIRECTORY结构得到导入表的位置和大小。

《PE总结 》– DOS文件头、PE文件头、节表和表详解（二）

好了，我们继续接着上一篇来讲解节表和表。

三、节表和节

1.首先我们先来了解Windows是如何将PE文件映射到内存的。

在执行一个PE文件的时候，windows 并不在一开始就将整个文件读入内存的，而是采用与内存映射文件类似的机制。也就是说，windows 装载器在装载的时候仅仅建立好虚拟地址和PE文件之间的映射关系。当且仅当真正执行到某个内存页中的指令或者访问某一页中的数据时，这个页面才会被从磁盘提交到物理内存，这种机制使文件装入的速度和文件大小没有太大的关系。

但是要注意的是，系统装载可执行文件的方法又不完全等同于内存映射文件。当使用内存映射文件的时候，系统对“原著”相当忠实，如果将磁盘文件和内存映像比较的话，可以发现不管是数据本身还是数据之间的相对位置的都是完全相同的。而我们知道，在装载可执行文件的时候，有些数据在装入前会被预处理，如重定位等，正因此，装入以后，数据之间的相对位置可能发生微妙的变化。

 

 

 Windows 装载器在装载DOS部分、PE文件头部分和节表（区块表）部分是不进行任何特殊处理的，而在装载节（区块）的时候则会自动按节（区块）的属性做不同的处理。

①内存页的属性：

对于磁盘映射文件来说，所有的页都是按照磁盘映射文件函数指定的属性设置的。但是在装载可执行文件时，与节对应的内存页属性要按照节的属性来设置。所以，在同属于一个模块的内存页中，从不同节映射过来的的内存页的属性是不同的。

②节的偏移地址：

节的起始地址在磁盘文件中是按照 IMAGE_OPTIONAL_HEADER32 结构的 FileAlignment 字段的值进行对齐的，而当被加载到内存中时是按照同一结构中的 SectionAlignment 字段的值对其的，两者的值可能不同，所以一个节被装入内存后相对于文件头的偏移和在磁盘文件中的偏移可能是不同的。

注意，节事实上就是相同属性数据的组合！当节被装入到内存中的时候，相同一个节所对应的内存页都将被赋予相同的页属性， 事实上，Windows 系统对内存属性的设置是以页为单位进行的，所以节在内存中的对齐单位必须至少是一个页的大小。（对于32位操作系统来说，这个值一般是4KB==1000H; 对于64位操作系统这个值一般是8KB==2000H）。节在磁盘中就没有最小4K的限制，为了减少磁盘文件的大小，文件对齐的单位一般要小于内存对齐的单位(FileAlignment的值一般为200h，一个扇区)，这样，在磁盘中就不必为每个节最后的零头数据补足4KB的大小了。

③节的尺寸：

对节的尺寸的处理主要分为两个方面：

第一个方面，正如刚刚我们所讲的，由于磁盘映像和内存映像中节对齐存储单位的不同而导致了长度扩展不同（填充的0数量不同嘛~）；

第二个方面，是对于包含未初始化数据的节的处理问题。既然是未初始化，那么没有必要为其在磁盘中浪费空间资源，但在内存中不同，因为程序一运行，之前未初始化的数据便有可能要被赋值初始化，那么就必须为他们留下空间。

④不进行映射的节：

有些节并不需要被映射到内存中，例如.reloc节，重定位数据对于文件的执行代码来说是透明的，无作用的，它只是提供Windows 装载器使用，执行代码根本不会去访问到它们，所以没有必要将他们映射到物理内存中。

2.节表

PE文件中所有节的属性都被定义在节表中，节表由一系列的IMAGE_SECTION_HEADER结构排列而成，每个结构用来描述一个节，结构的排列顺序和它们描述的节在文件中的排列顺序是一致的。全部有效结构的最后以一个空的IMAGE_SECTION_HEADER结构作为结束，所以节表中IMAGE_SECTION_HEADER结构数量等于节的数量加一。节表总是被存放在紧接在PE文件头的地方。

另外，节表中 IMAGE_SECTION_HEADER 结构的总数总是由PE文件头 IMAGE_NT_HEADERS 结构中的 FileHeader.NumberOfSections 字段来指定的。

IMAGE_SECTION_HEADER STRUCT
BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 8个字节的节区名称
union Misc
  DWORD PhysicalAddress;        
  DWORD VirtualSize;            //节区的尺寸
ends
DWORD VirtualAddress;         // 节区的 RVA 地址
DWORD SizeOfRawData;            // 在文件中对齐后的尺寸
DWORD PointerToRawData;        // 在文件中的偏移量
DWORD PointerToRelocations;     // 在OBJ文件中使用，重定位的偏移
DWORD PointerToLinenumbers;   // 行号表的偏移（供调试使用地）
WORD NumberOfRelocations;      // 在OBJ文件中使用，重定位项数目
WORD NumberOfLinenumbers;    // 行号表中行号的数目
DWORD Characteristics;       // 节属性如可读，可写，可执行等
IMAGE_SECTION_HEADER ENDS

真正有用的几个字段说明如下：

①Name1：区块名。这是一个由8位的ASCII 码名，用来定义区块的名称。多数区块名都习惯性以一个“.”作为开头（例如：.text），这个“.” 实际上是不是必须的。值得我们注意的是，如果区块名达到8 个字节，后面就没有0字符了。并且前边带有一个“$” 的区块名字会从连接器那里得到特殊的待遇，前边带有“$” 的相同名字的区块在载入时候将会被合并，在合并之后的区块中，他们是按照“$” 后边的字符的字母顺序进行合并的。
每个区块的名称都是唯一的，不能有同名的两个区块。但事实上节的名称不代表任何含义，他的存在仅仅是为了正规统一编程的时候方便程序员查看方便而设置的一个标记而已。所以将包含代码的区块命名为“.Data” 或者说将包含数据的区块命名为“.Code” 都是合法的。
当我们要从PE 文件中读取需要的区块时候，不能以区块的名称作为定位的标准和依据，正确的方法是按照 IMAGE_OPTIONAL_HEADER32 结构中的数据目录字段结合进行定位。

②Virtual Size：对表对应的区块的大小，这是区块的数据在没有进行对齐处理前的实际大小。

③Virtual Address：该区块装载到内存中的RVA 地址。这个地址是按照内存页来对齐的，因此它的数值总是 SectionAlignment 的值的整数倍。

④PointerToRawData：指出节在磁盘文件中所处的位置。这个数值是从文件头开始算起的偏移量。

⑤SizeOfRawData：该区块在磁盘中所占的大小，这个数值等于VirtualSize字段的值按照FileAlignment的值对齐以后的大小。

依靠上面4个字段的值，装载器就可以从PE文件中找出某个节(从PointerToRawData偏移开始的SizeOfRawData字节)的数据，并将它映射到内存中去(映射到从模块基地址偏移VirtualAddress的地方，并占用以VirtualSize的值按照页的尺寸对齐后的空间大小)。

⑥Characteristics：该区块的属性。该字段是按位来指出区块的属性（如代码/数据/可读/可写等）的标志。

3.RVA和文件偏移的转换

RVA 是相对虚拟地址（Relative Virtual Address）的缩写，顾名思义，它是一个“相对地址”。PE 文件中的各种数据结构中涉及地址的字段大部分都是以 RVA 表示的。

RVA 是当PE 文件被装载到内存中后，某个数据位置相对于文件头的偏移量。举个例子，如果 Windows 装载器将一个PE 文件装入到 00400000h 处的内存中，而某个区块中的某个数据被装入 0040**xh 处，那么这个数据的 RVA 就是（0040**xh – 00400000h ）= **xh，反过来说，将 RVA 的值加上文件被装载的基地址，就可以找到数据在内存中的实际地址。

 

 

 很明显，DOS 文件头、PE 文件头和区块表的偏移位置与大小均没有变化。而各个区块映射到内存后，其偏移位置就发生了变化。

当处理PE 文件时候，任何的 RVA 必须经过到文件偏移的换算，才能用来定位并访问文件中的数据，但换算却无法用一个简单的公式来完成，事实上，唯一可用的方法就是最土最笨的方法：
步骤一：循环扫描区块表得出每个区块在内存中的起始 RVA（根据IMAGE_SECTION_HEADER 中的VirtualAddress 字段），并根据区块的大小（根据IMAGE_SECTION_HEADER 中的SizeOfRawData 字段）算出区块的结束 RVA（两者相加即可），最后判断目标 RVA 是否落在该区块内。
步骤二：通过步骤一定位了目标 RVA 处于具体的某个区块中后，那么用目标 RVA 减去该区块的起始 RVA ，这样就能得到目标 RVA 相对于起始地址的偏移量 RVA2.
步骤三：在区块表中获取该区块在文件中所处的偏移地址（根据IMAGE_SECTION_HEADER 中的PointerToRawData 字段）, 将这个偏移值加上步骤二得到的 RVA2 值，就得到了真正的文件偏移地址。