强力的文件隐藏手段：绕过 Raw 模式文件系统 I/O Rootkit 检测程序

说明：我第一次翻译技术含量如此高的文章，所以肯定有很多错误、不严谨、不贴切、拗口（例如标题）等等问题，请大家谅解。


强力的文件隐藏手段：绕过 Raw 模式文件系统 I/O Rootkit 检测程序

===================
作者：CardMagic
翻译：FlowerCode(http://www.0ginr.com/bbs)
===================

在读过 Hoglund 的文章之后，我终于决定要写这篇文章。
实际上，在中国有许多聪明的 rootkit/antirootkit 作者有他们自己的有趣的材料，但不幸的是，由于许多原因（商业合同，语言障碍，甚至和某些神秘组织有关），他们不能将这些材料公开。
这篇文章的主要构想在我设计 DarkSpy 时就产生了，但当我完成了总线级文件隐藏程序的编写之后，它被丢弃了。
不过希望这篇文章仍能对这里的某些人有用。:)
好的，让我们进入正题：

1. 基于 Raw I/O 的隐藏文件检测

这种类型的文件检测技术在现代的检测程序中使用非常普遍。例如 DarkSpy/Icesword。
这种检测手段的主要思想是直接发送 I/O 请求包到文件系统，这样检测程序就会获得系统文件的真实信息。
这对于检测挂钩本地函数和文件系统过滤驱动的隐藏方式来说很有效。

此外，DarkSpy 还加入了两个很有效的手段（第二个手段使得 DarkSpy 的文件检测比 Icesword 要好 ^_^）
a)自己实现 IofCallDriver，并直接调用原始的文件系统派发函数，这将使挂钩文件系统函数的隐藏方式失效。
b)在每个I/O操作前从内存恢复整个文件系统文件映像，这可以对抗对文件系统函数进行 Inline 型代码修改的隐藏方式


2. 绕过这种检测技术的原理：

这里我们只讨论真正的文件隐藏程序（不包括使用文件流的那些东西），我们还会描述绕过 DarkSpy 的原理，因为 DarkSpy 是非常典型的基于 RAW I/O 的文件检测程序。首先让我们来看看DarkSpy文件检测的基本流程。


   -----------------                                           ---------------------
   |   DarkSpy           |  <1> ---->恢复          | 文件系统映像       |
   -----------------  <2>----->调用--->  |  派发代码                |
                                       <3><-----返回----- |-------------------|



从上面的图我们可以看出，要想在文件系统里做手脚几乎是不可能的，因为 DarkSpy 已经恢复了整个映像，甚至不依赖系统函数直接调用了派发代码。
现在开始改变我们的视角然后动点脑筋，我们能否在除了文件系统以外的地方拦截 I/O 处理呢？
答案是肯定的，因为文件系统会调用许多系统函数。
但我们必须找到一个恰当的调用，它要能够有机会接触 I/O 内容。哪个最好呢？
也许你会首先想到 IofCallDriver……但不幸的是 DarkSpy 已经在内部实现了它，因为 IofCallDriver 是非常容易实现的 :)

所以我们必须另外选择一个，它必须：
a) 很难自己实现
b) 将会被文件系统调用
c) 可以接触到I/O内容

究竟哪一个是最好的呢？
没错，你说对了，是 IofCompleteRequest。好吧……这是我们的想法……
通过 IofCompleteRequest 代码修改，检查我们是否被文件系统调用，如果是，我们将过滤 I/O 内容。这样，我们将可以完全绕过所有现代的基于 RAW I/O 的文件检测程序。

3. 主要代码：

参见——

http://www.rootkit.com/vault/cardmagic/hidefile.c

再加上hidefile.c的注释：
//
//文件隐藏模块
//由 CardMagic 编写
//Email : sunmy1@sina.com
//MSN: onlyonejazz at hotmail.com
//

//
//代码并不完整，因为我只是将它从一个大工程里提取出来。
//它只包括了和我的文章有关的一些材料。
//你必须把这些代码加入到你自己的驱动代码里。
//
//

显然 CardMagic 得要谈谈这个神秘的大工程了……莫非是DarkSpy Ultimate Edition？

引用第1楼123456789012于2007-04-09 21:20发表的“”:
再加上hidefile.c的注释：
//
//文件隐藏模块
//由 CardMagic 编写
//Email : sunmy1@sina.com
.......

