PE文件结构详解（四）PE导入表讲 了一般的PE导入表，这次我们来看一下另外一种导入表：延迟导入（Delay Import）。看名字就知道，这种导入机制导入其他DLL的时机比较“迟”，为什么要迟呢？因为有些导入函数可能使用的频率比较低，或者在某些特定的场 合才会用到，而有些函数可能要在程序运行一段时间后才会用到，这些函数可以等到他实际使用的时候再去加载对应的DLL，而没必要再程序一装载就初始化好。
这个机制听起来很诱人，因为他可以加快启动速度，我们应该如何利用这项机制呢？VC有一个选项，可以让我们很方便的使用到这项特性，如下图所示：
在这一项后面填写需要延迟导入的DLL名称，连接器就会自动帮我们将这些DLL的导入变为延迟导入。
现在我们知道如何使用延迟导入了，那这个看上去很厉害的机制是如何实现的呢？接下来我们来探索一番。在IMAGE_DATA_DIRECTORY 中，有一项为IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT，这一项便延迟导入 表，IMAGE_DATA_DIRECTORY.VirtualAddress就指向延迟导入表的起始地址。既然是表，肯定又是一个数组，每一项都是一个 ImgDelayDescr结构体，和导入表一样，每一项都代表一个导入的DLL，来看看定义：
- typedef struct ImgDelayDescr {
- DWORD grAttrs; // attributes
- RVA rvaDLLName; // RVA to dll name
- RVA rvaHmod; // RVA of module handle
- RVA rvaIAT; // RVA of the IAT
- RVA rvaINT; // RVA of the INT
- RVA rvaBoundIAT; // RVA of the optional bound IAT
- RVA rvaUnloadIAT; // RVA of optional copy of original IAT
- DWORD dwTimeStamp; // 0 if not bound,
- // O.W. date/time stamp of DLL bound to (Old BIND)
- } ImgDelayDescr, * PImgDelayDescr;
- 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里，默认保存的是一段代码的地址，当程序第一次调用到这个延迟导入函数时，流程会走到那段代码，这段代码用来干什么呢？请看一个真实的延迟导入函数的例子：
- .text:75C7A363 __imp_load__InternetConnectA@32: ; InternetConnectA(x,x,x,x,x,x,x,x)
- .text:75C7A363 mov eax, offset __imp__InternetConnectA@32
- .text:75C7A368 jmp __tailMerge_WININET
这段代码其实只有两行汇编，第一行把导入函数IAT项的地址放到eax中，然后用一个jmp跳转走，那么他跳转到哪里了呢？我们继续跟踪：
- __tailMerge_WININET proc near
- .text:75C6BEF0 push ecx
- .text:75C6BEF1 push edx
- .text:75C6BEF2 push eax
- .text:75C6BEF3 push offset __DELAY_IMPORT_DESCRIPTOR_WININET
- .text:75C6BEF8 call __delayLoadHelper
- .text:75C6BEFD pop edx
- .text:75C6BEFE pop ecx
- .text:75C6BEFF jmp eax
- .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了。
延迟导入一次只会导入一个函数，而不是一次导入整个模块的所有函数。