首页
社区
课程
招聘
[求助]文件过滤如何处理独占问题
发表于: 2021-11-2 19:16 9440

[求助]文件过滤如何处理独占问题

2021-11-2 19:16
9440

过滤驱动框架:minifilter

 

场景:功能类似微软代码示例里面的avscan。过滤驱动在发现文件修改后会将文件路径放到内核队列中,等待应用层通过DeviceIoControl将数据取出并检测。原先这套机制是同步的,队列在内核中,并在Create中检测是否正在扫描,如果发现正在扫描则会进行等待。

 

问题:因为同步有一定的效率问题,所以将这套机制改为异步的,队列从内核移到应用层:应用层收到数据放入队列,由线程慢慢扫描。但在使用时发现一个问题,扫描程序如果打开了文件(扫描程序以共享读写删打开文件),但其他进程以独占方式打开文件就会失败。这样实际上会对程序的正常逻辑造成影响。请问各位大佬,这个场景该怎么处理?有什么比较好的方案吗?


[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!

收藏
免费 0
支持
分享
最新回复 (10)
雪    币: 1
活跃值: (398)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
2
既然有个过滤驱动,完全可以在IRP_MJ_CREATE例程里通过IoStackLocation->Parameters.Create.ShareAccess过滤掉独占文件,不加入队列里

如果你不想这样,你试试扫描程序在处理文件时上个oplock,参考https://github.com/googleprojectzero/symboliclink-testing-tools/tree/master/SetOpLock
2021-11-3 09:33
1
雪    币: 661
活跃值: (1193)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
3
感谢大佬回复,第一个方案不太符合我的需求,第二个方案我测试是可以的。感谢!
另外,如果放在内核做的话,有没有哪些可行的方案?
2021-11-8 14:26
0
雪    币: 1
活跃值: (398)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
4

在其他进程以独占方式打开文件前,如果没有设置oplock,扫描程序必须关闭正在处理的文件句柄,否则"会对程序的正常逻辑造成影响"是必然的

我个人理解的合适的关闭句柄时机是其他进程以独占方式打开文件时触发的IRP_MJ_CREATE:假设将除了扫描程序还有其他进程正在打开文件的情况也考虑在内,你需要ObfReferenceObject之类的函数获取文件对象的引用计数进行判断

如果引用计数的结果是只有扫描程序和当前正在独占打开的进程,那么驱动向扫描程序发送消息,扫描程序收到后关闭句柄(DeviceIoControl怕是不好用了,可以试试LPC:https://bbs.pediy.com/thread-261668.htm)最后设置Irp->IoStatus.Status=0使这次独占打开成功

不是大佬,菜鸡一只,再问就是我不知道。

最后于 2021-11-8 23:36 被sky5编辑 ,原因:
2021-11-8 23:32
0
雪    币: 661
活跃值: (1193)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
5
sky5 在其他进程以独占方式打开文件前,如果没有设置oplock,扫描程序必须关闭正在处理的文件句柄,否则"会对程序的正常逻辑造成影响"是必然的我个人理解的合适的关闭句柄时 ...
其实我原先的思路就是你说的这样,不过用的是DeviceIoControl,但队列没处理好,搞不定同步问题,等有时间再试试。多谢了!
2021-11-9 21:01
0
雪    币: 193
活跃值: (630)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
6
你好,这种情况可以使用minifilter单独维护一块ShareAccess,下发到文件系统驱动的ShareAccess可以适当修改,比如给进程FO原来的ShareAccess加上SHARE_WRITE或SHARE_READ等,文件独占的冲突主要是ShareAccess的问题,可以看看wrk中相关的代码。
2022-1-23 23:07
0
雪    币: 661
活跃值: (1193)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
7
hkx3upper 你好,这种情况可以使用minifilter单独维护一块ShareAccess,下发到文件系统驱动的ShareAccess可以适当修改,比如给进程FO原来的ShareAccess加上SHARE_WRIT ...
这个我倒是尝试过,在PreCreate中判断了权限并修改,不过测试的时候仍然有问题,也不清楚是我设置的不对还是什么原因。
2022-1-24 11:02
0
雪    币: 1319
活跃值: (1955)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
8
这个简单,创建一个fcb就完事了。类似于透明加密双缓冲(两个文件对象,一个管理明文,另一个自己捣鼓)方式。oplock这玩意一般是网络链接(smb)同步数据会用到,不过我没研究过oplock底层文件系统是怎么细致得运作的。
2022-1-25 16:00
0
雪    币: 661
活跃值: (1193)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
9
库尔 这个简单,创建一个fcb就完事了。类似于透明加密双缓冲(两个文件对象,一个管理明文,另一个自己捣鼓)方式。oplock这玩意一般是网络链接(smb)同步数据会用到,不过我没研究过oplock底层文件系 ...
搞FCB有些过分复杂了,我觉得没必要,毕竟不是搞加解密。测试了下oplock机制感觉还行,能够处理占用问题。简单测试了几款杀毒软件,也就发现火绒做得还不错,不会出现占用问题,不会影响操作文件的进程独占打开文件。
2022-1-26 14:59
0
雪    币: 1140
活跃值: (3166)
能力值: ( LV12,RANK:385 )
在线值:
发帖
回帖
粉丝
10
IoCreateFileSpecifyDeviceObjectHint + IO_IGNORE_SHARE_ACCESS_CHECK
IoCreateFileEx + IO_IGNORE_SHARE_ACCESS_CHECK

https://github.com/kouzhudong/libdrv/blob/main/libdrv/CopyFile.cpp
2022-1-26 16:01
0
雪    币: 3116
活跃值: (1269)
能力值: ( LV8,RANK:120 )
在线值:
发帖
回帖
粉丝
11
Anowhere 搞FCB有些过分复杂了,我觉得没必要,毕竟不是搞加解密。测试了下oplock机制感觉还行,能够处理占用问题。简单测试了几款杀毒软件,也就发现火绒做得还不错,不会出现占用问题,不会影响操作文件的进程独占 ...
这么老的帖子。我这边有分享过oplock,可以看下
https://www.cnblogs.com/kkindof/articles/3551307.html
2022-1-26 17:34
0
游客
登录 | 注册 方可回帖
返回
//