IceSword&Rootkit Unhooker驱动简析
IceSword版本：1.20cn 修订号：061022
----------------------------------------------------
0. 进程
(略)
1. 端口
IS调用IoBuildDeviceIoControlRequest分别向Tcpip.sys所创建的TCP设备对象和UDP设备对象发送IRP，在输出缓冲区中将返回端口/IP/状态/PID的结构数组(DS也是这么搞的,只不过没关联到进程)。
2. 驱动
IS在驱动部分中通过调用NtQuerySystemInformation (SYSTEMMODULEINFORMATION) 来枚举内核模块，这里顺便插一句，在应用部分中，IS调用EnumServiceStatusExA函数把所有已运行模块枚举出来。每当枚举出一个模块时，到注册表中查找其ImagePath值，并与在内核部分列举出来的相应模块对比路径，若路径相同则认为已存在，若不同或没找到则说明是隐藏模块。
3. 注册表
IceSword中注册表处理比较简单，即调用ZwOpenKey,ZwQueryKey,ZwClose,ZwEnumerateKey,ZwEnumerateValueKey来枚举。在调用它们之前都要对其前几十字节进行恢复。
4. 文件系统
这部分算是重点了，也是IS处理得比较巧妙的地方，即采用所谓的Raw FSD I/O来枚举文件和目录。其实就是调用IoAllocateIrp，然后自己填好各个域（先发IRP_MJ_CREATE，再发IRP_MJ_DIRECTORY_CONTROL(IRP_MN_QUERY_DIRECTORY)），最后“直接”发到ntfs.sys/fastfat.sys的DispatchCreate和DispatchDirecotryControl派遣例程，但这里有两个问题需要注意：
a. IS在填充IRP_MJ_DIRECTORY_CONTROL的IRP时，在下层堆栈中设立了SL_RETURN_SINGLE_ENTRY标志，这就直接导致FSD每次只会返回给我们一个FILE_BOTH_DIRECTORY_INFORMATION结构，而不是全部返回（DS是全部返回的）。当IoStatus.Status == STATUS_NO_MORE_FILES时确认枚举完毕。
b. IS是有办法直接定位到上面说的派遣例程的地址的（通过特征搜索），人家也没直接调用IoCallDriver，而是直接call过去的，并且会变态的不停恢复派遣例程的前几十个字节，所以你用什么FSD dispatch routine table HOOK，什么FSD HOOK都白扯。
RkU版本：3.30.150.400
------------------------------------------------
0. 进程
(略)
1. 驱动
"Hidden drivers detection
Detection of drivers hidden from Windows API
combines four different methods of detection and including special five (c) Stealth Walker technology
and six (c) KMSE - Kernel Memory Scanning Engine" ---- RkU
正如其在帮助文档中所说的那样，RkU确实费了一定量代码在驱动枚举模块上，分析时差点被它搞疯，还是分条列举吧：
a. 遍历IoDriverObjectType对象类型的类型链表（POBJECT_TYPE->TypeList），这样可以获得所有DRIVER类型的对象体信息，也即DRIVER_OBJECT结构。然后取出:PDRIVER_OBJECT->DeviceObject，再遍历DeviceObject->AttachedDevice，得到相应DRIVEROBJECT信息，这些东西凡是不重复的统统放入输出缓冲区。
b. 遍历IoDeviceObjectType对象类型的类型链表，思路同上。
当然a和b成功实现枚举的前提是NtGlobalFlags变量设置了Maintain type list标志，否则输出缓冲区什么也没有。
c. 先调用ZwOpenDirectoryObject打开目录对象获得句柄，然后调用ObReferenceObjectByHandle获得目录对象的指针（其结构为OBJECT_DIRECTORY），
