某要好的同学正在做毕业设计，需要隐藏文件并指定要求绕过 Icesword.exe 最新版，
以前我写过一篇关于通过 inline hook IofCompleteRequest 这个函数来实现文
件隐藏，这个函数几乎被每个驱动调用，表示用于在驱动中指定 IRP 的所有操作全部完
成，并向 i/O 管理器返回指定的IRP 报文。但是 Icesword.exe1.22最新版（八卦一下：其
实 pif 去了 360 后，早就已经不更新。但是我个人仍然认为当时 Icesword（最早时间好像
是 2003 年开发）用到很多先进的技术，足以媲美哪些国外最好的反rootikit工具，应该是
国内 Anti-Rootkit 工具的开山鼻祖，而冰刃成了很多病毒”攻击”和”学习”的目标（谁
能过 IceSword,谁就NB）,真正的内核牛人！）会对IofCompleteRequest被挂钩的汇编指令
进行循环恢复(防止被再次 HOOK)，因此这种方法已无法绕过 Icesword1.22。但是同学的执
着让我感到很无奈，没办法，那只有按他的要求去做。
去年早些时间自己曾经写了一个浏览文件的工具，采取几乎和冰刃一样的方式，通过
自己构造一个 IRP，然后实现一个 IoCallDriver 发送查询文件的 IRP(主功能
号:IRP_MJ_DIRECTORY_CONTROL, 此功能号:IRP_MN_QUERY_DIRECTORY)到文件系统设备
(L”\\FileSystem\\NTFS”或者 L”\\FileSystem\\fastfat”)。但是通过逆向分析
IceSword 后发现其浏览文件方式与我采取的方法有所不同，首先它对
NtQuerySystemInformation函数（用来查询NTFS.sys/fat32.sys模块的基址）起始的0x30
个字节进行恢复（防止使用的函数被别人 HOOK 过，PJF 真是仔细呀）,然后通过 PE 文件的
格式计算出 fsd的 dispatch routine的 RVA,然后+前面获取正确的NtfsModuleBase，修复
fsd dispatch routine的起始部分指令防止被 fsd inline Hook。
检查文件系统驱动对象名称是否正确、以上步骤全部执行后，然后将构造好的查询文件的
IRP 发向至（通过目录查询、卷分区查询等都是以文件形式打开,用文件句柄来获取的内核
文件对象）FilE_OBJECT 指向的设备对象。这样一来 fsd hook、fsd inline hook、驱动对
象劫持、常见的IRP Hook(IoCallDriver、IoCompleteRequest)等等的方式隐藏文件都无法
绕过IceSword1.22。网上某大牛提出的一种方法来隐藏文件绕过冰刃1.22，由于icesword
毕竟还是基于os 开发的东西，它转去执行查询文件的fsd dispatch routine（这里以NTFS
文件系统为例，由于本人的操作系统只使用了NTFS文件系统）其实转去只能够是Ntfs查询
文件的函数，使用windbg查看 NTFS文件系统驱动例程如下图1：
这里可以看到执行 IRP_MJ_DEVICE_CONTROL 例程起始起始是调用
Ntfs!NtfsFsdDirectoryControl函数，下面反汇编该函数：
u Ntfs!NtfsFsdDirectoryControl l64
f98c92c3 684c010000 push 14Ch
f98c92c8 68c8988bf9 push offset Ntfs!`string'+0x384 (f98b98c8)
f98c92cd e8ce80fdff call Ntfs!_SEH_prolog (f98a13a0)
f98c92d2 33ff xor edi,edi
f98c92d4 897de4 mov dword ptr [ebp-1Ch],edi
f98c92d7 ff151c8b8bf9 call dword ptr [Ntfs!_imp__KeEnterCriticalRegion
(f98b8b1c)]
f98c92dd 6a01 push 1
f98c92df 6a01 push 1
f98c92e1 8d45b4 lea eax,[ebp-4Ch]
f98c92e4 50 push eax
f98c92e5 e82e82fdff call Ntfs!NtfsInitializeTopLevelIrp (f98a1518)
f98c92ea 8bf0 mov esi,eax
f98c92ec 8975e0 mov dword ptr [ebp-20h],esi
f98c92ef 33db xor ebx,ebx
f98c92f1 895dfc mov dword ptr [ebp-4],ebx |
