DelayLoad

   在 1998年12月的MSJ出版刊物中, Jeffrey和我写了关于 在 vc6中使用DelayLoad 功能的专栏.最终结果,是证明了它是多么cool.但是,不幸的是,还有很多人不了解DelayLoad,他们以为这个新特点是 最新版本的WINNT才有的.
    在开始的时候,让我重申一遍:DelayLoad不是最新的操作系统带的特有功能,它可以在任何win32系统中起作用.我将写一个简单例子来说明. DelayLoadProfile, 实现了一个很小功能,很多程序都可以得益于它.


预览:
    通常的,当调用一个dll中的函数时,连接器会将dll和函数加入你的可执行文件.最后,所有引用的函数会放在imports段中.  当加载该程序的时候,win32程序加载器会扫描所有imports段的每个dll.加载,和重新定位imports段的所有函数,将信息写入 引入地址表(ImportAddress Table, IAT).简单说来,IAT就是一个函数指针的表.调用该 引入函数的时候,就到IAT中去找.  那么,DelayLoad的机理是什么呢?当你为一个Dll进行"DelayLoad"的时候,连接器不将原来的值放入imports段,相反,它为每个DelayLoad的引入函数的名称和地址,生成一个小的根区, 备份下来。第一次引用的时候,它调用LoadLibrary加载Dll,然后,它调用GetProcAddress取得该函数的地址。最后,改写自己在IAT的值,以便以后的程序可以直接调用.
    上面的是简化的步骤.实际上,根区是一小段代码,它以静态的方式连接到可执行文件中.代码在delayimp.lib中,必须被 连接程序引用.并且,该代码要足够智能,当一个函数第一次被引用的时候,要调用LoadLibrary,以后调用就不用引用了.  和引用Dll相比,DelayLoad不会加太多的时间和空间,这种方式 调用LoadLibrary只会引起稍微一点点的性能损失.每次程序启动,在针对引入表的函数地址定位的时候,依次对DelayLoad引入的调用GetProcAddress,相对于Win32加载器来说,所损失的性能也可以忽略不记.
    然而,DelayLoad带来的好处也是不可比拟的.例如:如果你的程序从来没有 从Delay调用引入的函数,Dll的第一次是不会被加载的。有时候,这个情况的出现频率出乎你想象。假如,你的程序中,包含打印的代码,毫无疑问,即使用户没有使用打印功能,你的程序也一定要加载winspool.drv。在这种情况下,使用DelayLoad,你就不必加载和初始化Winspool.drv.
    另外一个好处就是:DelayLoad可以避免调用某些目标平台不存在的API。例如,假如你的程序需要调用AnimateWindow,这个API在Win2000和Win98中存在,但是在Win95和WinNT4中,就不存在,假如你用常规的方式调用AnimateWindow,那么,你的程序将不能再早期的平台中运行。然而,你可以用DelayLoad进行对AnimateWindow的加载检查。这样,你就不必改写你的代码为LoadLibrary和GetProcAddress的方式了。
    DelayLoad是很容易使用的。当你决定哪个dll你想使用DelayLoad,只需要简单的增加/DELAYLOAD:DLLNAME。其中,DLLNAME是相关的DLL文件名。你还需要增加DELAYIMP.LIB到连接库中,你也需要原来的LIB,例如,SHELL32.LIB。把全部放到一块,连接的命令就如下: SHELL32.LIB /DELAYLOAD:SHELL32.DLL DELAYIMP.LIB  很不幸,Visual Studio 6.0 IDE 不提供一个简单的方法去实现一个Dll的DelayLoad。所以,你必须手工加入:/DELAYLOAD:XXX 命令行到 "Project settings"->"Link"->"Project Options"中。
   
什么时候需要DelayLoad:
    当你有小的工程,它调用了多个dll,就是一个好的DelayLoad候选例子。然而,工程可能在以后由于其它开发者的加入而变大,很容易丢失调用dll的跟踪。我通常用sdk中的depends.exe。一个只有少数函数要引入的dll就是一个好的开始。
    然而,我想找到一个简单的,自动的方法来跟踪。于是,出来了DelayLoadProfile程序。它是一个exe,可以监视你的exe文件对dll的调用,直到你的exe结束。它打印出dll被调用的情况的汇总,包括多少个dll被调用,每个dll有多少个函数被引入。
    我在这里强调:DelayLoadProfile只是针对exe有效,当它涵盖你的程序所关联的所有dll的时候,有时会造成一点点复杂。DelayLoadProfile只给你哪个dll可以用DelayLoad开关的暗示,你最好在不确定的时候,使用原来的处理方法。

