网络安全编程：PE结构的地址与地址的转换

用OD调试器调试程序时看到的地址与使用C32Asm以十六进制形式查看程序时的地址形式有所差异。程序在内存中与在文件中有着不同的地址形式，而且PE相关的地址不只有这两种形式。与PE结构相关的地址形式有3种，且这3种地址形式可以进行转换。

1. 与PE结构相关的3种地址

与PE结构相关的3种地址是VA（虚拟地址）、RVA（相对虚拟地址）和FileOffset（文件偏移地址）。

VA（虚拟地址）：PE 文件映射到内存后的地址。

RVA（相对虚拟地址）：内存地址相对于映射基地址的偏移地址。

FileOffset（文件偏移地址）：相对 PE 文件在磁盘上的文件开头的偏移地址。

PE文件在磁盘上和在内存中的结构是一样的。所不同的是，在磁盘上，文件是按照IMAGE_OPTIONAL_HEADER的FileAlignment值进行对齐的。而在内存中，映像文件是按照IMAGE_OPTIONAL_HEADER的SectionAlignment进行对齐的。FileAlignment是以磁盘上的扇区为单位的，也就是说，FileAlignment最小为512字节，十六进制的0x200字节。而SectionAlignment是以内存分页为单位来对齐的，通常Win32平台一个内存分页为4KB，也就是十六进制的0x1000字节。一般情况下，FileAlignment的值会与SectionAlignment的值相同，这样磁盘文件和内存映像的结构是完全一样的。当FileAlignment的值和SectionAlignment的值不相同的时候，就存在一些细微的差异了，其主要区别在于，根据对齐的实际情况而多填充了很多0值。PE文件映射如图1所示。

图1 PE文件映射图

除了文件对齐与内存对齐的差异以外，文件的起始地址从0地址开始，用C32Asm的十六进制模式查看PE文件时起始位置是0x00000000。而在内存中，它的起始地址为IMAGE_OPTIONAL_HEADER结构体的ImageBase字段（该说法只针对EXE文件，DLL文件的映射地址不一定固定，但是绝对不会是0x00000000地址）。

2. 3种地址的转换

当FileAlignment和SectionAlignment的值不相同时，磁盘文件与内存映像的同一节表数据在磁盘和内存中的偏移也不相同，这样两个偏移就发生了一个需要转换的问题。当知道某数据的RVA，想要在文件中读取同样的数据的时候，就必须将RVA转换为FileOffset。反之，也是同样的情况。

下面用一个例子来介绍如何进行转换。一个用MessageBox()输出“Hello World”的例子程序，用PEID打开它，查看它的节表情况，如图2所示。

图2 PEID显示的节表内容

从图2的标题栏可以看到，这里不叫“节表”，而叫“区段”。还有别的资料上称之为“区块”或“节区”，只是叫法不同，内容都是一样的。

从图2中可以看到，节表的第一个节区的节名称为“.text”。通常情况下，第一个节表项都是代码区，入口点也通常落在这个节表项。在早期壳不流行时，通过判断入口点是否在第一个节区就可以判断该程序是否被病毒感。如今，由于壳的流行，这种判断方法就不可靠了。关键要看的是“R.偏移”，表明了该节区在文件中的起始位置。PE头部包括DOS头、PE头和节表，通常不会超过512字节，也就是说，不会超过0x200的大小。如果这个“R.偏移”为0x00001000，那么通常情况下可以确定该文件的磁盘对齐大小为0x1000。测试验证一下这个程序，看到“V.偏移”与“R.偏移”相同，则说明磁盘对齐与内存对齐是一样的，这样就没办法完成演示转换的工作了。不过，可以人为地修改文件对齐大小。也可以通过工具来修改文件对齐的大小。这里借助LordPE来修改其文件对齐大小。修改方法很简单，先将要修改的测试文件复制一份，以与修改后的文件做对比。打开LordPE，单击“重建PE”按钮，然后选择刚才复制的那个测试文件，如图3和图4所示。

图3 LordPE界面

图4 重建PE功能结果

PE重建功能中有压缩文件大小的功能，这里的压缩也就是修改磁盘文件的对齐值，避免过多地因对齐而进行补0，使其少占用磁盘空间。用PEID查看这个进行重建的PE文件的节表，如图5所示。

