-
-
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用）
-
发表于: 2020-12-8 00:30
-
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
嗯！是兼容的！对ntfs/fastfat(fat32)文件系统发送IRP操作文件,各个版本的windows基本相同， 以前做小工具的时候从WinXP SP2到Win7 SP1都用过，Win10上现在也进行了调试，全部兼容。这里做个总结！
最后于 2020-12-9 09:32
被低调putchar编辑
，原因：
|
|
|
 好总结
|
|
|
|
|
|
|
|
|
膜拜，看原理应该跟pchunter差不多，绕过ssdt函数直接自行下发irp
|
|
|
|
|
|
您也不错！
最后于 2020-12-21 23:03
被低调putchar编辑
，原因：
|
|
|
|
|
|
|
|
|
|
|
|
虽然东西是老知识，但是做了这么详细的总结以及从win7到win10 都可以用，不错点赞！！！！！！！！！！！
|
|
|
厉害！
|
|
|
|
|
|
|
|
|
微过滤管理器L"\\FileSystem\\FltMgr"本质上还是一个文件系统过滤驱动FltMgr.sys，通过把过滤设备绑定在pVpb->DeviceObject卷设备之上来监控文件操作的，如果发送IRP请求时指定ntfs.sys/fastfat.sys的文件系统卷设备pVpb->DeviceObject，请求不会送往过滤设备，MiniFilter是捕获不到的。 如果HOOK了ntfs.sys/fastfat.sys派发例程, pDriverObject->MajorFunction就可以过滤到。 但HOOK是可以摘除的，如果下发IRP请求前检测并摘除了IRP钩子/inline Hook钩子就可以绕过。 |
|
|
|
|
|
|
|
|
可以实现！成本比较高！一些标签水印系统就是HOOK的fsd的MajorFunction. 文件系统控制设备也能收到：IRP_MJ_CREATE, IRP_MJ_CLEANUP, IRP_MJ_CLOSE等请求 所以有必要区分文件系统的控制设备和卷设备，另外视情况决定是否要过滤卷影设备。 区分文件系统的控制设备和卷设备比较靠谱的方法就是: IoRegisterFsRegistrationChange注册一个文件系统变动回调 //注册文件系统变动回调 NTSTATUS IoRegisterFsRegistrationChange( PDRIVER_OBJECT DriverObject, //你的驱动对象指针 PDRIVER_FS_NOTIFICATION DriverNotificationRoutine //文件系统变动回调 ); //文件系统变动回调 void DriverFsNotification( _DEVICE_OBJECT *DeviceObject, //激活或注销的文件系统的控制设备(包括文件系统识别器控制设备) BOOLEAN FsActive 当文件系统激活时FsActive为TRUE，文件系统注销时FsActive为FALSE ) 自己增删设备维护一个设备链(包含了文件系统识别器及当前已激活的文件系统的控制设备)，只要不在设备链中的设备可以视为文件系统卷设备(包括卷影)。 卷影设备的判断sfilter中有例子: 可以自行学习掌握。 有人可能会想到另一种方法: 用ObQueryNameString查询设备栈最底层的设备名，对于没有名字的就认为是文件系统卷设备。 但除了IRP_MJ_CREATE/IRP_MJ_CLOSE/IRP_MJ_CLEANUP外，文件系统其余IRP请求中用ObQueryNameString容易死锁。所以还是 注册一个文件系统变动回调自己增删设备维护一个设备链的方法稳妥些。
最后于 2020-12-20 18:44
被低调putchar编辑
，原因：
|
|
|
以HOOK 64位ntfs主功能号为IRP_MJ_DIRECTORY_CONTROL派遣函数为例,的伪代码 1. 获得驱动对象指针伪代码: extern POBJECT_TYPE *IoDriverObjectType; //自己外部声明: 导出驱动对象类型
//一个未公开的内核API函数,直接声明一下就可以用了
NTKERNELAPI
NTSTATUS NTAPI ObReferenceObjectByName(
IN PUNICODE_STRING ObjectName,
IN ULONG Attributes,
OUT PACCESS_STATE AccessState OPTIONAL,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_TYPE ObjectType OPTIONAL,
IN KPROCESSOR_MODE AccessMode,
IN PVOID ParseContext OPTIONAL,
OUT PVOID *Object
);
...
//获得ntfs驱动对象指针
RtlInitUnicodeString(&unsObjectName,
L"\\FileSystem\\Ntfs");
ntStatus=ObReferenceObjectByName(&unsObjectName,
OBJ_CASE_INSENSITIVE,
NULL,
FILE_READ_DATA|FILE_WRITE_DATA,
*IoDriverObjectType,
KernelMode,
NULL,
(PVOID*)&g_pNtfsDriver);
if(NT_SUCCESS(ntStatus)){
...
//挂钩
//...
ObDereferenceObject((PVOID)g_pNtfsDriver);
...
}2. IRP钩子伪代码: //IRP挂钩
if(NT_SUCCESS(ntStatus)){
//保存ntfs以前的派遣例程，把ntfs的派遣例程替换成你自己的钩子函数
g_sysDispatchDirectoryControl=InterlockedExchangePointer(&g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL],
DispatchDirectoryControlHook);
ObDereferenceObject((PVOID)pNtfsDriver);
}
...
//钩子函数
NTSTATUS DispatchDirectoryControlHook(IN PDEVICE_OBJECT pDeviceObject,
IN PIRP pIrp)
{
NTSTATUS ntStatus;
//执行前过滤
//...
ntStatus=g_sysDispatchDirectoryControl(pDeviceObject,
pIrp); //执行ntfs以前的派遣例程
//执行后的过滤
//...
return ntStatus;
}2. inline hook 钩子伪代码 //中转函数(类似32位inline hook中的__declspec(naked)裸函数功能,必须保证至少容纳24字节)
//在hook时，前12字节被替换为: g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL]的前12个字节节
//然后: mov rax, imm64(机器码: 48 b8 64位立即数)
//jmp rax(机器码: ff e0)
//在hook时， imm64被替换为: (ULONG_PTR)g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL]+12
NTSTATUS NakedDispatchDirectoryControl(
IN PDEVICE_OBJECT pDeviceObject,
IN PIRP pIrp
)
{
//这里可以自己任意写些功能性代码,只要保证函数体长度不少于24字节即可
...
}
//inline hook
VOID InlineHook(VOID)
{
//mov rax,imm64 (机器码: 48 b8 64位立即数)
//jmp rax(机器码: ff e0)
UCHAR ucCode[12] = { 0x48,0xb8,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xe0 }, //imm64: 为钩子函数HookedDispatchDirectoryControl地址
ucCodeNaked[12] = { 0x48,0xb8,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xe0 }; //imm64: 为ntfs派遣例程地址+12
ULONGLONG ullAddr;
KIRQL kSavedIrql;
//保存ntfs派遣例程的前12字节指令集
/*
WIN7 SP0
PAGE:00000000000B1680 mov [rsp+arg_0], rbx
PAGE:00000000000B1685 mov [rsp+arg_8], rdx
PAGE:00000000000B168A push rsi
PAGE:00000000000B168B push rdi
*/
/*
WIN7 SP1
PAGE:00000000000A97E0 mov [rsp+arg_0], rbx
PAGE:00000000000A97E5 mov [rsp+arg_8], rdx
PAGE:00000000000A97EA push rsi
PAGE:00000000000A97EB push rdi
*/
RtlCopyMemory(g_oldCode,
g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL],
12);
//钩子派遣例程地址
ullAddr = (ULONGLONG)HookedDispatchDirectoryControl;
RtlCopyMemory(&ucCode[2],
&ullAddr,
8);
//ntfs派遣例程地址的12字节偏处
ullAddr = (ULONGLONG)g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL] + 12;
RtlCopyMemory(&ucCodeNaked[2],
&ullAddr,
8);
CloseWriteProtect(&kSavedIrql); //关闭写保护(自实现的中断请求级别提升及CR0的bit16置0)
//Patch掉NakedDispatchDirectoryControl的前24字节
//调用时, 先执行ntfs派遣例程原来的12字节指令集，然后跳转到ntfs派遣例程+12处，发挥类似裸函数的功能
RtlCopyMemory(NakedDispatchDirectoryControl,
g_oldCode,
12);
RtlCopyMemory((PUCHAR)NakedDispatchDirectoryControl + 12,
ucCodeNaked,
12);
//修改ntfs派遣例程前12字节,以便跳转到我们的钩子函数
RtlCopyMemory(g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL],
ucCode,
12);
RestoreWriteProtect(kSavedIrql); //恢复写保护(自实现的中断请求级别恢复及CR0bit16置1)
return;
}
//inline unhook
VOID UnInlineHook(VOID)
{
KIRQL kSavedIrql;
CloseWriteProtect(&kSavedIrql); //关闭写保护(自实现的中断请求级别提升及CR0的bit16置0)
RtlCopyMemory(g_pNtfsDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL],
g_oldCode,
12); //恢复派遣例程前12字节
RestoreWriteProtect(kSavedIrql); //恢复写保护 (自实现的中断请求级别恢复及CR0bit16置1)
return;
}
...
//inline hook挂钩
if(NT_SUCCESS(ntStatus)){
InlineHook();
ObDereferenceObject((PVOID)g_pNtfsDriver);
}
...
//钩子函数
NTSTATUS DispatchDirectoryControlHook(IN PDEVICE_OBJECT pDeviceObject,
IN PIRP pIrp)
{
NTSTATUS ntStatus;
//执行前过滤
//...
//
// 转去中转函数(类似32位inline hook的裸函数)，最终转去执行ntfs的原来的派遣例程功能(这里作了改进,不用考虑线程同步)
//
ntStatus=NakedDispatchDirectoryControl(pDeviceObject,
pIrp);
//执行后的过滤
//...
return ntStatus;
}
最后于 2020-12-22 20:30
被低调putchar编辑
，原因：
|
|
|
|
|
|
|
