摘要（转自网络）：
一、从PEB的Ldr链中消失
引用内容
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 \
+0x02c BaseDllName : _UNICODE_STRING \
......//省略部分内容
随便取一个链表进行遍历，根据DllBase找到自己的DLL之后，从三个链中RemoveEntryList就可以了，这样所有使用PEB->Ldr结构来枚举DLL链表的就无法找到了。
由于大部分ARK对隐藏DLL的查找并不是很重视(比如
RKU,Gmer,XueTr,Atool,NIAP)，因此该方法就可以bypass很多ARK了，还是有一定市场的~
但对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也麻烦啊~~
http://bbs.pediy.com/archive/index.php?t-125571.html http://lwglucky.blog.51cto.com/1228348/282331
相关推荐：
loading