图5 重建PE文件后的节表

现在可以看到“V.偏移”与“R.偏移”的值不相同了，它们的对齐值也不相同了，大家可以自己验证一下FileAlignment和SectionAlignment的值是否相同。

现在有两个功能完全一样，而且PE结构也一样的两个文件了，唯一的不同就是其磁盘对齐大小不同。现在在这两个程序中分别寻找一个节表中的数据，学习不同地址之间的转换。

先用OD打开未进行重建PE结构的测试程序，找到反汇编中调用MessageBox()处要弹出对话框的两个字符串参数的地址，如图6和图7所示。

图6 MessageBox()函数中使用的字符串地址

图7 两个字符串的地址在数据窗口的显示

从图6和图7中可以看到，字符串“hello world!”的地址为0x00406030，字符串“hello”的地址为0x00406040。这两个地址都是虚拟地址，也就是VA。

将VA（虚拟地址）转换为RVA（相对虚拟地址）是很容易的，RVA（相对虚拟地址）为VA（虚拟地址）减去IMAGE_OPTIONAL_HEADER结构体中的ImageBase（映像文件的装载虚拟地址）字段的值，即RVA= VA – ImageBase = 0x00406030 – 0x00400000 = 0x00006030。由于IMAGE_OPTIONAL_HEADER中的SectionAlignment和FileAlignment的值相同，因此其FileOffset的值也为0x00006030。用C32Asm打开该文件查看文件偏移地址0x00006030处的内容，如图8所示。

图8 文件偏移0x00006030处的内容为“hello world！”字符串

从这个例子中可以看出，当SectionAlignment和FileAlignment相同时，同一节表项中数据的RVA（相对虚拟地址）和FileOffset（文件偏移地址）是相同的。RVA的值是用VA– ImageBase计算得到的。

再用OD打开“重建PE”后的测试程序，同样找到反汇编中调用MessageBox()函数使用的那个字符串“hello world!”，看其虚拟地址是多少。它的虚拟地址仍然是0x00406030。同样，用虚拟地址减去装载地址，相对虚拟地址的值仍然为0x00006030。不过用C32Asm打开该文件查看的话会有所不同。用C32Asm看一下0x00006030地址处的内容，如图9所示。

图9 文件偏移0x00006030处没有“hello world！”字符串

从图9中可以看到，用C32Asm打开该文件后，文件偏移0x00006030处并没有“helloworld！”和“hello”字符串。这就是由文件对齐与内存对齐的差异所引起的。这时就要通过一些简单的计算把RVA转换为FileOffset。

把RVA转换为FileOffset的方法很简单，首先看一下当前的RVA或者是FileOffset属于哪个节。0x00006030这个RVA属于.data节。0x00006030这个RVA相对于该节的起始RVA地址0x00006000来说偏移0x30字节。再看.data节在文件中的起始位置为0x00004000，以.data节的文件起始偏移0x00004000加上0x30字节的值为0x00004030。用C32Asm看一下0x00004030地址处的内容，如图10所示。

图10 0x00004030文件偏移处的内容

从图10中可以看出，该文件偏移处保存着“hello world!”字符串，也就是说，将RVA转换为FileOffset是正确的。通过LordPE工具来验证一下，如图11所示。

图11 用LordPE计算RVA为0x00006030的文件偏移

再来回顾一下这个过程。

某数据的文件偏移 = 该数据所在节的起始文件偏移 + （某数据的RVA –该数据所在节的起始RVA）。

除了上面的计算方法以外，还有一种计算方法，即用节的起始RVA值减去节的起始文件偏移值，得到一个差值，再用RVA减去这个得到的差值，就可以得到其所对应的FileOffset。可以使用例子程序进行手工计算，然后通过LordPE进行验证。

知道如何通过RVA转换为文件偏移，那么通过文件偏移转换为RVA的方法也就不难了。这3种地址相互的转换方法就介绍完了。如果没有理解，就可以反复地按照公式进行学习和计算。只要在头脑中建立关于磁盘文件和内存映像的结构，那么理解起来就不会太吃力。