开始本文之前先膜拜一下老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如果了解这一块儿知识请不吝指点~~