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了。
延迟导入一次只会导入一个函数,而不是一次导入整个模块的所有函数。