【原创】A了Stuxnet的加载DLL代码--从内存中加载某个DLL

Stuxnet出来很久很久了，之前看过分析文档，觉得它的加载DLL的方式比较有意思，一直没有时间来整，近段时间比较空闲，于是就有了这篇文章

首先，Stuxnet加载DLL的方式，不是传统的PE LOADER，而是将一片内容重新映射，这样做的效果就是，映射过后，这个DLL没有出现在模块列表中，但是可以GetProcAddress获得DLL的导出函数，Stuxnet调用15号导出函数就是这么干的。

Stuxnet的做法如下：
HOOK了6个ntdll的函数，分别为：

这6个函数在LoadLibray执行中调用。
在分析6个HOOK函数时，首先要知道的是：
ZwCreateSection后MapViewOfFile，不ZwClose，直接UnMapViewOfFile，那么第二次Map的时候，返回的就是上次映射的内存，我觉得这就是Stuxnet这种调用方式的核心。

在调试Stuxnet过程中，依次对这几个函数下断点，可以发现LoadLibraryW有这样的执行顺序：
1.查找文件（ZwQueryAttributesFile）
2.打开文件（ZwOpenFile）
3.创建Section（ZwCreateSection）
4.填充某些信息（ZwQuerySection）
5.关闭文件（ZwClose）
6.映射内存（ZwMapViewOfSection）
7.关闭section（ZwClose）

HOOK上面这些函数，Stuxnet还准备了：一个假的文件句柄，一个没有Close的Section句柄，以及QuerySection需要的数据

Stuxnet HOOK写得不错，直接把一段Shellcode考到NTDLL中，统一了HOOK的入口，在入口中再判断，跳转到对应的HOOK流程，如下：

首先是 ZwQueryAttributesFile
执行流程很明了，判断文件名，如果是的话，直接FileInformation->FileAttributes=0x80;
否则，调用int 2e，执行原来的流程

ZwOpenFile
同理，判断是否是要打开的文件，如果是，则返回假文件句柄

ZwCreateSection
首先，判断文件句柄是不是假文件句柄，如果是的话，返回之前没有Close的Section句柄

ZwQuerySection
判断Size是不是0x30，不是的话，返回0C000000Dh，如果section句柄是指定的句柄，是的话，将内存中的PE头相关信息复制到对应的参数

ZwMapViewOfSection
如果是指定section句柄，则修改内存属性为PAGE_EXECUTE_WRITECOPY，接着调用原来函数，再一次判断section句柄，如果匹配，则修正重定位表（测试的时候，忽略了重定位，结果各种加载不上。。。）

最后就是ZwClose
判断是不是文件句柄，如果是的话，直接返回SUCCESS，判断是不是section句柄，如果是的话，将保存的句柄赋0值，然后调用原来的函数关闭

以上就是HOOK的分析过程，重写的思路可以简化为：
1.将某个DLL文件读到内存中，然后按照内存对齐，映射为某片内存，然后反映射。
2.HOOK 上面6个函数
3.调用LoadLibraryW,参数为一个硬盘中不存在的文件

在重写过程中，我仿造Stuxnet这种统一HOOK入口的方式，碰到一个蛋疼的问题，读取参数读取错误，导致堆栈混乱，为了解决这个问题，我给每个函数都加了一个参数，详细见代码。。:eek::eek:

附件就是一个实例工程和Stuxnet的IDB，代码很粗糙，已知不足如下：
1.UNICODESTRING的比较，我直接写死了
2.修复重定位表时，只考虑了IMAGE_REL_BASED_HIGHLOW
还有N多BUG，等着各路神人拍砖了

最后，这种调用方式，在最后一步调用LoadLibrayW的时候，不能加路径，只能文件名！加路径的话就OVER了！

我不知道之前是否有牛人分析过，此贴意在抛钻引玉，欢迎拍砖。

上传的附件

MyLoadLibrary.rar (657.9 KB)