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），然后开始枚举：    
  I. 先从HashBuckets数组中取得索引为0的对象目录项指针
  II. 判断是否为0，若为0则取下一项。
  III. 若不为0，取得POBJECT_DIRECTORY_ENTRY->Object，即对象体。然后根据对象头Object_Header中的类型域判断是否是IoDriverObjectType或IoDeviceObjectType，按照a，b的方式分别处理。若都不是则判断是否是“目录”类型，若是则递归枚举。否则，从POBJECT_DIRECTORY_ENTRY->ChainLink中取下一项继续遍历。
 
d. 通过DRIVER_OBJECT.DriverSection（即PsLoadedModuleList链表）枚举驱动模块。
 
   好了，已经说了4项了，至于最后的"special five (c) Stealth Walker technology and six (c) KMSE"，其实就是从内核地址空间0x80000000-0xffff0000之间暴力搜PE映像，然后综合某些条件来判断是否驱动的PE映象，变态吧？？？

2. Disk Low-Level Scanning
   调用IoBuildAsynchronousFsdRequest创建一个主功能码为IRP_MJ_READ的IRP发到下层卷管理器驱动ftdisk.sys读磁盘扇区信息，这里是绕过了FSD的。

对于IS或者DS::
inline hook ObOpenObjectByName
禁止打开ntos*.exe文件
和已经加载的FSD系统和Tcpip.sys.
另外为了防止ObCreateObject大法式打开文件在IRP_MJ_CREATE中也做处理～

对于那个RKU那个玩意，直接Zero掉DriverObject和DeviceObject,并断开那些链表。
最后就是KMSE,用ShadowWalker过滤个读比较简单～

引用第1楼killvxk于2007-04-30 10:22发表的“”:
对于IS或者DS::
inline hook ObOpenObjectByName
禁止打开ntos*.exe文件
和已经加载的FSD系统和Tcpip.sys.
另外为了防止ObCreateObject大法式打开文件在IRP_MJ_CREATE中也做处理～
.......

邪恶。。。

还有谁？～
直接Disk的那个也可以过滤～哼哼哈嘿～
用更邪恶的～

killvxk是一贯走邪恶路线啊,哈哈,俺还是更喜欢做得神不知鬼不觉,装死:)

disk low-level i/o bypassing做好的话什么winhex,filereg,rku,rootkitrevealer...统统拿下

disk low i/o 可以完全不走Windows的驱动体系~

io port读硬盘
试了效果还不错
只是不通用....

自然不是io port,而是另外的方法~

再给说说贝....

分析的真好,原理讲的真清楚.拜一个.

不直接IO的话,你少不了要发IRP的或其他数据包的,不管你发给谁,难免不给HOOK,困难啊......

引用第1楼killvxk于2007-04-30 10:22发表的“”:
对于IS或者DS::
inline hook ObOpenObjectByName
禁止打开ntos*.exe文件
和已经加载的FSD系统和Tcpip.sys.
另外为了防止ObCreateObject大法式打开文件在IRP_MJ_CREATE中也做处理～
.......

DS使用内建的文件系统,来读写所有系统文件,应该不受HOOK影响的.

引用第12楼wowocock于2007-05-07 12:58发表的“”:

DS使用内建的文件系统,来读写所有系统文件,应该不受HOOK影响的.

改下文件系统名称，你内建能行么？？
识别不了吧～～哈哈～～

改下文件系统名称？？什么意思？？我们实现自己的MINI OS来处理系统，除非你用自己的文件系统，如果是标准的文件系统应该没问题的。当然目前公开的DS版本由于基本垃圾，就没什么好说的了。。。。

引用第14楼wowocock于2007-05-07 14:54发表的“”:
改下文件系统名称？？什么意思？？我们实现自己的MINI OS来处理系统，除非你用自己的文件系统，如果是标准的文件系统应该没问题的。当然目前公开的DS版本由于基本垃圾，就没什么好说的了。。。。

老v的意思是把文件系统的标识改掉.hehe

还是想知道不走驱动体系的做法,哪位給说说呗....

MINIOS恐怖.

楼上的几位真是少见的BT行为
俺来凑凑热闹学学习....

Share your old stuff, keep your good stuff.