XX backdoor

中国人写的还要翻译。。。。。

引用第3楼WQXNETQIQI于2007-04-09 22:02发表的“”:
中国人写的还要翻译。。。。。

但CardMagic说没有中文版……

这个也翻译,晕......

引用第5楼wowocock于2007-04-10 12:14发表的“”:
这个也翻译,晕......

主要当时没写中文版的，flowercode这个同志很好，很热心，说要翻译，于是就翻译了。
在这还要再表达我对他的谢意：谢谢你，honey
其实这个文章的主要思想是进行io后置处理，前端处理的文章已经很多了。
利用这个code的原理稍加改动，可以在所有的detector下隐藏。包括filereg（但可能要动点脑筋了:) ).
另外，iocompleterequest具体处理上与别的隐藏处理逻辑少有点不同，一个逻辑分支处理不慎都会造成无法意料的bug.具体细节可以参考下source ：） 可能对某些朋友有用吧~最少它不加改动就可以过目前所有
raw io的file detector.

现在大家都自己实现FS了,你的HOOK得往下移,而且有家伙号称可以不用系统的FS,DISK DRIVER,来直接访问磁盘,不过好象还是没自己实现MINI PORT的DRIVER,不过目前即使在DISK.SYS这层的HOOK已经不够了,所以HOOK还得下移......

晕倒,最后是不是要在bios中想办法才行?

推荐B梦的FILELIB+DIRECT DISK,确实不错
DirectDisk V1.0

  DirectDisk提供了一组磁盘读写接口，通过调用这组接口，可以绕过WINDOWS内核的文件系统驱动和磁盘驱动，读写到
真实磁盘上的扇区内容。
  开发DirectDisk的目的是为了和我的FileLib库配合起来，这样通过FileLib和DirectDisk，就可以完全取代WINDOWS的
文件系统驱动和磁盘驱动的功能，使你不经过这些驱动也可以读写物理磁盘上的文件，完成创建目录和删除文件等操作，
此外DirectDisk也可以为我的VvolDisk虚拟磁盘提供内核层的磁盘读写功能，如果用户是拿一块物理磁盘区域做为虚拟
磁盘，那么VvolDisk就可以不再走上层的文件系统和磁盘驱动来读写磁盘了，至少这样速度上可以提升很多。：）（
VvolDisk是我的另一个产品，提供本地和网络虚拟磁盘功能，是为我的网络存储解决方案而开发的，我会在另一篇文章中
说明）。

  正常的文件读写简要流程：
  1.用户调用Win32 API ReadFile,WriteFile进行文件读写(如 ReadFile("c:\txt"...))
  2.读写请求被下发到内核中的文件系统驱动(fastfat.sys,ntfs.sys等)，文件系统驱动进行文件系统解析，然后向磁盘
    驱动发送磁盘读写请求
  3.磁盘驱动(Disk.sys)从真实物理设备中读入或者写入扇区数据

  通过FileLib+DirectDisk文件读写简要流程：
  1.用户调用FileLib提供的接口ReadFile,WriteFile进行文件读写(如 ReadFile("c:\txt"...))
  2.请求被发送到FileLib中，FileLib负责进行文件系统解析，然后向内核中的DirectDisk发送磁盘读写请求
  3.DirectDisk从真实物理设备中读入或者写入扇区数据
  (通过FileLib+DirectDisk读写文件是保证不会经过fastfat.sys,ntfs.sys,disk.sys这类驱动)

  正常的磁盘读写简要流程：
  1.用户调用Win32 API ReadFile,WriteFile进行磁盘读写(如 ReadFile("\\\\.\\PhysicalDrive0"...))
  2.读写请求被下发到内核中的文件系统驱动(fastfat.sys,ntfs.sys等)，文件系统驱动转发这些请求到磁盘驱动中处理
  3.磁盘驱动(Disk.sys)从真实物理设备中读入或者写入扇区数据

  通过DirectDisk磁盘读写简要流程：
  1.用户调用DirectDisk提供的接口ReadDisk进行磁盘读写(如 ReadDisk(0),0对应PhysicalDrive0)
  2.读写请求被下发到内核中的DirectDisk驱动，DirectDisk负责从真实物理设备中读入或者写入扇区数据
  (通过DirectDisk读写文件是保证不会经过fastfat.sys,ntfs.sys,disk.sys这类驱动)


  本来我是打算将DirectDisk免费公开给所有开发人员使用的，不过经过好友的劝说，我暂时放弃了这样的想法。因为
