摘除过滤驱动


开始本文之前先膜拜一下老V~

“无法F5的驱动，不是好驱动啊~不是好驱动啊~ ”            -----killvxk语录


这两天下午的时间，破解那个驱动保护搞得好痛苦，每次关机都要蓝一次，有时候设备还不工作，郁闷...

而且VMware用得很伤心，每次开GuestOS都得6分钟左右，要不是时间不多懒得换它，早就把它扔到垃圾堆里去了~~~~~~~~~~

忘了今天主题了，摘除过滤驱动来着~

某些驱动创建自己的Device之后调用IoAttachDeviceXXX函数来将自己的设备附加到目标设备上，成为其上一层驱动，这样当有IRP发来的时候就有了优先处理权。这个其实可以认为是M$给你提供的正统的Hook方式，否则的话你要优先处理IRP可能就得Hook及DispatchRoutine了~如果拿到IRP就处理的话，可以认为是SetOnBefore的Hook方式，如果拿到IRP后设置CompleteRoutine然后继续下发，可以认为是SetOnAfter的Hook方式。又说到Hook这东西了，这东西其实主要在思想，越邪恶越WS才越强大~

进行附加设备的函数有：

IoAttachDevice

IoAttachDeviceByPointer

IoAttachDeviceToDeviceStack

IoAttachDeviceToDeviceStackSafe

它们都调用了未导出的IopAttachDeviceToDeviceStackSafe，要Hook的话就搞它吧~我的驱动里就这么干的，发现调用来自某XX驱动的话就直接返回个失败结果，这样就拒绝某些特定的驱动进行Attach操作(不知道如果把那个XX驱动的AddDevice函数给直接Patch掉会怎么样)。

当AttachDevice操作成功后，目标设备的AttachedDevice指向刚附加上的设备，而附加上的设备的_DEVOBJ_EXTENSION结构中的AttachedTo则指向它附加上的设备。

结构如下：

lkd> dt _DEVICE_OBJECT

nt!_DEVICE_OBJECT

   +0x000 Type             : Int2B

   +0x002 Size             : Uint2B

   +0x004 ReferenceCount   : Int4B

   +0x008 DriverObject     : Ptr32 _DRIVER_OBJECT

   +0x00c NextDevice       : Ptr32 _DEVICE_OBJECT

   +0x010 AttachedDevice   : Ptr32 _DEVICE_OBJECT

   +0x014 CurrentIrp       : Ptr32 _IRP

   +0x018 Timer            : Ptr32 _IO_TIMER

   +0x01c Flags            : Uint4B

   +0x020 Characteristics : Uint4B

   +0x024 Vpb              : Ptr32 _VPB

   +0x028 DeviceExtension : Ptr32 Void

   +0x02c DeviceType       : Uint4B

   +0x030 StackSize        : Char

   +0x034 Queue            : __unnamed

   +0x05c AlignmentRequirement : Uint4B

   +0x060 DeviceQueue      : _KDEVICE_QUEUE

   +0x074 Dpc              : _KDPC

   +0x094 ActiveThreadCount : Uint4B

   +0x098 SecurityDescriptor : Ptr32 Void

   +0x09c DeviceLock       : _KEVENT

   +0x0ac SectorSize       : Uint2B

   +0x0ae Spare1           : Uint2B

   +0x0b0 DeviceObjectExtension : Ptr32 _DEVOBJ_EXTENSION

   +0x0b4 Reserved         : Ptr32 Void

lkd> dt _DEVOBJ_EXTENSION

nt!_DEVOBJ_EXTENSION

   +0x000 Type             : Int2B

   +0x002 Size             : Uint2B

   +0x004 DeviceObject     : Ptr32 _DEVICE_OBJECT

   +0x008 PowerFlags       : Uint4B

   +0x00c Dope             : Ptr32 _DEVICE_OBJECT_POWER_EXTENSION

   +0x010 ExtensionFlags   : Uint4B

   +0x014 DeviceNode       : Ptr32 Void

   +0x018 AttachedTo       : Ptr32 _DEVICE_OBJECT

   +0x01c StartIoCount     : Int4B

   +0x020 StartIoKey       : Int4B

   +0x024 StartIoFlags     : Uint4B

   +0x028 Vpb              : Ptr32 _VPB

也就是说，每个设备对象中的AttachedDevice和AttachedTo这两个域承上启下，通过它可以找到它的上一层设备和下一层设备，像什么？对了，双项链表！


如图，要摘除中间这个过滤驱动B的话，只要断开这个双链就可以了。同时把B的AttachedDevice和AttachedTo这两个域清零。整个操作很像断链隐藏进程，都是双向链表嘛~

0GiNr上FC的一篇文章《摘除过滤驱动》提供的代码是这样的：

/////////////////////////////////////代码开始///////////////////////////////////////////////

