PE文件结构详解（五）延迟导入表

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

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

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

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

在这一项后面填写需要延迟导入的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就可以获取到导入函数的地址了。

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

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

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

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