DelayLoadProfile:详细描述
    其实DelayLoadProfile的原理很简单:重定向 exe中,IAT的函数的指针到一段根区。根区简单的标志一下,引入的函数被调用了。然后,跳入原来的Win32加载提供的IAT地址。只是,难的是如何实现。
    第一,你必须决定,要在哪里运行你的代码,实现对exe的IAT入口的更改,把他们指定到那段根区去。这些都是在进程外完成。这样可以避免你的代码牵涉到目的exe进程中。这个可以用遍历所有的数据结构,定位和修改IAT结构的方法。我在这里利用了很多ReadProcessMemory调用。
    接着的艰苦工作是要在和目的exe相同的进程空间里完成。几乎是很琐碎的工作:遍历所有的数据结构,建立根区,从定向IAT入口,然后在完成的时候,汇总结果。然而,为了完成进程空间的工作,在exe进程运行的时候,一些 DelayLoadProfile代码必须被加载到目的exe的进程空间。这个是我要做的。
    当确认到需要在目的进程中,加载我的代码的时候,下个问题就是如何把我的代码加入到目的进程中。其中一个选择就是,要求用户连接我的DelayLoadProfile库,这个会造成用户的很大量的对他们源代码工程,或者Makefile的更改,所以,我不能采用,现在需要一个完全自动化的方法。
    在这点上,我想到了加载程序,然后,插入我的DelayLoadProfiledll进去,一个技术就是用CreateRemoteThread,在目标进程,创建一个LoadLibrary的线程。我放弃了这个,因为,win9x中,不提供CreateRemoteThread.
    很久以前的MSJ读者可能记得我5年前写的一个叫APISPY32的程序。它加载一个进程,插入一个dll来记录API的调用。那个有点像我今天的DelayLoadProfile工作。然而,我在Win200中,调用那个dll失败。有一点点问题。我觉得现在是时候要重读那段代码,并且改正那个错误了。
   
