WIN2K-NT-XP-监视文件系统过滤驱动程序的驱动程序原代码

WIN2000下利用汇编做文件过滤驱动程序新办法： 技术难题： [1]编程环境 1）首先安装VC++6.0 2）安装TASM5.0 3）安装2K DDK 4）安装2k IFS DDK [2]如何利用WIN2K DDK/IFSDDK环境制作SYS驱动程序 1）制作ASM驱动程序之前，首先制作一个最简单的Kernel模式驱动程序。 这个程序由三个文件组成： makefile,sources,wap32.c内容如下： #makefile文件: !INCLUDE $(NTMAKEENV)\makefile.def #sources文件： DRIVERTYPE=DRIVER TARGETNAME=Wap32 TARGETTYPE=DRIVER TARGETPATH=obj BROWSER_INFO=1 C_DEFINES=-DDRIVER INCLUDES=.\inc SOURCES=Wap32.c #wap32.c文件： int DriverEntry(VOID) { return 0; } 2）创建目录树：Asm,C++,比如我把他们都放在D:\Driver目录下： 创建后完整路径如下D:\Driver\Asm;D:\Driver\C++ 3）制作汇编基本文件wap32.asm内容如下： include IFSDDK.inc locals .586p .model flat,STDCALL .data db 'this is data' .code public _DriverEntry@8 _DriverEntry@8 proc uses ebx esi edi,pDriverObject:dword,pRegPath:dword xor eax,eax ret DriverEntry@8 endp 4)制作批处理文件m.bat内容如下： cd asm; tasm32 /ML WAP32.ASM cd .. copy asm\wap32.obj c++\wap32.obj /y cd c++ build cd .. copy c++\wap32.sys /y 5)把这些文件放到正确的路径上： d:\driver\m.bat d:\drvier\asm\wap32.asm d:\driver\c++\wap32.c d:\driver\c++\makefile d:\driver\c++\sources 6)OK，先进入DDK,Free Build Environment,弹出DOS框，输入Dos命令： c:\NTDDK\>D: d:\>cd Driver d:\>Driver\>cd c++ d:\>Driver\c++\>build ...... 1 file compiled - 4 LPS 1 executable built d:\>Driver\c++\>cd .. d:\>Driver\>m ...... Assembling file: WAP32.asm Error messages: None Warning messages: None Passes: 1 ...... 1 executable built - 1 Warning ...... 1 file(s) copied. d:\Driver\> 如果顺利的话，在D:\Driver\下就生成了一个Wap32.sys [3]inc文件，2kDKK/IFSDDK没有汇编使用的头文件，这个需要我们手工完成。生成我们可以使用的IFS.inc [4]函数引入问题的解决： 调查Tasm生成的OBJ文件是OEF文件格式，与C++的OBJ不符合，幸好C++中的link可以自动转换。 将DKK的C:\NTDDK\freelib\ntoskrnl.lib拿出来观察，发现他的采用的是COFT格式，函数名已经变化 所以引入函数名应该从ntoskrnl.lib中的名字为准，不应该使用ntoskrnl.exe的真实函数名，否则无法连接。 [5]驱动程序入口的编制： 1）与做一般的驱动程序一样，创建控制设备对象，并建立符号连接 2）登记Dispatch例程：与一般的文件系统过滤驱动程序不同，在这里只需要登记 MJ_IRP_CREATE,MJ_RIP_CLOSE，MJ_IRP_DEVICE_CONTROL 这种登记方式更象一般的KernelMode的驱动程序，因为挂接文件系统的方式不同了。 在这个Driver中并不存在真的过滤设备对象(FDO),仅仅只有控制设备对象(CDO) 登记这些函数的目的是为了使WIN32程序能打开我们建立的符号连接。 并通过DeviceIoContrl来控制驱动程序的运行。 3）登记Unload,登记Unload是为了支持动态卸载。 [6]挂接的实现：（有点象病毒在挂文件系统） 1）获得逻辑驱动器跟目录文件关联文件对象(DEVICE OBJECT) a.通过ZwCreate()打开跟目录文件 b.调用ObReferenceObjectByHandle()得到其文件设备对象 此设备对象对应的驱动程序名字是FtDisk，他并不处理实际的IRP文件操作。 他仅仅是文件系统一个协调器，IFSDDK指出他是医科可选驱动程序。我们不挂接他。 c.调用IoGetRelatedDeviceObject()得到关联文件设备对象 此设备对象可能是Ntfs(C:...),FastFat(A:)...如果你装载了病毒防火墙，就是防火墙驱动程序的名字 例如：金山毒霸的KWatch... 2）从其设备对象中取得驱动程序对象(DRIVER OBJECT) ok,有了DriverObject,你就可以挂接你想挂接的MJ_IRP_XXXX了。 3）挂接的细节： 从DriverObject中我们可以得到该驱动程序的DeviceObject首连，从而我们可以遍例该驱动程序建立的所有 设备对象(DeviceObject),而该连的最后一个设备对象就是该驱动程序的控制设备对象(CDO),因此我们不仅可 象传统的文件系统过滤驱动程序那样挂接过滤设备对象（FDO)的,而且还可以以挂接该驱动程序的CDO。 可怕的事情发生了，我们挂接得如此彻底。 4）分辨逻辑驱动器号(Driver Letter) 我们挂接了MJ_IRP_CREATE,但我们却不知道他是那一个逻辑驱动器的文件设备对象，所以要象FileMon一样能把 驱动器盘符也跟踪出来的话，就不得不反复的用1）的办法去的到关联设备对象，然后记录他的地址。共以后对照识别。 5）关于驱动程序分层的问题 我们不可能通过去挂接某一个驱动程序而挂住所有的文件IRP请求。 所以留给我们做的是要考虑到你可能需要挂接多个不同类型的驱动程序，才能完全挂住整个文件系统。 比如挂接软驱可能需要挂FastFat,而挂硬盘确实Ntfs...光驱是CdRom等等。 6）一般不需要挂控制设备对象(CDO) CDO不处理实际的文件IRP请求。为了使原有CDO运行正常我们必须保存他的驱动程序对象 以便我们能找到他的MJ_IRP_XXX函数地址。这里涉及更多的细节。 [7]驱动程序Unload事件挂接 1）挂接Unload事件的意义： 当一个被挂接设备驱动程序被Unload后，我们的驱动程序也随着死去了，虽然他还在内存，但是所有IRP都已经转向到其他更底层的驱动程序。 所以，Unload例程是必须要挂接的，（除非你一开始便挂在了最底层的驱动程序上面,但本人还没有找到方法） 2）挂接的时机：（正在研究中...) 设计者应采用修改指令来挂接。