前段时间因有需要我必须摘除一个MiniFilter的回调，了解的人都知道FltUnregisterFilter是移除MiniFilter的API，但是MSDN强调过这个API只能模块自身使用，于是当我尝试拿他去对我的目标驱动手时，代码进入FltUnregisterFilter后就一去不返了。

在看雪上拜读到这篇文章，文中定位了阻塞的原因：进入FltUnregisterFilter后，ExWaitForRundownProtectionRelease会检查filter对象的引用计数，按照MSDN的解释，如果不为0那么就会阻塞。作者的实验场景中此时引用计数为2，那么一定也就阻塞了。
作者再观察使用PCHunter来摘除MiniFilter的过程，发现在进入ExWaitForRundownProtectionRelease之前这个filter对象的引用计数已经变为了0，于是他猜测PCHunter使用APIExReleaseRundownProtection来减少了引用计数。因此他也在自己驱动中在调用FltUnregisterFilter之前添加执行了ExReleaseRundownProtection，然后成功了。

我使用作者这个方法在一个环境下测试成功了，但是换了一个环境后并没成功，原因是要摘除的filter的引用计数在 ExWaitForRundownProtectionRelease之前并不能到达0：
执行ExReleaseRundownProtection后进入FltUnregisterFilter之时引用计数值为0x7623：

执行到ExWaitForRundownProtectionRelease之时这个引用计数值还剩0x6：

接着进入ExWaitForRundownProtectionRelease就再次一去不返了。

所以我需要调多次ExReleaseRundownProtection吗？如果是多次那么到底应该调几次才是恰当的？我尝试寻找一个真正的具有通用性的解决办法：
我尝试连续调用ExReleaseRundownProtection，发现每次这个引用计数都会减少2：

所以如果我循环“引用计数/2”次是不是就能清零了？如下：

这样在执行FltUnregisterFilter之前，引用计数清零了：

但是继续执行后，依然阻塞了。
暂停下来看传入对象的引用计数：

可见这个计数变得很大，高位为ffff，可以猜测是不是它在为0后经过了多次递减最终导致这么大的数字，现在就需要看看 FltUnregisterFilter中发生了什么事了，关键反编译代码如下：

经过简单调试就可以发现，从刚进入FltUnregisterFilter到断点FltpWaitForRundownProtectionReleaseInternal，filter对象的引用计数发生较大的减小，a处FltpFreeInstance函数和b处FltObjectDereference执行了修改操作。
看看具体引用计数是怎么被修改的，先看FltObjectDereference：

可见InterlockedCompareExchange会将计数减2。
再看看FltpFreeInstance，由于里面调用栈较深，我这里通过访问断点来演示，在filter+8处下写断点很快就命中了，调用栈如下：

这里也是每次减计数2：

从上面给的FltUnregisterFilter精简代码可以看到，a会被循环调用，再观察下这个for循环的结构很容易猜测到这是一个_LIST_ENTRY链接的链表，偏移位于208处。
现在大概知道FltUnregisterFilter怎么处理filter对象的引用计数了：首先它会遍历对象偏移0xD0位置的链表，对每个节点使用 FltpFreeInstance最终使用nt! ExfReleaseRundownProtection来释放这个节点和它对filter对象的引用计数，这一步完成后，此时要求filter的引用计数剩且仅剩2次，然后下面再调用FltObjectDereference减去最后两次引用，这样在进入FltpWaitForRundownProtectionReleaseInternal前引用计数就清零了。
所以该怎么来恰如其分地释放filter对象？现在的问题在于，不知道在前面a处循环后到达b时还剩多少次引用计数，如本节开头我演示的实验，剩的引用计数为6，那么可以在FltUnregisterFilter前使用三次ExReleaseRundownProtection即可。但是要是再换一个环境或者当这个环境发生变化时这个计数又会变为多少？那我能不能计算在节点循环时引用计数会减少多少，然后再加上后面FltpWaitForRundownProtectionReleaseInternal之前减少的2，两者之和与总引用计数值的差值就是我需要手动调用 ExReleaseRundownProtection来减少的计数？ 或许可以，这意味着我需要逆向分析FltpFreeInstance内部实现，然后编写代码模拟其判断逻辑，才能精确计算出到底他使用了多少次引用计数，我想我没有兴趣做这件繁琐的事。这里有另一个办法：在执行 FltpWaitForRundownProtectionReleaseInternal前进行hook，调用ExReleaseRundownProtection减掉多余的引用计数值。

Hook怎么来编写？先看下fltmgr!FltUnregisterFilter中调用FltpWaitForRundownProtectionReleaseInternal处的代码长什么样：

这是在Windows 10 22H2的fltmgr.sys中的样子，可以拿上图 "1C0058627"到"1C005862D+1"部分作为特征定位位置， 然后从"1C005861F"写入hook代码，到"1C005862D"正好有14个字节的空间。由于x64下内联hook进行跳转至少需要两条指令，因此在没有特殊条件下，至少14个字节完成如下两条指令：

示例代码如下：

搜索hook点和编写hook代码部分在部分平台会有差异，自行微调。当设置这个hook后，就只需要在简单对filter对象执行一次 FltUnregisterFilter即可稳定地摘除它的回调。

这个方法在hook中减掉了多余的引用计数，但是这会不会有个问题，内核对象的引用都是有意义的，如果一个对象的引用不是由使用者在使用完毕后自行关闭，而是被其他模块在不告知的情况下关闭，那么使用者再次使用这个对象时就可能出现未知问题。所以如果注册MiniFilter的模块再次使用这个filter对象时是有可能出现BSOD的，因为我在摘除后一直没有遇到问题所以暂时还没研究这个问题。

这是一种劫持执行流的解决方案，而且如0x5点所述我还不确定绝不会出现问题，不过这里似乎还有另一个方法，就是直接编写代码模仿FltUnregisterFilter的行为，FltUnregisterFilter反编译后可以看到其实并不是很复杂，如果手动循环调用FltpFreeInstance后再在FltpWaitForRundownProtectionReleaseInternal之前根据引用计数决定释放次数，然后结合调试执行其余关键的操作。我想理论上是可行的，这种办法还能避开不同系统版本的适配性问题，但这也无法解决0x5点中提到的问题，所以或许也不是拆除MiniFilter的最正确姿势。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)