继续深入:
    重新温习一下,DelayLoadProfile包含2部分,一,是进程加载功能,它会注射一个dll到你的进程的地址空间。然后,那个dll扫描你的所有的exe IAT,重新定向他们到dll创建的根区中。当你的程序完成后,注射的dll会扫描所有的根区,统计出多少dll和函数它调用的。如果你曾经用过APIMON的相关部件,你将认出类似的技术细节。
    完成所有的工作,包括 监视 一个程序的引入的dll,叫DelayLoadProfileDLL.(看Figure 1).它用到DLL_PROCESS_ATTACH和DLL_PROCESS_DETACH来初始化2个主要的工作。
    当DllMain获得DLL_PROCESS_ATTACH的消息的时候,DelayLoadProfileDLL调用PrepareToProfile(),在PrepareToProfile中,代码加载目的EXE的IAT,对于每个它发现的引用的DLL,代码还检测是否安全的重定向IAT。通过IsModuleOKToHook函数来检测,大多数情况下,是安全的,因此,PrepareToProfile包括了RedirectIAT函数。
    RedirectIAT是比较复杂的函数。如果你理解了 winini.h中的引入相关数据结构,你将得到很大的帮助。首先,函数定位IAT和相关的引入名字表,然后,计算有多少个IAT入口,扫描所有的IAT,查找NULL的指针。得到了数目后,程序将创建一个DLPD_IAT_STUB根区,每个根区对应一个IAT入口。
    最后,代码重新扫描IAT,获取每个IAT入口的地址,用根区的一个包含JMP指令的地址,替换IAT入口。它还扫描下一个IATDLPD_IAT_STUB根区。我在后面将还会继续解析。
    在重定向IAT入口的根区中,有2个值得提起:1,IAT常常被放到EXE的只读段,通常,尝试改写只读段,会引起访问违规,幸运的,VirtualProtect允许你更改一个目的地址的属性。现在必须更改iat的属性为读/写。完成后,代码要恢复IAT段原来的属性。
    另外一个要注意的地方,就是在重定向IAT的时候,有数据引入的问题。虽然程序员们很少这样做,但是,很容易用增加的代码去导入数据。vc++运行库DLL(MSVCRT.DLL)有数据导出。如果重定向一个数据IAT的入口,会导致问题。
    那么,如何判断一个IAT是数据呢?一个商业的软件,应该用准确的算法来判断一个IAT入口的类型。但是,我在这里用了一个快捷方法。就是IsBadWritePtr。如果IAT包含的指针是可写的,那么,很可能是一个数据指针。如果是只读的,那么,应该是一段代码。这个测试合适吗?不,但是,它对DelayLoadProfile是足够了。
    现在看一下根区,在DelayLoadProfileDLL.h中定义的DLPD_IAT_STUB结构包含着代码和数据。简单来说,就是如下:
  CALL DelayLoadProfileDLL_UpdateCount
  JMP xxxxxxxx //original IAT 地址
  DWORD count
  DWORD pssNameOrOrdinal

    当exe调用其中一个重定向的函数时,控制权被转到根区的CALL指令中,调用DelayLoadProfileDLL.CPP中的DelayLoadProfileDLL_UpdateCount函数,在call指令返回时,继续调用jmp 跳转到IAT原来取得的地址中。Figure2显示了结构示意图。
    汇编高手会对DelayLoadProfileDLL_UpdateCount函数能确定根区的COUNT字段的地址,感到疑惑,通过快速的察看代码,会发现DelayLoadProfileDLL_UpdateCount会在堆栈中,查找到返回地址。返回地址指着JMP xxxxxxxx指令。因为,CALL调用总是5个字节,根据这些算法,可以确定COUNT字段的地址。
    有一个问题值得提醒,就是DelayLoadProfileDLL_UpdateCount没有调用PUSHAD和POPAD指令来保存/回复CPU寄存器的值。这段代码在很多程序上都工作正常,但是,却在一些函数中,不能正常工作。最后,发现 MSVCRT.DLL的__CxxFrameHandler和 _EH_prolog有问题,这2个函数 期望eax寄存器被设置成某个值。然而,DelayLoadProfileDLL_UpdateCount更改了EAX.  既然这个是由于EAX引起的问题,那么,我增加了PUSHAD和POPAD,昏倒,问题还存在。在遭受挫折后,我检查了汇编生成的代码。通常,VC6编译器会插入将所有本地变量都初始化为0xCC的代码。这些代码会在PUSHAD和POPAD前,将EAX改变。我只好移去/GZ的选项。


结果报告:
    当你的进程停止的时候,系统对所有加载的DLL发送一个DLL_PROCESS_DETACH消息。DelayLoadProfileDLL使用这个选项来搜集程序运行过程中,获得的结果。也是说,再次遍历所有的根区单元。收集所有获得的数据,输出。
    在DelayLoadProfileDLL安装的阶段,重定向IAT,它保存exe的IAT到一个公共的变量出g_pFirstImportDesc。在关闭的过程中,ReportProfileResults用到这个指针来再次遍历引入段。如果这个IAT是被重定向的,那么,第一个IAT的指针应该指到第一个为该DLL分配的DLPD_IAT_STUB根区内存。当然,代码保持了基本的测试方法,如果某些地方不正确,DelayLoadProfileDLL忽略该特定的dll。
    总的说来,所有的都很正常,并且,第一个IAT入口指到我的根区单元。对于每个DLL,代码反复的遍历所有的根区。每个相关的根区,它的包含的字段的值,将加到该DLL的总计数。当遍历完成,ReportProfileResults格式化一个字符串,输出该dll的名字,和调用的总次数。代码还用OutputDebugString广播该结果。

