终于比IceSword底层了

{此文转自 zzzevazzz，自己MARK一下，看官请注意原作}                                  

    IceSword有反调试功能，搞的我想研究一下它的原理都举步维艰。不过同样是pjf的作品FileMgr却没有设防，正好拿来开刀。
    经过IrpMon、IrpTrace、WinObj、NTObjects、WinDbg等工具的左右夹击，终于发现FileMgr通过直接IoCallDriver(/Device/Ftdisk设备对象, 自定义的Irp);来绕过大部分的文件过滤驱动。然后再研究IceSword，果然是一样的原理。它和我准备用来实现knlls的原理一样，这种"英雄所见略同"既是偶然也是必然。虽说IceSword绕过系统API自己实现了大量的操作，但文件系统实在复杂，在Ftdisk之下就要考虑NTFS和FAT32之类的文件系统格式了，绕过系统支持不同的文件系统是不现实的，所以在磁盘类驱动层必然要把读写文件的控制权交给系统。
    不过，FileMgr和IceSword还是棋差一招，调用IoCallDriver会经过Io管理器，由Io管理器根据DRIVER_OBJECT的MajorFunction[]来调用相应的Dispatch例程，只要修改MajorFunction[]就能hook发往Ftdisk的Irp了。我本以为IceSword会直接找到并调用Ftdisk各个Dispatch例程，但在IceSword启动的前或后加载我的钩子都能起效，可见IceSword还是用到了"不安全"的MajorFunction[]。 
    知道原理是一回事，"虎口拔牙"又是另一回事。文件系统相关IRP太复杂了，实时性要求又高，在没完全搞清楚之前还是不要动手，先写出knlls再说。

（11月30日添加）
    今天又研究了一下，发现IceSword调用Ftdisk的Dispatch只是表面现象，Ftdisk上的钩子没有勾到什么有价值的数据。改成挂钩/FileSystem/NTFS，这才获得了所有访问文件系统的操作。如果是FAT32则需要挂钩/FileSystem/FastFat。
    我还没搞清除Ftdisk和ntfs/FastFat之间究竟是怎么个关系，Ftdisk应该是在具体的文件系统驱动之上提供统一的"接口"才对，但实际上它们既不以NextDevice联系，也不以AttachedTo/AttachedDevice联系，Hook到的数据完全搞不清楚其含义，于是我郁闷了。难道是通过DeviceNode？
    刚刚开始探索文件系统结构，就已经找不着北了。看来写knlls任重道远啊。