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