从内存资源中加载DLL.doc

一种保护应用程序的方法 模拟Windows PE加载器，从内存资源中加载DLL 1、前言 目前很多敏感和重要的DLL(Dynamic-link library) 都没有提供静态版本供编译器进行静态连接(.lib文件)，即使提供了静态版本也因为兼容性问题导致无法使用，而只提供DLL版本，并且很多专业软件的授权部分的API，都是单独提供一个DLL来完成，而主模块通过调用DLL中的接口来完成授权功能。虽然这些软件一般都采用了加壳和反调试等保护，但是一旦这些功能失去作用，比如脱壳，反反调试，HOOK API或者干脆写一个仿真的授权DLL（模拟授权DLL的所有导出函数接口），然后仿真的DLL再调用授权DLL,这样所有的输入首先被仿真DLL截获再传递给授权DLL，而授权DLL的输出也首先传递给仿真DLL再传递给主程序，这样就可以轻易的监视二者之间的输入输出之间的关系，从而轻易的截获DLL中的授权信息进行修改再返回给主程序。? 2、目前隐式调用敏感DLL中可能存在的安全隐患 以下通过两个软件的授权DLL来说明这种问题的严重性。如下是两个软件中授权DLL的部分信息，如下图所示： （图１） 通过工具OllyICE可以轻易的看出IoMonitor.exe调用授权DLL(XKeyAPI.DLL)，这样就很容易在调用这些API的地方设置断点，然后判断输入输出的关系，从而达到破解的目的。? （图２） 通过工具OllyICE可以轻易的看出sfeng.DLL中导出了很多函数，其中含义也很明显。GetHDID获取硬盘的ID，GetCpuId获取cpu的ID，WinAntiDebug反调试接口。而这些都是主程序需要调用的，比如：主程序通过GetHDID来获取硬盘编码，以这个硬盘ID的伪码来生成授权码，破解者很容易修改这些接口的输出值或者干脆写一个sfeng.DLL来导出跟目标sfeng.DLL一模一样的导出函数，而主程序却完全不知晓。只要用户有一套授权码就可以让GetHDID不管什么机器都返回一样的值，从而达到任何机器都可以使用同一套授权码。? （图３）? 如上图所示，直接修改DLL中函数GetHDID(RVA地址:0093FF3C开始)的实现，让它直接返回固定的硬盘ID就可以达到一个授权到处使用的目的。其中：”WD-Z=AM9N086529ksaiy”为需要返回的已经授权的硬盘ID,我们直接返回这个值即可。把原来0093FF3C 部分的代码用nop替换掉，添加Call 008FFF60，后面添加字符串”WD-Z=AM9N086529ksaiy”，Call 008FFF60之后，ESP=Call后的返回地址(Call指令的下一行)，也就是字符串”WD-Z=AM9N086529ksaiy”的首地址，然后pop EAX 后，返回值就是字符串的首地址，通过这种简单的修改就可以达到破解的目的，说明这种隐式的调用是非常危险的。? 3、模拟Windows PE加载器，从资源中加载DLL 本文主要介绍将DLL文件进行加密压缩后存放在程序的资源段，然后在程序中读取资源段数据进行解压和解密工作后，从内存中加载这个DLL，然后模拟PE加载器完成DLL的加载过程。本文主要以Visual C++ 6.0为工具进行介绍，其它开发工具实现过程与此类似。? 这样作的好处也很明显，DLL文件存放在主程序的资源段，而且经过了加密压缩处理，破解者很难找到下断点的地方，也不能轻易修改资源DLL，因为只有主程序完成解压和解密工作，完成PE加载工作后此DLL才开始工作。? 我们知道，要显式加载一个DLL，并取得其中导出的函数地址一般是通过如下步骤： (1) 用LoadLibrary加载DLL文件，获得该DLL的模块句柄； (2) 定义一个函数指针类型，并声明一个变量； (3) 用GetProcAddress取得该DLL中目标函数的地址，赋值给函数指针变量； (4) 调用函数指针变量。 这个方法要求DLL文件位于硬盘上面,而我们的DLL现在在内存中。现在假设我们的DLL已经位于内存中，比如通过脱壳、解密或者解压缩得到，能不能不把它写入硬盘文件，而直接从内存加载呢？答案是肯定的，方法就是完成跟Windows PE加载器同样的工作即可。? 加载过程大致包括以下几个部分：? 1、调用API读取DLL资源数据拷贝到内存中? 2、调用解压和解密函数对内存中的DLL进行处理? 3、检查DOS头和PE头判断是否为合法的PE格式? 4、计算加载该DLL所需的虚拟地址空间大小? 5、向操作系统申请指定大小的虚拟地址空间并提交? 6、将DLL数据复制到所分配的虚拟内存块中，注意文件段对齐方式和内存段对齐方式? 7、对每个 DLL文件来说都存在一个重定位节（.rel