RtlInitUnicodeString ( &TcpipName, L"\\Driver\\Tcpip" );

ObReferenceObjectByName( &TcpipName,

OBJ_CASE_INSENSITIVE,

NULL,

0,

*IoDriverObjectType,

KernelMode,

NULL,

&TcpipDrvObj);

TcpipDevice = TcpipDrvObj->DeviceObject;

while(TcpipDevice!= NULL )

{

TcpipDevice->AttachedDevice=0;

TcpipDevice = TcpipDevice->NextDevice;

}

//////////////////////////////////////代码结束//////////////////////////////////////////////////////////

这种摘除法，有点太暴力了(狙剑的过滤驱动摘除就是这么暴力)~而且摘除方法不是很正规吧~

FC说“首先Reference最底层的，然后循环摘下附在上面的设备”，不知是我最初看到这句话时理解错了还是FC说的不太准确，我觉得同一个驱动创建的多个设备应该是并行的关系没有谁上谁下，而过滤设备与原设备才是上下的关系。所以FC的“最底层的，附在上面”貌似容易引起误解。

我的摘除法稍“温柔”一点，摘之前判断一下是不是目标设备的，全摘了也不太好~

//////////////////////////////////////////////////代码开始/////////////////////////////////////////////////////////////

VOID DetachSecureDevicesFromTargetDriver(PDRIVER_OBJECT pOwnerDrvObject)

{

 PDEVICE_OBJECT pDevObj,pNextDev;


if (pOwnerDrvObject)

 {

   //取第一个设备

   pNextDev=pOwnerDrvObject->DeviceObject;

   do

   {

    pDevObj=pNextDev;

    ////////////////////////////////////////////////////////////////////////////////

    ///内部循环摘除单个设备上所附加的设备

    //DbgPrint("正在检查设备0x%08X\n",pDevObj);

    while(pDevObj->AttachedDevice)

    {

     //判断第一个设备的附加设备

     //进行判断

     if (IsSecurDevice(pDevObj->AttachedDevice))

     {

      DbgPrint("Detaching Device:0x%08X\n",pDevObj->AttachedDevice);

      IoDetachDevice(pDevObj);//若是XX系统的设备，就摘掉它

     }

     else

     {

      pDevObj=pDevObj->AttachedDevice;//若不是，取上一层设备

     }

    }

    //////////////////////////////////////////////////////////////////////////////

    pNextDev=pNextDev->NextDevice;

   } while(pNextDev);


}


}


////////////////////////////////////////代码结束/////////////////////////////////////////////////////////////////

摘除效果还可以，有选择性地摘嘛，呵呵~


到目前为止，我使用了以下步骤来对付这个USB控制驱动(目标是插入U盘后可以正常访问)：

1.恢复它对IofCompleteRequest的Hook

取原始值时很搞笑，它Hook时不是保存原始值到自己驱动中一个全局变量了嘛，我就直接读出来再写回去~

2.Patch掉它使用IoRegisterFsRegistrationChange注册的FsChangeRoutine

3.Inline Hook了IopAttachDeviceToDeviceStackSafe拒绝它往新设备上挂载filter设备

4.摘除它的文件系统过滤驱动，磁盘系统过滤驱动


可以还是搞不定，目前访问插入的U盘时终于可以看到文件系统了，但是双击打开提示拒绝访问~而且那厮还篡改消息，把“拒绝访问”改成了“未注册”，太明显了~

驱动中我不知道还有什么地方需要处理了，我能想到的已经都搞了。应该还跟Ring3部分的程序有关，那个程序中有用CreateFile打开并进行DeviceIoControl操作，不过这里我还不清楚这样发送某些DeviceIoControl命令之后就可以达到禁止访问的效果吗？继续研究....哪位XDJM如果了解这一块儿知识请不吝指点~~

摘除过滤驱动,布布扣,bubuko.com

时间： 2025-01-05 07:20:00

摘除过滤驱动的相关文章

文件过滤驱动开发

文件过滤驱动 一.文件透明加解密 关键字:透明.文件过滤驱动.加密标识,缓存 文件过滤驱动最重要的两点是搞定加密标识和缓存管理 1.透明概念: 透明指的是用户在操作的时候,虽然后台在自动的进行加解密,但是用户根本就不知道加密的存在,就像中间隔了一层透明的玻璃一样. 透明的好处在于不改变用户的操作,一切都和加密之前一样,甚至在有些企业安装加密后都无需通知所有的员工,就像加密并不存在一样,只是加密文件到了企业安全环境的外部才会发现文件无法打开. 透明的程度也是加密软件一个很重要的方面,例如:正在编辑

Windbg对过滤驱动DriverEntry函数下断点技巧

