PE文件结构详解

时间：2022-11-26 11:52:54

by evil.eagle 转载请注明出处。

http://blog.csdn.net/evileagle/article/details/12718845


<五>延迟导入表

  PE文件结构详解（四）PE导入表讲了一般的PE导入表，这次我们来看一下另外一种导入表：延迟导入（Delay Import）。看名字就知道，这种导入机制导入其他DLL的时机比较“迟”，为什么要迟呢？因为有些导入函数可能使用的频率比较低，或者在某些特定的场合才会用到，而有些函数可能要在程序运行一段时间后才会用到，这些函数可以等到他实际使用的时候再去加载对应的DLL，而没必要再程序一装载就初始化好。

这个机制听起来很诱人，因为他可以加快启动速度，我们应该如何利用这项机制呢？VC有一个选项，可以让我们很方便的使用到这项特性，如下图所示：

PE文件结构详解


在这一项后面填写需要延迟导入的DLL名称，连接器就会自动帮我们将这些DLL的导入变为延迟导入。

现在我们知道如何使用延迟导入了，那这个看上去很厉害的机制是如何实现的呢？接下来我们来探索一番。在IMAGE_DATA_DIRECTORY中，有一项为IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT，这一项便延迟导入表，IMAGE_DATA_DIRECTORY.VirtualAddress就指向延迟导入表的起始地址。既然是表，肯定又是一个数组，每一项都是一个ImgDelayDescr结构体，和导入表一样，每一项都代表一个导入的DLL，来看看定义：

[cpp]  view plain copy
  1. typedef struct ImgDelayDescr {  
  2.     DWORD           grAttrs;        // attributes  
  3.     RVA             rvaDLLName;     // RVA to dll name  
  4.     RVA             rvaHmod;        // RVA of module handle  
  5.     RVA             rvaIAT;         // RVA of the IAT  
  6.     RVA             rvaINT;         // RVA of the INT  
  7.     RVA             rvaBoundIAT;    // RVA of the optional bound IAT  
  8.     RVA             rvaUnloadIAT;   // RVA of optional copy of original IAT  
  9.     DWORD           dwTimeStamp;    // 0 if not bound,  
  10.                                     // O.W. date/time stamp of DLL bound to (Old BIND)  
  11. } ImgDelayDescr, * PImgDelayDescr;  
  12. typedef const ImgDelayDescr *   PCImgDelayDescr;  
grAttrs：用来区分版本，1是新版本，0是旧版本，旧版本中后续的rvaxxxxxx域使用的都是指针，而新版本中都用RVA，我们只讨论新版本。

rvaDLLName：一个RVA，指向导入DLL的名字。

rvaHmod：一个RVA，指向导入DLL的模块基地址，这个基地址在DLL真正被导入前是NULL，导入后才是实际的基地址。

rvaIAT：一个RVA,表示导入函数表，实际上指向IAT，在DLL加载前，IAT里存放的是一小段代码的地址，加载后才是真正的导入函数地址。

rvaINT：一个RVA，指向导入函数的名字表。

rvaUnloadIAT：延迟导入函数卸载表。

dwTimeStamp：延迟导入DLL的时间戳。

定义知道了，那他是怎么被处理的呢？前面提到了，在延迟导入函数指向的IAT里，默认保存的是一段代码的地址，当程序第一次调用到这个延迟导入函数时，流程会走到那段代码，这段代码用来干什么呢？请看一个真实的延迟导入函数的例子：

[cpp]  view plain copy
  1. .text:75C7A363 __imp_load__InternetConnectA@32:        ; InternetConnectA(x,x,x,x,x,x,x,x)  
  2. .text:75C7A363                 mov     eax, offset __imp__InternetConnectA@32  
  3. .text:75C7A368                 jmp     __tailMerge_WININET  

这段代码其实只有两行汇编，第一行把导入函数IAT项的地址放到eax中，然后用一个jmp跳转走，那么他跳转到哪里了呢？我们继续跟踪：

[cpp]  view plain copy
  1. __tailMerge_WININET proc near             
  2. .text:75C6BEF0                 push    ecx  
  3. .text:75C6BEF1                 push    edx  
  4. .text:75C6BEF2                 push    eax  
  5. .text:75C6BEF3                 push    offset __DELAY_IMPORT_DESCRIPTOR_WININET  
  6. .text:75C6BEF8                 call    __delayLoadHelper  
  7. .text:75C6BEFD                 pop     edx  
  8. .text:75C6BEFE                 pop     ecx  
  9. .text:75C6BEFF                 jmp     eax  
  10. .text:75C6BEFF __tailMerge_WININET endp  

其中最重要的是push了一个__DELAY_IMPORT_DESCRIPTOR_WININET，这个就是上文中看到的ImgDelayDescr结构，他的DLL名字是wininet.dll。之后，CALL了一个__delayLoadHelper，在这个函数里，执行了加载DLL，查找导出函数，填充导入表等一系列操作，函数结束时IAT中已经是真正的导入函数的地址，这个函数同时返回了导入函数的地址，因此之后的eax里保存的就是函数地址，最后的jmp eax就跳转到了真实的导入函数中。

