潜水了两个月，由于工作的关系没有什么多余的时间发新帖了，由于临近端午准备休息一下，于是乎决定在周末搞点事情，恰逢北京今日又下起雨来，在这朦朦胧胧的雨天里给大家呈上一份Hips的高端操作，让大家燃一下。

这也是初入安全时我一直想实现的一个东西，但是由于当时技术局限，很菜，其实今天来看只是当时没有找到好的学习方法，没有办法实现很是遗憾。然而今日在团队的带领下，我改进了自己的学习方法，学会了如何有效看待问题分析问题以及解决问题。在此感谢我的导师以及leader。

这个一直想实现的东西就是用驱动拦截模块，看似很简单的一个问题但是实际上要操作起来并非易事，要看得懂代码，得先理解了这张图：

可以看到，调用API加载模块的时候最后都逃不过ntdll!ZwMapViewOfSection，最后进入系统调用然后触发模块回调，我们唯一能做的就是在模块回调里干一些猥琐的事情。直接Patch？那是不可能的，因为模块回调有限制，这时候有EProcess.AddressCreationLock的限制不说，模块还未能初始化完成，直接去搞肯定是不正确的做法。那么可以想到的是用Apc延迟去Patch模块，因为在ZwMapViewOfSection在内核中最后会返回至Ring3，在返回的过程中调用Apc去Patch这样就完美了。

话又说回来，模块回调中为每一个模块都插一个Apc？ 这显然也不现实，因此这种方法最好是有一个Ring3层进程来制定策略，指定对哪一个进程加载哪一个模块时执行哪种Patch操作。那么这就涉及到Ring0与Ring3的通信问题。说到这里就有三种方法可供选择，一种是LPC（ZwConnetPort...），一种是内核可等待对象，还有一种就是Minifilter的双向通信机制。

当然，我选择的是最后一种，现在貌似运用这种方法做通信的不多，我也没怎么接触过，一切都是从0开始，那就试试吧...

首先由Ring3进程指定策略，这里拿金山的两个模块开刀：

注册这个通信是奠定与Ring3进程通信的基础，应用层进程可以通过连接之后发送策略（即要对哪个进程的哪个模块进行监控），然后由模块回调在匹配策略之后对应用程序进行通知

这里一定要注意，FltSendMessage这个函数msdn上说的很清楚，如果RelpyData为NULL, 只要是Ring3进程调用了FilterGetMessage取得了数据，那么这个函数不会再等待。而我们需要做的是在GetMessage之后发消息给驱动，让它为LoadImage这个当前线程插入Apc，那么在模块回调中必须卡死直到应用进程调用FilterRelpyMessage回应消息，否则这一次系统调用就返回了。

Ring3进程拿到模块监控数据之后决定对该模块采取什么样的Patch措施，然后将决定结果送达至Ring0，这里我就以Patch基地址即DosHeader.e_magic为例了。

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