方法1: 1> 先用DeviceTree.exe查看指定的过滤驱动的Load Address(加载地址) 2> 再用LordPE.EXE查看指定过滤驱动文件的入口点地址 3> 计算过滤驱动的DriverEntry函数内存地址 DriverEntry函数内存地址 = Load Address + 入口点地址 例子: 1> Load Address = 0xFAABF000 2> 入口地址 = 0x3400 3> Windbg下断点 bu 0xFAABF000+0x3400

键盘过滤驱动

在笔者接触驱动到如今以来一以后大半个月的时间,从中让我深深的体会到了万事开头难,以及学习持之以恒的重要性.笔者也是个驱动新人,開始接触驱动的时候看着张帆的<Windows驱动开发技术具体解释>讲的挺细,对新手来说是个不错的学习资料,可是更重要的还是自己要多动手练习,笔者在学习到同步操作的相关知识的时候,实在是看天书.最后还是放弃了学习本书.再找了本楚狂人的资料学习,感觉本书对新手来说还是比較吃力的,当中笔者就是这样,非常多知识点不是非常明确,仅仅能凭借自己的感觉去做,只是造成的后果就是无情的蓝

文件过滤驱动实现目录重定向（一）good

文件过滤驱动拦截的IRP主要包括以下几个:IRP_MJ_CREATE,文件创建操作,文件的任何操作,都是从这里开始的.IRP_MJ_CLEANUP,文件的HANDLE句柄全部关闭会触发这个消息IRP_MJ_CLOSE,文件对象 FILE_OBJECT引用减为0,文件对象即将被删除时触发.IRP_MJ_READ.IRP_MJ_WRITE, 文件的读写操作IRP_MJ_QUERY_INFORMATION 查询文件信息,比如文件创建修改时间,文件大小等等.IRP_MJ_SET_INFORMATION

[转载]windows过滤驱动程序设计入门（驱动程序基本结构，设备栈，IRP栈和工作原理）

本文转载自: http://blog.csdn.net/arvon2012/article/details/7789724 最近在学习windows驱动设计,认真看了些教材后总结了我认为驱动中都会涉及到,也最重要的概念,和大家分享.如果有说的不对的请大家留言指出.谢谢! 这里主要是写概念,代码涉及的不多也不详细,但是我会说出涉及到的API,详细的使用细节大家可以自己动手搜搜.掌握下面的概念之后,看驱动开发的教材里的代码,或者理解教材里说的内容应该就顺利很多! 过滤驱动程序概括: 对于window

File System Minifilter Drivers（文件系统微型过滤驱动）

问题: 公司之前有一套文件过滤驱动,但是在实施过程中经常出现问题,现在交由我维护.于是在边看代码的过程中,一边查看官方资料,进行整理. 这套文件过滤驱动的目的只要是根据应用层下发的策略来控制对某些特定文件的控制,例如根据后缀名来决定是否允许查看,是否允许查看指定目录啊之类的功能. 介绍: MSDN上对可安装的文件系统驱动介绍http://msdn.microsoft.com/en-us/library/windows/hardware/ff548143(v=vs.85).aspx:其中树形结构菜

一个简单的文件系统过滤驱动框架

很多人认为文件系统过滤驱动很复杂,其实也有一定道理,因为需要有很多细节需要考虑到,这是一个简单的文件系统过滤驱动,抛去了大部分细节,留下了一个简单的框架,其实这样文件系统过滤驱动就变得蛮简单的,很多接口可以不用实现,只要知道大致流程,其它都将会很清晰. #define DBG 1 #include <ntifs.h> #include "fsfilter.h" PDEVICE_OBJECT g_Cdo; PDRIVER_OBJECT g_MyDriver; NTSTATUS

基于文件过滤驱动的透明加密那点事儿(转)

文件透明加密这点事儿,从2001年开始出现基于API HOOK的方式开始到现在,已经十几年了,有细心人按技术实现的方式将其细分为4代,分别是基于API HOOK的第一代技术.基于文件过滤驱动(加清缓存)的第二代技术.使用Layerfsd的双缓冲第三代技术和基于微软新一代minifilter框架的Layerfsd双缓冲第四代技术.第一代和第二代的技术划分基本上没有异议,所谓的第四代很多人并不认同,认为使用minifilter框架算不上是技术突破,其技术实现仍然是基于Layerfsd的双缓冲技术,没

[转载]文件过滤驱动 文件系统激活通知 IoRegisterFsRegistrationChange函数实现

IoRegisterFsRegistrationChange 注册一个文件系统变动回调函数,用来被通知文件系统的激活和注销,激活是指第一次加载文件系统,当一个文件系统已经加载后,当加载一个同种文件系统的卷时,该文件系统就和激活没关系.话说该函数调用后,激活的文件系统会重新激活一遍,在2k SP4之后的系统都会这样做. 现在考虑下,这种机制是怎么实现的,猜测是在注册的时候,注册完成后,系统将各种类型的文件系统,都调用该回调函数一遍,来一次所有文件系统激活的通知.而事实上,也应该如此,reactOs