DLL中API列表的分析

        大家知道DLL文件是Windows系统中非常重要的文件。很多API函数或者资源都在DLL中。对DLL的分析可以帮助我们加深对系统的了解。特别是如果能够获取DLL中API函数的列表，并扫描学习可以大大提升我们的编程功力。

        我就是在获得了DLL中API函数列表之后才编写出ShowLastError宏；才知道Window Mobile 4.21开始就可以支持“安全字符串处理API”（MSDN中声称WM5才支持。）；查到MD5 API函数提取摘要；使用gx.dll中奇怪的函数名调用游戏API函数，正因为攻占了游戏API我们才拥有了直接攻击显存的能力........

        首先我浏览了PPC中的各个目录，没有找到DLL文件。在EVC的虚拟机中通过显示隐藏文件的功能发现DLL都在\Windows目录下。尝试拷贝一个DLL出来分析失败，系统提示找不到文件。

     使用FindFirstFileW和FindNextFileW在\Windows目录下逐个枚举*.DLL文件获得成功。在PPC 2003中枚举到283个DLL。这里需要注意的是Windows CE系统的WIN32_FIND_DATA 结构和桌面系统不同。我已经在Xarm中声明了。枚举过程中把文件大小也取出，写入文本文件中。这样就得到了全部DLL的文件名和大小列表。

         到这个时候有两条路线研究DLL。
   一条是从文件出发，按PE格式分析文件得到API列表。
   一条是从内存映象出发，也是按PE格式分析。

         从文件路线走：
         有了文件名就尝试使用CopyFileW函数将文件拷贝出来，函数出错。找不到文件。
   尝试用CreateFileW获得文件句柄，函数出错。找不到文件。
   其他文件API也对其无能为力都提示找不到文件。
   使用FindFirstFileW查找coredll.dll文件获得其文件属性发现有FILE_ATTRIBUTE_ROMMODULE属性。
   尝试使用SetFileAttributesW函数修改属性失败，找不到文件。
   因为WIN32_FIND_DATA 结构中有dwOID 参数尝试从结构对象存储出发看能否有突破，依然失败。
   尝试研究虚拟机文件，发现ppc.dess才是真正存储了虚拟机中新增文件的硬盘文件。但是保存一个
   可执行文件后其容量的增量并不和文件相同。而且在这个文件中发现的PE标志不像是PE文件。
   可能是压缩了。这条路线基本失败。

         从内存映象路线走：
   LoadLibraryW得到了DLL的实例句柄，但是我们很快发现这个实例句柄并不是内存地址。
   通过GetModuleInformation函数可以查到DLL的装载地址和入口点等信息。
   直接访问装载地址失败。
   估计是这段内存没有可读属性，尝试使用VirtualProtect修改内存属性失败。（这个函数对写加密病毒非常重要！）
   尝试使用SetKMode进入系统状态访问仍然失败。
   通过VirtualQuery函数查询这段内存发现是PAGE_NOACCESS属性的难怪无法访问。

   看来微软是严防死守不让我们研究DLL！无论文件还是内存映象都严密控制了。
   在春节前一天突然想到一个问题，我们要得到DLL的函数列表关键是分析DLL的输出表。这个
   部分一般在文件的后半部分，系统对这部分是否也控制了呢？

   立即试验！
   发现对于装载在内存中的DLL，系统只将最初的4K设置为PAGE_NOACCESS属性后面的可以自由访问！
   太好了！立即编写程序将从DLL装载位置4K偏移量以后的部分Dump到文本文件中。使用WinHex处理
   这个文本文件，终于得到了我们梦寐以求的API函数列表。后来针对WM6作试验发现同样只有最初4K
   被设置为PAGE_NOACCESS属性后面部分可以访问。


总结：
         这个“DLL中API列表分析”问题前后用了4周才攻克。是我们学习Windows CE / ARM以来第一个重大
难关。不过研究的过程是很快乐的。因为我们不断的尝试新的方法，大大提高了对系统的认识。不断
研究的过程就是不断学习积累的过程，至少我们知道这个办法不行。还有另一些有趣发现。

01.    PPC 2003 中DLL的装载地址是64K对齐的。所有地址的末尾都是0000。
02.    WM 6       中DLL的装载地址是4K对齐的。所有地址末尾都是000。DLL量增加了，密度也增大？
03.    所有的DLL都是顺次排列好的。一个挨一个，有的未加载的就给她空着的。     
04.    ★ 这个最有趣：用FindFirstFileW/FindNextFileW可以得到一个DLL列表。这个列表产生的方式
              恰好是DLL在内存中装载地址从高到低排列的方式。

         同时让我们明白编写程序检测系统中是否存在某个文件时不能使用CreateFileW尝试获得文件的句柄。
而是应该使用FindFirstFileW。否则遇到DLL这样的文件就认为她不存在了。


问题：
01.    为什么FindFirstFileW这样的函数可以找到这些DLL的信息？而其他API函数不行？
02.    为什么FindFirstFileW/FindNextFileW枚举DLL的结果和装载地址有这样的联系？
03.    上述两个函数是否是从类似于文件分配表这样的结构中获得的DLL信息？
04.    如果能够用上述两个函数找到DLL，能否用他们的工作原理取出DLL文件来分析？


后记：
         这篇文章总结了我们攻克“DLL中API列表获取”难关时经历的一些失败教训和有趣发现。可能有更好的办法解决这个问题。如果您知道其他方法或者对这个问题有其他高见欢迎您发邮件，指教！作者感激不尽！


编写时间：22:00:34  2008 年 03 月 15 日  星期六

修改时间：18:13:39  2008 年 03 月 16 日  星期日