这个过程很完美，也很灵巧，但是如果仔细观察就会发现什么地方有点不对劲，你发现了吗？__delayLoadHelper的参数中只有IAT项的偏移和整个模块的延迟导入描述__DELAY_IMPORT_DESCRIPTOR_WININET，但是参数中并没有要导入函数的名字。也许你说，名字在__DELAY_IMPORT_DESCRIPTOR_WININET的名字表中，是的，那里确实有名字，但是别忘了，那是个表，里面存的是所有要从该模块导入的函数名字，而不是“当前”这个被调用函数的函数名。或许你觉得参数中应该有个索引号，用来表示名字列表中的第几项是即将被导入的那个函数的名字，不幸的是我们也没有看到参数中有这样的信息存在，那Windows执行到这里是如何得到名字的呢？MS在这里使用了一个巧妙的办法：__DELAY_IMPORT_DESCRIPTOR_WININET中有一项是rvaIAT，前面提到了，这里实际上就是指向了IAT，而且是该模块第一个导入函数的IAT的偏移，现在我们有两个偏移，即将导入的函数IAT项的偏移（记作RVA1）和要导入模块第一个函数IAT项的偏移（记作RVA0），(RVA1-RVA0)/4 = 导入函数IAT项在rvaIAT中的下标，rvaINT中的名字顺序与rvaIAT中的顺序是相同的，所以下标也相同，这样就能获取到导入函数的名字了。有了模块名和函数名，用GetProcAddress就可以获取到导入函数的地址了。

上述流程用一张图来总结一下：

PE文件结构详解

最后还有两点要提醒大家：

延迟导入的加载只发生在函数第一次被调用的时候，之后IAT就填充为正确函数地址，不会再走__delayLoadHelper了。

延迟导入一次只会导入一个函数，而不是一次导入整个模块的所有函数。


<六> 重定位


前面两篇 PE文件结构详解（四）PE导入表 和 PE文件结构详解（五）延迟导入表 介绍了PE文件中比较常用的两种导入方式，不知道大家有没有注意到，在调用导入函数时系统生成的代码是像下面这样的：

PE文件结构详解

在这里，IE的iexplorer.exe导入了Kernel32.dll的GetCommandLineA函数，可以看到这是个间接call，00401004这个地址的内存里保存了目的地址，根据图中显示的符号信息可知，00401004这个地址是存在于iexplorer.exe模块中的，实际上也就是一项IAT的地址。这个是IE6的exe中的例子，当然在dll中如果导入其他dll中的函数，结果也是一样的。这样就有一个问题，代码里call的地址是一个模块内的地址，而且是一个VA，那么如果模块基地址发生了变化，这个地址岂不是就无效了？这个问题如何解决？

答案是：Windows使用重定位机制保证以上代码无论模块加载到哪个基址都能正确被调用。听起来很神奇，是怎么做到的呢？其实原理并不很复杂，这个过程分三步：

1.编译的时候由编译器识别出哪些项使用了模块内的直接VA，比如push一个全局变量、函数地址，这些指令的操作数在模块加载的时候就需要被重定位。

2.链接器生成PE文件的时候将编译器识别的重定位的项纪录在一张表里，这张表就是重定位表，保存在DataDirectory中，序号是 IMAGE_DIRECTORY_ENTRY_BASERELOC。

3.PE文件加载时，PE 加载器分析重定位表，将其中每一项按照现在的模块基址进行重定位。

以上三步，前两部涉及到了编译和链接的知识，跟本文的关系不大，我们直接看第三步，这一步符合本系列的特征。

在查看重定位表的定义前，我们先了解一下他的存储方式，有助于后面的理解。按照常规思路，每个重定位项应该是一个DWORD，里面保存需要重定位的RVA，这样只需要简单操作便能找到需要重定位的项。然而，Windows并没有这样设计，原因是这样存放太占用空间了，试想一下，加入一个文件有n个重定位项，那么就需要占用4*n个字节。所以Windows采用了分组的方式，按照重定位项所在的页面分组，每组保存一个页面其实地址的RVA，页内的每项重定位项使用一个WORD保存重定位项在页内的偏移，这样就大大缩小了重定位表的大小。

有了上面的概念，我们现在可以来看一下基址重定位表的定义了：

[cpp]  view plain copy
  1. typedef struct _IMAGE_BASE_RELOCATION {  
  2.     DWORD   VirtualAddress;  
  3.     DWORD   SizeOfBlock;  
  4. //  WORD    TypeOffset[1];  
  5. } IMAGE_BASE_RELOCATION;  
  6. typedef IMAGE_BASE_RELOCATION UNALIGNED * PIMAGE_BASE_RELOCATION;  
VirtualAddress：页起始地址RVA。

SizeOfBlock：表示该分组保存了几项重定位项。

TypeOffset：这个域有两个含义，大家都知道，页内偏移用12位就可以表示，剩下的高4位用来表示重定位的类型。而事实上，Windows只用了一种类型IMAGE_REL_BASED_HIGHLOW  数值是 3。

好了，有了以上知识，相信大家可以很容易的写出自己修正重定位表的代码，不如自己做个练习验证一下吧。

本文 by evil.eagle 转载的时候请注明出处。http://blog.csdn.net/evileagle/article/details/12886949

最后，还是总结一下，哪些项目需要被重定位呢？

1.代码中使用全局变量的指令，因为全局变量一定是模块内的地址，而且使用全局变量的语句在编译后会产生一条引用全局变量基地址的指令。

2.将模块函数指针赋值给变量或作为参数传递，因为赋值或传递参数是会产生mov和push指令，这些指令需要直接地址。

3.C++中的构造函数和析构函数赋值虚函数表指针，虚函数表中的每一项本身就是重定位项，为什么呢？大家自己考虑一下吧，不难哦~

标签：

相关文章