Q1815349357Q

  多年前，部分杀软就推出了U盘访问控制，摄像头保护的功能。

现在较火的端点防护概念，也强调自己设备权限控制的能力，但实现方法见智见仁。

  驱动级控制的原理是类过滤驱动，做内核开发的传统艺能了。

  比如：https://github.com/pwnslinger/USBlocker

  比如百度杀毒的BdCameraProtect.sys，笔者手里这份编译时间是：2013/10/30 (PE FILE_HEADER).

正好看到X绒的hrdevmon.sys，打开看一下。

在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class里搜索hrdevmon,能看到所有被过滤的类。

hrdevmon.sys Attach了如下两种DeviceType:

  - FILE_DEVICE_MASS_STORAGE

  - FILE_DEVICE_KS

对MASS_STORAGE设备的处理里，着重处理了：

  - MJ_FltMassStorageWrite

  - MJ_FltMassStorageDevCtl （IOCTL_SCSI_PASS_THROUGH & IOCTL_SCSI_PASS_THROUGH_DIRECT）

                             Cdb[0] (0xA or 0x2A or 0xAA)

参考：

   Windows IOCTL Reference：http://www.ioctls.net/

   SCSI Operation Codes：https://www.t10.org/lists/op-num.htm

但是两者都只过滤了写操作，判断偏移是否在MBR或者VBR内，是的话说明有人写MBR/VBR，则上报。

这里有个疑问，由一个函数判断偏移是否在MBR或者VBR里，

Write里是用偏移字节数传递给该函数，DevCtl里则是用扇区数传递给该函数，该函数并没有区分，

这里写错了还是笔者搞错了？

MASS_STORAGE里并不干涉U盘（只要不是写MBR/VBR），那么正好很容易能突破，如下：

https://blog.csdn.net/u011164819/article/details/52045151

或者不想写代码，用winhex（工具->打开磁盘）即可。

FILE_DEVICE_KS这个，内核流设备，是用来保护摄像头的，挂载在注册表Class里的image设备里面。

MJ_FltKsDevCtl里，IOCTL_KS_READ_STREAM，是读取流内容。

这里会往上报操作者pid与tid，然后弹框询问用户，允许或阻止。

hrdevmon里，所有FltKsDevObj是放在一个全局list里（g_pFltKsDOList），有数量限制。

附上idb，侵删

-End-

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课