终于比IceSword底层了

    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任重道远啊。

 

【作者: zzzevazzz】

ftdisk是位于ntfs这类filesystem以下..disk这类storage driver以上的一个value added的驱动程序
他在partmgr的帮助下完成一下value added的功能
比如disk mirror等等
至于ftdisk跟disk的联系跟filesystem的联系都不是使用attach的方式完成的...

跟filesystem的联系是通过vpb来完成的
跟disk这是通过io control传递device object的指针完成的

发送到ftdisk的fdo的irp大部分是io control
而发送到ftdisk的pdo的irp则几乎都是read write

系统引导以后..disk.sys被加载..成功以后windows向其发送一个query bus relationship的irp...这个irp首先到达的驱动不是disk.sys而是作为disk的class的upperfilter加载的驱动...partmgr.sys

partmgr.sys在这个irp上设置一个完成routine然后传递下去...disk会为其每一个分区创建一个pdo..

irp完成的时候..partmgr.sys的完成routine调用..对irp作进一步的处理

他解析返回的device relation结构
对于里面返回的每一个device object..如果是以前没有的现在新出现了..则构造一个volume arrival的iocontrol发送到ftdisk.
如果是以前有的而现在却没有了则发送一个volume removal到ftdisk
完成这些操作了以后ftdisk设置device relation的count成员为0...这样windows并不认为disk返回了很多pdo..以至于windows并不发送诸如start stop这类pnp的irp到disk为每个分区创建的pdo..当然这个工作是有人来完成的..partmgr会发送这些irp到disk去
要验证这个说法很简单..构造一个query bus relation发送到disk.sys就能看到pdo.而发送到partmgr.sys就什么都看不到
windows也不承认disk创建的设备是pdo.因为windows会为每个pdo创建device node.而这些设备并没有对应的device node

ftdisk接受到用disk本身的pdo跟disk创建的分区的pdo作为input产生的volume arrival的时候就创建一个pdo.并且保持这两个指针.这个新创建得pdo是一个FILE_DEVICE_DISK类型的pdo.windows在IoCreateDevice的检查这种类型.为其创建一个vpb结构.并关联上去.同时ftdisk为这个新创建的pdo注册一个特别的device interface...系统里面的mountmgr.sys在这个device interface上注册了一个notification..mountmgr.sys得到运行.为这个pdo分配一个盘符.并创建符号连接/dosdevices/c:这样的到ftdisk创建的pdo上...

在第一次访问这个新创建的pdo的时候.比如某程序要读取c:/boot.txt...windows解析这个名字发现c:是一个符号链接.重定向到ftdisk的pdo上.再检查这个pdo.发现附加得有vpb.再检查vpb发现没有filesystem mount在上面.于是通知各个系统里面注册了得filesystem开始尝试mount这个新的volume.mount成功以后修改vpb的一个指针指向filesystem在mount过程中为这个即将要使用的新分区所创建的一个device上面.这样就通过vpb把filesystem跟ftdisk连接到了一起.

大致的情况就是如此.其中disk.sys是有源代码的.fastfat也是有源代码的.