FileLib+DirectDisk组合起来的威力太强大了。试想一下，如果某个病毒通过该接口进行感染或者破坏，所有基于文件
过滤和磁盘过滤的病毒监控都是没有办法监控到的。FileLib+DirectDisk，几乎可以破解目前任何文件过滤保护和磁盘
过滤保护类的产品，会对世面上所有的还原卡，还原产品，目录加密，磁盘加密类产品造成危害。：（

  此外还有很多群里的朋友问题我DirectDisk的原理，不过现在暂时还不能公开，总之DirectDisk决不是通过内核直接
磁盘I/O的方式读写磁盘的，那样的东东我几年前写过，通用性太差了，会和WINDOWS本身的磁盘驱动产生冲突，而且不
能兼容其它的磁盘模式(比如AHCI模式)，DirectDisk兼容性很强，不会和WINDOWS的磁盘读写冲突，而且兼容所有模式。

引用第9楼wowocock于2007-04-10 13:35发表的“”:
推荐B梦的FILELIB+DIRECT DISK,确实不错
DirectDisk V1.0

  DirectDisk提供了一组磁盘读写接口，通过调用这组接口，可以绕过WINDOWS内核的文件系统驱动和磁盘驱动，读写到
真实磁盘上的扇区内容。
.......

的确是个好东西.但我们只能"望梅止渴":"本来我是打算将DirectDisk免费公开给所有开发人员使用的，不过经过好友的劝说，我暂时放弃了这样的想法".

......
open时代结束了～

最邪恶的东西还是把linux的内核在windows内核里面跑起来，然后我就不说了吧，什么NTFS之类都可以了～自己有一套新的磁盘驱动来干坏事啦～

晕倒..老v真能想象,不过要有实用价值吧?这样弄太复杂了.

不是不可能,但工作量...

如果要实现你的想象,应该不会是Window的一个子系统,否则你没法直接i/o的吧

DirectDisk的用处和危害说得离谱了点，直接IO DISK这个东东的应用还是稳定性和速度上的问题

稳定性很好非常成熟的东东实际我们早就有了

只是速度比MS的稍微慢了一点，，考虑用户感受，还是改用了其他小技巧来突破那些流氓的小孩级XX

那个实现起来很容易，主要是看你怎么把Windows和Linux结合起来啦～嘿嘿

引用第14楼WQXNETQIQI于2007-04-10 15:58发表的“”:
DirectDisk的用处和危害说得离谱了点，直接IO DISK这个东东的应用还是稳定性和速度上的问题

稳定性很好非常成熟的东东实际我们早就有了

只是速度比MS的稍微慢了一点，，考虑用户感受，还是改用了其他小技巧来突破那些流氓的小孩级XX

Filelib+DirectDisk没有Binary和Source，更没有一个理论详细说明 显得有些苍白无力～

引用第14楼WQXNETQIQI于2007-04-10 15:58发表的“”:
DirectDisk的用处和危害说得离谱了点，直接IO DISK这个东东的应用还是稳定性和速度上的问题

稳定性很好非常成熟的东东实际我们早就有了

只是速度比MS的稍微慢了一点，，考虑用户感受，还是改用了其他小技巧来突破那些流氓的小孩级XX

不是吹牛吧?放个 tester出来看看

FileLib+DirectDisk
===============
没有source就算了，binary也没有，那谁不会说啊？

我也开发了一个超级无敌Rootkit，可以让目前所有AntiRootkit下岗，可惜因为保密需要，source和binary无法公开。有人相信我说的话吗？哈哈~~~~~~~~~~~~~~

引用第18楼slwqw于2007-04-10 18:18发表的“”:
FileLib+DirectDisk
===============
没有source就算了，binary也没有，那谁不会说啊？

我也开发了一个超级无敌Rootkit，可以让目前所有AntiRootkit下岗，可惜因为保密需要，source和binary无法公开。有人相信我说的话吗？哈哈~~~~~~~~~~~~~~

别人不开原,我们也没办法,拿个BIN先顶着吧.