文章总结： 文章主要介绍了安全开发中主动防御架构设计和查杀引擎设计的关键要点。作者指出了当前系统存在的通讯机制、UI架构、驱动鉴权等问题，并提出了改进方案。主动防御设计核心是将内核事件发送到R3层进行规则判断。文章还涵盖了特征杀毒、启发查杀、AI查杀等多种查杀引擎设计思路，以及下一代查杀引擎的展望。作者建议使用IOCP优化通讯机制，分离UI与查杀服务，并加强驱动鉴权机制以防止劫持。
综合评分： 85
文章分类： 安全建设,安全开发,终端安全,漏洞分析,应用安全
安全开发(终章): 主动防御架构设计/查杀引擎设计/下一代查杀引擎展望
原创
huoji
冲鸭安全
2025年11月17日 10:00
北京
前言
终于,我们迎来了整个系列的完结,在此之前请阅读之前所有内容,因为本章包含了大量信息,不可以逃课.
在上一篇中,核心EPP的功能,内核通讯<->查杀<->UI 我们已经搞定了(虽然很多问题)
因此，其他的“功能” 比如主动防御/乱七八糟的杀毒/也只是基于这个核心功能的对外扩展.因此我决定不再这些乱七八糟的功能具体细节代码上浪费时间,只说一下咋实现.
本节主要内容:
-
目前要解决的问题
-
主动防御设计
-
本地规则系统设计
-
云主防设计
-
主动防御缺陷
-
查杀引擎设计
-
特征杀毒设计
-
启发查杀设计
-
AI查杀设计
-
云杀毒引擎设计
-
目前主流查杀引擎缺陷
-
更好的查杀引擎展望
-
题外话: 为什么我们需要用EDR?
-
结语
其实本来还想写更多的,但是考虑到读者消化能力有限,还是别写太多了.
要解决的问题
这里列举一下目前整套系统存在的问题,以及咋解决,但是不给出具体解决代码了,毕竟DEMO和商业化,路差的很远.
- IOCP通讯 -> 我们的通讯机制还是队列通讯,这是异步的而且容易卡系统.为了实现主动防御，软件管控等功能，需要做IOCP的通讯，具体自己问GPT咋实现吧
- UI/查杀分离 我们现在的R3模块是UI+查杀+高权限一起的,这不是设计失误,这只是为了简化,严格来说，查杀服务，和驱动通讯的服务，应该是单独的一个exe并且以service启动,而UI只低权限用RPC/PIPE/ALPC/GRPC等手段跟那个exe通讯.而不是在一起。在一起会有几个问题,比如UI不启动功能不生效,比如不要UAC功能就不生效,不开UI就没主动防御等问题.
- UI架构,CEF过于臃肿,可能的替代方案是:QT,不过这玩意bug也多,WEBVIEW,这个不支持老版本的windows,新版本倒挺不错的.DUI这个最完美,360等一众杀毒软件都是这个做的.不过这玩意坑也多,而且对技术要求高.所以看情况来
- 驱动鉴权,内部签名. 如你所见,我们现在的驱动通讯是没签名验证的,所以会导致什么人都可以调用我们的驱动,从而成为漏洞驱动,所以,驱动要校验一下R3的内部签名,具体方法就不说了,自己问一下GPT,不过值得注意的是,校验是不是内部签名也不安全,因为有DLL注入/白加黑劫持的风险,所以还需要校验进程内存完整性或者改用PPL保护方案.否则就会被劫持.
主动防御设计
注意: 设计主动防御之前,必须要先把通讯队列做成IOCP的那种优化,否则做出来的效果会不理想
主动防御的设计,其实很简单,比你想的简单太多了,回顾上一章节,我们进程创建的时候就判断了MD5是不是黑的,如果是黑的就弹窗.而主动防御,就是把一堆信息,同样的方法塞到R3,然后R3写规则系统去判断.
当然不止进程创建,还能塞模块加载(loadimage),文件操作(minifilter),网络操作(WFP,不过注意这个只能异步,因为WFP的回调都是DPC级别的)等等的内核事件发给R3,玩的野一点的,hypervisor或者inifityhook的事件也可以发给R3.总之一句话,内核把事件发给R3.
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：冲鸭安全 huoji《安全开发(终章): 主动防御架构设计/查杀引擎设计/下一代查杀引擎展望》