|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
章鱼C PG有快速测试的方法 调那个时间函数 叫什么来着我忘记了WIN10 X64上还是不行!微软已经把ntfs.sys的PG校验加起了。 在WIN7X64 SP0,SP1上还可以试试,PG比较旧。 |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
章鱼C 刚问了一下 的确扫 PG3还是PG4就开始了 我没记错 嗯!在WIN10 1809 x64下测试了下,可以确定: 挂了inline hook的虚拟机等它跑起,我先去忙别的了,过1个多钟头再来看。
最后于 2020-12-21 19:55
被低调putchar编辑
,原因:
|
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
hhkqqs 引用某个大佬的pg_context,现在的pg今非昔比了 “ 0 : A generic data region 1 : Modification of a ...IRP钩子修改的是nt!_DRIVER_OBJECT驱动对象的内容,Win10的x64系统上会触发PG. 再试试inline Hook钩子。这个应该是修改的ntfs.sys里面的内容了。 |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
章鱼C 我印象中ntfs PG是会扫的 你可以查一下我查了下,Patch Guard是针对内核模块: ntoskrnl.exe的,而文件系统驱动:ntfs.sys/fastfat.sys PG会忽略的。 当然也不排除以后的系统微软可能要增加对文件系统的Patch Guard |
|
[原创]调试实战 | 通过转储文件分析程序无响应之使用 windbg + IDA 逆向篇
不错!界面开发我还有点印象,很多年前做界面时,记得SendMessage要等待界面线程处理了消息才会返回,而PostMessage把消息寄送过去不等待。 根据你发上来的截图,这里把AssemblyDesign_Tools.dll的GetCVUploadInfoFromPCUnit函数中把SendMessage改为PostMessage是否可行? 不错!楼主的调试经验很丰富!赞一个! |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
沉醉星渊 请问大佬,有没有hook ntfs.sys派遣函数的例子呀 以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编辑
,原因:
|
|
[原创]Hook技术:Ring3层下的Inline Hook详解【附源码】
八零年的刘某 那个 目标地址-原地址-5 是怎么回事,我弄了好多次 地址都计算的不对。jmp near xxx; 近跳指令长度为5字节 操作码0xe9: 后面的相对偏移=目标地址-(近跳指令地址+5)=目标地址--近跳指令地址-5 |
|
IDA7.5 启动基础配置
感谢分享! |
|
|
|
[求助]请问手动构造irp会被minifilter截获吗
沉醉星渊 昨天看了论坛里大牛的文章,https://bbs.pediy.com/thread-264070-1.htm#1672687,里面介绍了这种方法,直接给底层设备发送手动构建的irp我算不上大牛!只是以前工作时接触文件驱动方面的内容多些,相比我其它方面的内容相对熟悉点。 来这里可以找很多资料,相互交流,共同进步! |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
沉醉星渊 请问大佬,有没有hook ntfs.sys派遣函数的例子呀 可以实现!成本比较高!一些标签水印系统就是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中有例子: https://github.com/ExpLife0011/sfilter-1 可以自行学习掌握。 有人可能会想到另一种方法: 用ObQueryNameString查询设备栈最底层的设备名,对于没有名字的就认为是文件系统卷设备。 但除了IRP_MJ_CREATE/IRP_MJ_CLOSE/IRP_MJ_CLEANUP外,文件系统其余IRP请求中用ObQueryNameString容易死锁。所以还是 注册一个文件系统变动回调自己增删设备维护一个设备链的方法稳妥些。
最后于 2020-12-20 18:44
被低调putchar编辑
,原因:
|
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
沉醉星渊 请问大佬,如果采用你上面说的那个直接发送给最底层的设备对象,过掉中间的过滤设备,这种情况下的请求有什么办法能过滤到吗微过滤管理器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钩子就可以绕过。 |
|
[原创] [Windows驱动开发] 00_环境搭建
在高版本的VMWare上(15.x以上),VirtualKD不好使了,我在16.x的VMWare上用的VirtualKD-Redux。 |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
hhkqqs 膜拜,看原理应该跟pchunter差不多,绕过ssdt函数直接自行下发irp[em_63] 您也不错!
最后于 2020-12-21 23:03
被低调putchar编辑
,原因:
|
|
[原创]PspCidTable引起的思考和探索
感谢分享!至少在我的另一台笔记本Win10(1809)上有效。 kd> uf nt!PsLookupProcessByProcessId nt!PsLookupProcessByProcessId: fffff800`50840100 48895c2418 mov qword ptr [rsp+18h],rbx fffff800`50840105 56 push rsi fffff800`50840106 4883ec20 sub rsp,20h fffff800`5084010a 48897c2438 mov qword ptr [rsp+38h],rdi fffff800`5084010f 488bf2 mov rsi,rdx fffff800`50840112 65488b3c2588010000 mov rdi,qword ptr gs:[188h] fffff800`5084011b 66ff8fe6010000 dec word ptr [rdi+1E6h] fffff800`50840122 b203 mov dl,3 fffff800`50840124 e8a7060000 call nt!PspReferenceCidTableEntry (fffff800`508407d0) ... kd> uf nt!PspReferenceCidTableEntry nt!PspReferenceCidTableEntry: fffff800`508407d0 48895c2408 mov qword ptr [rsp+8],rbx fffff800`508407d5 48896c2410 mov qword ptr [rsp+10h],rbp fffff800`508407da 4889742418 mov qword ptr [rsp+18h],rsi fffff800`508407df 48897c2420 mov qword ptr [rsp+20h],rdi fffff800`508407e4 4156 push r14 fffff800`508407e6 4883ec20 sub rsp,20h fffff800`508407ea 488b0567acf1ff mov rax,qword ptr [nt!PspCidTable (fffff800`5075b458)] ... 1: kd> dq nt!PspCidTable fffff800`5075b458 ffffbe8f`2aa07b00 00000000`00000000 fffff800`5075b468 ffff948f`3ecb20c0 00000000`00000000 fffff800`5075b478 00010000`00000000 0000017c`00001000 fffff800`5075b488 00000000`00001f41 00000000`00009e09 fffff800`5075b498 00000000`00000000 00000000`00000000 fffff800`5075b4a8 00000000`00000000 00000000`00000000 fffff800`5075b4b8 00000000`00000000 00000000`00000000 fffff800`5075b4c8 00000000`00000000 00000000`00000000 1: kd> dq ffffbe8f`2aa07b00 ffffbe8f`2aa07b00 00000000`00001c00 ffffbe8f`3383a001 ffffbe8f`2aa07b10 00000000`00000000 ffffbe8f`2aa07b18 ffffbe8f`2aa07b20 ffffbe8f`2aa07b18 00000001`00000000 ffffbe8f`2aa07b30 00000000`00000000 00000000`00000000 ffffbe8f`2aa07b40 00000000`00000000 ffffbe8f`2aa2b110 ffffbe8f`2aa07b50 ffffbe8f`2aa2bc20 000006bf`000006bc ffffbe8f`2aa07b60 00000000`00000000 00000000`00000000 ffffbe8f`2aa07b70 00000000`00000000 00000000`00000000 1: kd> dq ffffbe8f`3383a000 ffffbe8f`3383a000 ffffbe8f`2aa2b000 ffffbe8f`3383b000 ffffbe8f`3383a010 ffffbe8f`2f3ff000 ffffbe8f`2e9fd000 ffffbe8f`3383a020 ffffbe8f`33d32000 ffffbe8f`35107000 ffffbe8f`3383a030 ffffbe8f`35af9000 00000000`00000000 ffffbe8f`3383a040 00000000`00000000 00000000`00000000 ffffbe8f`3383a050 00000000`00000000 00000000`00000000 ffffbe8f`3383a060 00000000`00000000 00000000`00000000 ffffbe8f`3383a070 00000000`00000000 00000000`00000000 1: kd> dq ffffbe8f`2aa2b000 ffffbe8f`2aa2b000 00000000`00000000 00000000`00000000 ffffbe8f`2aa2b010 948f3ec7`e300ffb9 00000000`00000000 ffffbe8f`2aa2b020 948f41fa`50800001 00000000`00000000 ffffbe8f`2aa2b030 948f3ed2`40800001 00000000`00000000 ffffbe8f`2aa2b040 948f3ed7`90800001 00000000`00000000 ffffbe8f`2aa2b050 948f3ed6`80800001 00000000`00000000 ffffbe8f`2aa2b060 948f3ed1`30800001 00000000`00000000 ffffbe8f`2aa2b070 948f3edb`01400001 00000000`00000000 1: kd> !object ffff948f3ec7`e300 Object: ffff948f3ec7e300 Type: (ffff948f3eca8e80) Process ObjectHeader: ffff948f3ec7e2d0 (new version) HandleCount: 5 PointerCount: 163940 nt!PspCidTable的定位,修改都好办。x64上,由于PG的原因,改了过一会儿会蓝。 不过学习点东西还是不错的!PCHunter_jb51.net的驱动也没有加壳,空了再慢慢分析。 |
|
[原创]内核层自己发送IRP请求操作文件全面总结(已完整调试, x86/x64各系统通用)
killpy jianro兼容win7 到10? 嗯!是兼容的!对ntfs/fastfat(fat32)文件系统发送IRP操作文件,各个版本的windows基本相同, 以前做小工具的时候从WinXP SP2到Win7 SP1都用过,Win10上现在也进行了调试,全部兼容。这里做个总结!
最后于 2020-12-9 09:32
被低调putchar编辑
,原因:
|