加载和注射:
    本程序加载你的exe,注射DelayLoadProfileDLL.dll将会调用,(你猜到了),是DelayLoadProfile.exe(源文件可以在msj的网站找到,http://www.microsoft.com/msj)。这个代码主要继承了CDebugInjector类。我将简单的介绍它。函数主要包含了目的exe的命令行,并且传递到CDebugInjector::LoadProcess。如果进程被成功创建,函数会告诉CDebugInjector,哪个dll会被注射,既然是这样,和DelayLoadProfile.exe同目录的DelayLoadProfileDLL.DLL,将会被加载。
    在运行目标程序之前,最后的步骤是调用CDebugInjector::SetOutputDebugStringCallBack。当DelayLoadProfileDLL用OutputDebugString来输出报告结果的时候,CDebugInjector看到他们,然后传递他们到你已经注册的回调函数中。这个回调函数只是用printfs输出字符串到控制台。最后,函数调用CDebugInjector::Run。这样,目的进程开始运行,当时机成熟,注射dll进去。  描述3(hoodtextfigs.htm#fig3)说明了CDebugInjector类。这是代码实现的地方。CDebugtInjector::LoadProcess创建了目的进程,作为一个调试进程,它的分支已经在msdn的很多文档中讨论过了,这里,不想作太多具体的讨论。
    调试进程运行后(这里是DelayLoadProfile)进入了一个循环,不断的调用WaitForDebugEvent和ContinueDebugEvent,直到调试停止。每次WaitForDebugEvent返回,都有些东西发生在调试程序身上。可能是一个异常(包括断点),或者加载一个dll,或者创建一个线程,或者其他事件。WaitForDebugEvent文档历包含了所有的可能的事件。CDebugInjector::Run过程包含这个循环的代码。
    那么,如何让目的进程作为一个被调试进程,帮助你注射一个dll呢?一个调试进程可以控制的被调试进程的执行过程。每次被调试程序有一个信号事件发生,它都会暂停,等待调试者调用ContinueDebugEvent继续运行。了解了这个,一个调试进程可以增加代码到被调试进程的空间,和临时改变被调试者的寄存器值,以便增加的代码运行。
    在某些特定场合,CDebugInjector合成了一小段代码根区来调用LoadLibrary。LoadLibrary的dll名字参数,指到要被注射的dll的名字。CDebugInjector写那个根区(和相关联的dll名字)到被调试者的地址空间。然后,调用SetThreadContext来改变被调试者的指令寄存器,运行LoadLibrary根区。所有的相关代码在CDebugInjector::PlaceInjectionStub过程中。
    立刻的,根区中的LoadLibrary调用后,是一个断点(int 3)。这个暂停被调试者的运行,交回控制权给调试的进程。调试者用SetThreadContext,恢复指令寄存器和其他寄存器到原来的值。另一次调用ContinueDebugEvent,被调试者在dll注射的状态下,继续运行。没有人知道发生了什么事情。
    如果你不想那么多,这个注射进程不会觉得太难,但是,一些有兴趣的东西,弄复杂了事情。例如,什么时候创建根区,改变运行代码,才是适当呢?你不能在CreateProcess后立刻做这个,因为,引入的dll还没有被映射到内存中,WIN32加载器还没有建立exe的IAT。相当于:太早了。
    最后,我决定让被调试者运行,直到碰到了第一个断点。我在程序入口处,设置了一个自己的断点。当第2次中断被触发,CDebugInjector知道目的进程的DLL,都被初始化了(包括Kernel32.dll)。但是,在exe中,还没有代码运行。现在是时候注射DelayLoadProfileDLL.DLL了。
    顺便说一下:断点从哪里来呢?通过定义,一个被调试的win32的进程,在运行之前,会调用DebugBreak(也是int3),在我早期的apispy32代码中,我选用了最初的DebugBreak来做注射。在win2k中,非常不幸,这个DebugBreak在Kernel32.dll初始化之前,被调用,那么,CDebugInjector设置它的断点到exe即将获得控制的地方,那么,kernel32.dll被初始化了。
    在之前,我提到在LoadLibrary调用后,发生的一个断点。这是第3个CDebugInjector要处理的断点,所有的处理不同断点的技巧,可以参考CDebugInjector::HandleException。
    另外一个关于注射dll的有兴趣的问题,就是在那里写LoadLibrary单元,在winnt4.0以后,你可以用VirtualAllocEx来为某个线程申请内存。我采用了这个方法。现在,剩下不能支持VirtualAllocEx的Win9x,针对这个问题,我利用了win9x内存映射文件的一个特殊的特性,这些文件在所有的地址空间都可见。并且,是同一个地址。我简单的利用系统页面文件作为支持,创建了一个小的内存映射文件,写了LoadLibrary根区进去。该根区对于被调试程序,是可见的。更多的详细情况,请看文章首部的连结的CDebugInjector::GetMemoryForLoadLibraryStub。

使用DelayLoadProfile:
    DelayLoadProfile是一个输出结果到标准输出的命令行程序。在命令行提示中,运行DelayLoadProfile,制定目的程序,和它需要的参数,例如:  DelayLoadProfile notepad c:autoexec.bat下面是针对(windows 2000 Release Candidate2)的calc.exe, 运行DelayLoadProfile的结果:
   [d:columncol66debug]delayloadprofile calc
   DelayLoadProfile: SHELL32.dll was called 0 times
   DelayLoadProfile: MSVCRT.dll was called 9 times
   DelayLoadProfile: ADVAPI32.dll was called 0 times
   DelayLoadProfile: GDI32.dll was called 60 times
   DelayLoadProfile: USER32.dll was called 691 times
    我简单的开始calc,然后,立即关闭。注意到,shell32.dll和advapi32.dll都没有调用,这2个dll是最初的calc用来DelayLoad的候选。
    你将回觉得奇怪,为什么calc调用shell32.dll,你没有调用它。如果你针对CALC,调用DumpBin /IMPORTS或者Depends.exe分析,你将看到,CALC从SHELL32.DLL中引入的函数只有ShellAboutW。简单来说,只有你选者CALC的HELP|About Calculator菜单项,才会完全的调用SHELL32.DLL入内存。这个是一个最明显的/DELAYLOAD显示其价值的例子。顺便说,SHELL322.DLL简单的,毫无条件的加载SHLWAPI.DLL和COMCTL32.DLL,并且初始化。
    如果只是因为DelayLoadProfile报告一个dll没有被调用,或者很少调用,你就可以自动的 延迟加载,你要认真的确定,哪一个暗中连结的dll,你要使用/DELAYLOAD。这种情况下,如果由于其他的依赖,你的DLL要被自动的加载和初始化,那么,/DELAYLOAD就没有意义了。平台sdk带的Depends.exe是一个很有用的工具,可以看到一个dll的使用情况。
    在你的测试过程中,你的测试的程序的个数,也是值得考虑的。如果你测试了所有的程序的功能,所有的被引入的dll都包括了。个人认为,我觉得应该尽量缩小初始化时间,这个可能是意味着你只是开始你的程序,然后关闭它。要加快初始化,就依次加载dll。用户都是主观的由启动时间判断你的程序的速度。
    我发现几个DLL可以从/DELAYLOAD处得益。从上所述,SHELL32.DLL是其中一个。另外一个是打印支持的WINSPOOL.DRV。既然很多用户都不经常打印,那么,就是很好的采用者。还有,类似的OLE32.DLL和OL3AUT32.DLL。一个多态的程序,在小容器中,用到COM和OLE,那么,相关的DLL也是可以选用的。例如,WIN2000的CDPLAYER.EXE和OLE32.DLL连接,用到了CreateStreamOnHGlobal函数。但是,在通常的情况下,我没有觉察到这个函数被调用。
    DelayLoadProfile并不是没有它的毛病,当我在很多程序针对IAT,用DelayLoadProfileDLL成功测试后,你可能还会碰到不正确的运行的情况。要完全解决这个问题,就超出了本次讨论的范围。然而,如果你成功解决了其中一个问题,请让我知道。我将在将来的一天更新DelayLoadProfile。  我知道某些引入mfc42.dll和mfc42u.dll的程序会和DelayLoadProfile冲突,于是,我采用了一个方法,在DelayLoadProfileDLL.cpp,有一个IsModuleOKToHook函数,我放了MFC42.DLL,MFC42U.DLL和KERNEL32.DLL进去。(你不能用 /DELAYLOAD 和KERNEL32.DLL关联,因为,是没有作用的)如果一个特别的DLL会出问题,你应该放到IsModuleOKToHook函数中。  我希望DelayLaodProfile会帮助你的程序采用/DELAYLOAD。我以后应该还会有时间去更新一些专业的带骂,并且,我还希望听到你的成功的故事.

你可能感兴趣的:(DelayLoad)