下面是通过fltmc进行文件过滤驱动加载的常用命令。
1 2 |
|
写过MiniFIlter驱动的都知道FltUnregisterFilter用于注销回调。
但是MSDN中有这样一段话:
A minifilter driver can only call FltUnregisterFilter to unregister itself, not another minifilter driver.
意思就是驱动应该自身去调用这个函数,而不是使用其他微过滤驱动去调用。
为此我写了一个驱动去实验,发现再调用后驱动就在调用FltUnregisterFilter后一去不复返了。
在对这个函数进行下断后,发现PCHunter在调用移除过滤器后确实会调用FltUnregisterFilter。
上双机调试环境,把IDA拖入fltmgr,启动sync,Windbg 和 ret-sync联调。
1 2 3 |
|
先追踪一去不复返的原因。
经过调试发现ExWaitForRundownProtectionRelease
导致了函数的无限等待。
找到了这个原因,让我们看看MSDN,根据Remarks可知,需要通过调用ExReleaseRundownProtection 来释放保护,这个函数才能返回。
再次调试,看看这个对象的引用计数是怎样的。
在调用Remove之后,我们断在函数FltUnregisterFilter处:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
第一个参数即是_FLT_FILTER
的指针
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
接下来我们看看相关的计数
1 2 3 4 |
|
可以看到再我们卸载时这个Count为0xC。
在调用ExWaitForRundownProtectionRelease
之前,我们再看一次计数
1 2 3 4 |
|
可以看到此时的计数是2。
那么我们接下来测试PCHunter。
再调用移除过滤器后我们也成功断在了入口处。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
我们看一下引用计数,现在是0xa。
1 2 3 4 |
|
放过去,运行到调用ExWaitForRundownProtectionRelease
之前,发现引用计数变为了0。
1 2 3 4 |
|
因此PCHunter肯定是调用了ExReleaseRundownProtection
去释放运行时保护。
Let’s try it!
关键代码如下:
1 2 3 |
|
重新编译驱动,下断。
1 2 |
|
第一次断下记录rcx
1 2 3 4 5 6 7 |
|
第二次断下查看计数,Ok! 效果和PCHunter一样了。
1 2 3 4 |
|
然后就成功移除掉了。