【旧文章搬运】再谈隐藏进程中的DLL模块
原文发表于百度空间，2009-09-17
==========================================================================
相当老的话题，大约一年前就写过这个东西了，不过那时候知识比较有限，也不了解内核，因此实现得很粗浅，现在再写一下，权当是对这个老问题的总结吧。
先谈谈正规DLL的隐藏方法，这里说的正规DLL，是指用LoadLibrary以正常方式加载的DLL。
一、从PEB的Ldr链中消失
这个很简单，看雪上NetRoc有一篇关于这个的文章，从分析原理到编程实现，虽然技术不算高深，但是思路非常精彩。来复习一下吧~~
lkd> dt _PEB 7ffdc000 //当前PEB的地址 nt!_PEB ... +0x00c Ldr : 0x001a1e90 _PEB_LDR_DATA //这里指向Ldr结构 lkd> dt _PEB_LDR_DATA 0x001a1e90 //这个结构里有三个链表的表头 nt!_PEB_LDR_DATA +0x000 Length : 0x28 +0x004 Initialized : 0x1 '' +0x008 SsHandle : (null) +0x00c InLoadOrderModuleList : _LIST_ENTRY [ 0x1a1ec0 - 0x1a34f8 ] +0x014 InMemoryOrderModuleList : _LIST_ENTRY [ 0x1a1ec8 - 0x1a3500 ] +0x01c InInitializationOrderModuleList : _LIST_ENTRY [ 0x1a1f28 - 0x1a3508 ] +0x024 EntryInProgress : (null)
这里看到有三个链表，其实三个链表的内容是一样的，但是链表的顺序不一样，分别按加载顺序、内存顺序、初始化顺序排列
也就是说每一个DLL由一个LDR_DATA_TABLE_ENTRY结构描述，但是第一个结构被链入了三个链表。取一个来看看：
lkd> dt _LDR_DATA_TABLE_ENTRY 0x1a34f8 nt!_LDR_DATA_TABLE_ENTRY +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x1a1e9c - 0x1a3450 ] +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x1a1ea4 - 0x1a3458 ] +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x1a1eac - 0x1a3460 ] +0x018 DllBase : 0x20000000 +0x01c EntryPoint : (null) +0x020 SizeOfImage : 0x549000 +0x024 FullDllName : _UNICODE_STRING "C:\WINDOWS\system32\xpsp2res.dll" +0x02c BaseDllName : _UNICODE_STRING "xpsp2res.dll" ......//省略部分内容
随便取一个链表进行遍历，根据DllBase找到自己的DLL之后，从三个链中RemoveEntryList就可以了，这样所有使用PEB->Ldr结构来枚举DLL链表的就无法找到了。
由于大部分ARK对隐藏DLL的查找并不是很重视(比如RKU,Gmer,XueTr,Atool,NIAP)，因此该方法就可以bypass很多ARK了，还是有一定市场的~
但对IceSword是个例外，下面就来说说如何bypass IceSword
二、从VAD树中消失
IceSword在枚举进程模块时使用的是ZwQueryVirtualMemory，查询的InfoClass是MemorySectionName(或者叫MemoryMappedFilenameInformation，值为2)。NtQueryVirtualMemory首先判断Vad->ControlArea->FilePointer是否有效，若有效则调用ObQueryNameString查询此文件对象的名称，最终由文件系统完成此次查询工作。
关于VAD的详细知识，可以参考《JIURL玩玩Win2k内存篇 VAD》，这里不作为重点，知道是平衡二叉树就可以了，树的根结点在EPROCESS中。
lkd> dt _EPROCESS 83f915b8 nt!_EPROCESS ... +0x11c VadRoot : 0x84079c08
该成员是一个MMVAD类型的结构，而成员LeftChild和RightChild分别是该结点的左子结点和右子结点。
lkd> dt _MMVAD 0x84079c08 nt!_MMVAD +0x000 StartingVpn : 0x8e0 +0x004 EndingVpn : 0x8e0 +0x008 Parent : (null) +0x00c LeftChild : 0x843b1128 _MMVAD //左孩子 +0x010 RightChild : 0x840bf4a0 _MMVAD //右孩子 +0x014 u : __unnamed //标志位 +0x018 ControlArea : (null) +0x01c FirstPrototypePte : (null) +0x020 LastContiguousPte : (null) +0x024 u2 : __unnamed
要对目标DLL实施隐藏时，先获取该DLL基址，然后遍历VAD树，根据MMVAD->StartingVpn做匹配(StartingVpn实际上是内存地址的高20位，比如0x7c800000在这里将只显示为0x7c800)找到目标DLL的VAD结构(这里以kernel32.dll为例，其加载地址正为0x7c800000):
lkd> dt _MMVAD 84174a18 nt!_MMVAD +0x000 StartingVpn : 0x7c800 +0x004 EndingVpn : 0x7c91b +0x008 Parent : 0x841223a0 _MMVAD +0x00c LeftChild : 0x84120470 _MMVAD +0x010 RightChild : 0x841a4790 _MMVAD +0x014 u : __unnamed +0x018 ControlArea : 0x876d0b88 _CONTROL_AREA //关键域 +0x01c FirstPrototypePte : 0xe177d6f0 _MMPTE +0x020 LastContiguousPte : 0xfffffffc _MMPTE +0x024 u2 : __unnamed lkd> dt _CONTROL_AREA 0x876d0b88 nt!_CONTROL_AREA ... +0x024 FilePointer : 0x876d0b10 _FILE_OBJECT外//目标在这里
好了，看到FILE_OBJECT了，这时你应该会想到系统是从这里取到的文件名吧，没错，这儿就是我们要动手脚的地方。根据小伟、Sysnap等人的测试，只要把ControlArea->FilePointer->FileName.Buffer填0就可以实现该DLL的隐藏(根据字符串的特性，实际上只需要把第一个字符填0就可以了)，此时ZwQueryVirtualMemory将返回0xC0000039错误，即“指定的路径无效”，自然也就枚举不到了。而且对于那些共享的dll,如系统的ntdll.dll,kernel32.dll或在不同进程中被加载2次或以上的dll，虽然是在不同进程中，但是使用的是同一个共享的ControlArea结构,因此只需要改一个，那么在所有进程中都将实现隐藏，这对于隐藏全局钩子类型的dll显然是非常方便的。
IS是在ZwQueryVirtualMemory查完全无法枚举到DLL时才采用枚举PEB的方法，因此结合前面的Ldr断链法，足以搞定N多ARK了。
我所说的“从VAD树中消失”只是使该VAD的信息从IS的查询结果中消失，而并不是真的摘掉该VAD~~
值得一说的是，Sysnap的Yas Kit在检测隐藏DLL方面也是比较强的，但是对于动了VAD的，似乎也无能为力~
三、抹掉PE特征
有的工具可以直接枚举所有有效内存并检查PE标记来确定是否有隐藏DLL,因此需要把PE特征抹掉来对抗之，方法很简单，把PE头整个填零就可以了。
这种方法主要是作为前两种方法的补充，单独搞是没有意义的。
再来说说非正规方式加载的DLL，怎么个非正规呢？其实就是不用LoadLibrary，自已实现Loader的功能.
实现Loader功能之后，不管你是Load别的DLL，或者DLL自已Load自己(老V的ReloadAndRun同样适用于DLL)，在Load完成后，不会出现在PEB->Ldr链中，它的VAD也不会与FILE_OBJECT发生任何关系，然后再抹掉PE特征，隐藏效果与上面的正规隐藏法相当，甚至要更隐蔽一些~~
再极端一点，DLL也可以完全不要，注入具有相同功能的shellcode然后开线程执行就可以了，只是shellcode写起来麻烦一点而已，写Loader也麻烦啊~~
总之只要能把我们的代码跑起来就OK，DLL隐藏就写到这儿~~
这次发代码出来，要代码请到这里
