暴力搜索内存空间获得Api的线性地址

暴力搜索内存空间获得 Api 的线性地址

转：

下载本节例子程序和源代码 (4.43 KB)

暴力？怕怕……呵呵，其实这里的“暴力”只是一个形象的比喻。首先说明，本文也是老掉牙的东东了，如果你已经懂得在内存中搜索 Api 的技术，那就不要浪费时间在这篇文章上了。但如果你还是一名初学者，那么看看本文，应该还是有点帮助的。

首先我们来看看为什么要在内存中搜索 Api 的线性地址。我们知道，一个 PE 文件在编译和连接成功后，会有一个 import table ，当需要执行 Api 的时候，会先在 import table 中得到 Api 的地址，然后调用它。这在一般的情况下是足以应付要求的了，可是当有病毒插入宿主的时候，情况就不同了——病毒是在 PE 文件编译好之后才插入的，它本身没有 import table ，那么要如何得到 Api 的地址呢？我们首先知道，任何一个 Dll ，都可以用 LoadLibraryA 来装入，然后通过 GetProcAddress 来取得这个 Dll 中的函数的地址。但是，这里就有个蛋生鸡还是鸡生蛋的问题了——我们能够通过 LoadLibraryA 和 GetProcAddress 来获得别的 Api 的地址，但是我们如何能够获得这两个 Api 的地址呢？现在比较通用的技术是在整个 4GB 的内存空间中暴力搜索 Kernel32.dll 的基地址，然后从 Kernel32.dll 的 export table 中取得 LoadLibraryA 和 GetProcAddress 的地址。有了这两个 Api ，我们就可以导入别的 Dll ，然后进一步得到那个 Dll 中的函数的线性地址了。

不难吧？不过你或许会有个疑问：为什么能够从 4GB 的内存中得到 Kernel32.dll 的基地址呢？其实是这样的，Dll 有一个非常特殊的特性：当有别的程序调用它的时候，它的文件映象就会动态地映射到调用进程的内存地址空间。一般情况下，一个程序在运行的时候， Kernel32.dll 这个 Dll 都会被映射到该程序的内存地址空间，成为它的一部分——这样一来，我们不就可以在宿主的内存地址空间中搜索到 Kernel32.dll 的基地址了吗？

很好，相信你已经看明白了。Let’s go on!

众所周知，Kernel32.dll 也是一个 PE 文件，我们在内存中搜索它的时候，只需要按照判断 PE 文件的方法来执行就 OK 了。值得注意的是，在不同的操作系统下，Kernel32.dll 的基地址是不同的，例如，98 下它是 BFF70000h ， 2K 为 77E80000h ， XP 为 77E60000h 。由于它们都在 70000000h 以上，所以为了加速搜索，我们可以就从 70000000h 开始，或者是反过来，从栈顶 [esp] 开始，往下递减，减少到 70000000h 为止。当然，如果是一个一个字节地进行搜索，那么速度也太慢了吧？！由于 Dll 一般是以 1M 为边界，所以我们可以用 10000h (64k) 作为跨度，这样可以大大加快搜索速度。

值得补充的是， 4GB 的内存地址并不是完全可读的，如果遇到了不能读的地方，就会产生 GPF （General Protect Fault，一般保护性错误）。幸好 Micro$oft 已经为我们预留了一种办法——可以用 SEH 来解决。不过在实际的试验中，我发现 GPE 还没有真正产生过，所以本文为了尽量简化操作，并没有使用 SEH 技术，如果你觉得有需要的话，请自行参考有关资料。

得到了 Kernel32.dll 的基地址后，我们如何得到它的 export table 呢？如上所述， Kernel32.dll 也是一个 PE 文件，我们完全可以按照处理一般的 PE 文件的方法来获得它的 export table 。在 PE 文件头有一个叫做 DataDirectory 的数据目录，它储存的是 PE 文件的一些重要部分的起始 RVA 和尺寸，目的是使 PE 文件的装入更加快速。 DataDirectory 的第一项就是 export table ，所以我们可以定位到 DataDirectory ，然后读取它的第一个 VirtualAddress ，这样就得到了 export table 的 RVA 。

随后，我们就要在 Kernel32.dll 的 export table 中查找我们感兴趣的 Api 的地址。这里涉及到比较繁琐的 PE 文件操作，我就不具体进行分析了，请读者自行参考 Iczelion 的 PE 格式教程的 export table 部分。下面我只具体谈谈如何通过函数名字获取函数地址：

1、定位到 PE Header。
2、从数据目录读取引出表的虚拟地址。
3、定位引出表获取名字数目( NumberOfNames )。
4、并行遍历 AddressOfNames 和 AddressOfNameOrdinals 指向的数组匹配名字。如果在 AddressOfNames 指向的数组中找到匹配名字，就从 AddressOfNameOrdinals 指向的数组中提取索引值。例如，若发现匹配名字的 RVA 存放在 AddressOfNames 数组的第 12 个元素，那就提取 AddressOfNameOrdinals 数组的第 12 个元素作为索引值。如果遍历完 NumberOfNames 个元素，说明当前模块没有所要的名字。
5、从 AddressOfNameOrdinals 数组提取的数值作为 AddressOfFunctions 数组的索引。也就是说，如果值是 7 ，就必须读取 AddressOfFunctions 数组的第 7 个元素，此值就是所要函数的RVA。

具体到我们的病毒中，有一条公式可以用：

API’s Address = ( API’s Ordinal * 4 ) + AddressOfFunctions’ VA + Kernel32 imagebase

注意上面的 Kernel32 imagebase ，这个是 Kernel32.dll 的基地址，为什么要加上它呢？很简单，因为我们的病毒是附属在宿主上的，没有它的话，偏移量就不对啦。（注意了，实际上在很多地方都要加上这个偏移）

不会很难吧？至少我觉得这已经是很初级的了。回想一下我的另外一篇教程《为PE文件添加新节显示启动信息》，在那里我使用的技术是用硬编码来调用 Api ，这种方法有个很大的缺陷——在不同版本的 Windows 下，Api 地址的硬编码不可能相同。看了本文后，相信你就可以轻松地给自己的病毒加上暴力搜索 Api 的线性地址的功能了——这样一来，你的病毒就可以在各个版本的 Windows 下运行了。呵呵，是不是很 cooooool 呢？

好了，我相信我已经把基本的概念讲清楚了，下面给出示范代码。如果你在实践中遇到了什么困难，欢迎给我来信。lcother@163.net

Are you ready? Let’s rock!

点击复制内容点击运行代码