为什么要绑定FS的CDO设备?
楚狂人在《Windows文件系统过滤驱动开发教程(第二版)》中写道:
“一个新的存储媒质被系统发现并在文件系统中生成一个Volume的过程称为Mounting.其过程开始的时候,FS的CDO将得到一个IRP,其Major Function Code为IRP_MJ_FILE_SYSTEM_CONTROL,Minor Function Code为IRP_MN_MOUNT。换句话说,如果我们已经生成了一个设备绑定文件系统的CDO,那么我们就可以得到这样的IRP,在其中知道一个新的Volume正在Mount.这时候我们可以执行上边所说的操作”
我们以微软源码sfilter进行分析
在我的另一篇《windows内核编程 白话设备栈》(http://www.cnblogs.com/UnMovedMover/p/4195063.html)一文中截取一幅图
图1
如图1,我们的Sfilter!FiDO绑定在Ntfs!CDO之上。
在DriverEntry中设置IRP_MJ_FILE_SYSTEM_CONTROL的IRP处理函数:
DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL]=SfFsControl;
下面我们用WinDBG来分析SfFsControl函数
在函数
NTSTATUS
SfFsControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)中 传入的 参数信息:图2
DeviceObject的地址是0x86337998,是绑定在Ntfs!CDO上的FiDO的地址。这时候说明我们已经截获了发送给FS的IRP_MJ_FILE_SYSTEM_CONTROL。
我们记录下storageStackDeviceObject= irpSp->Parameters.MountVolume.Vpb->RealDevice;
图3
typedef struct_VPB {
CSHORT Type;
CSHORT Size;
USHORT Flags;
USHORT VolumeLabelLength;// inbytes
struct _DEVICE_OBJECT *DeviceObject; //文件系统上的卷设备对象
struct _DEVICE_OBJECT *RealDevice; //实际存储媒介设备对象
ULONG SerialNumber;
ULONG ReferenceCount;
WCHAR VolumeLabel[MAXIMUM_VOLUME_LABEL_LENGTH/sizeof(WCHAR)];
} VPB, *PVPB;
这里截取的IRP我们只能取出RealDevice,DeviceObject这个设备要到文件系统处理完之后才能取得。
新建一个FiDO
status = IoCreateDevice( gSFilterDriverObject,
sizeof( SFILTER_DEVICE_EXTENSION ),
NULL,
DeviceObject->DeviceType,
0,
FALSE,
&newDeviceObject );
图4
newDeviceObject的地址是0x861b73f8
newDevExt =newDeviceObject->DeviceExtension;
newDevExt->StorageStackDeviceObject =storageStackDeviceObject;
调用ObQueryNameString查询StorageStackDeviceObject 的设备名
图5
接下来调用 status= IoCallDriver( devExt->AttachedToDeviceObject, Irp );交给Ntfs!CDO处理
图6
Ntfs!CDO处理完之后生成VPB->VDO(0x8626a020)
图7
NTFS!VDO->NextDevice(0x862c8270)正是NTFS!CDO(0x862c8270)
图8
绑定FiDO到NTFS!VDO设备上
status = SfAttachDeviceToDeviceStack(
vpb->DeviceObject,
FiDO,
&newDevExt->AttachedToDeviceObject );
图9
最后我们绘制出FiDO附着在VDO上的全图
图10
- 1楼zzw007a昨天 14:26
- 驱动的海洋中畅游。。。。。