前言

当应用程序或操作系统出现漏洞时，官方一般通过补丁方式来进行升级和防止利用。在安装完补丁后，一般需要重启应用程序或操作系统，补丁才能生效。

有一些业务，是不能中断的，需要24小时保障；这就导致了即使官方发布了补丁后，漏洞也不能及时被修复。同时，由于一些操作系统已经超过了维护的生命周期（XP/Win7等），即使出现漏洞，官方不再提供补丁。

这个时候，由第三方安全厂商提供热补丁功能，继续保障系统安全，就显得尤为重要。

本文尝试对Windows系统的热补丁方案进行架构与具体实现需要的技术进行讨论，后续将视各方反馈对Linux、Java的热补丁进行进一步的研究与分享。

需求分析

一个能给客户带来价值的Windows热补丁系统，至少应具备以下功能：

1.支持对操作系统内核驱动的热补丁功能。

2.支持对不同CPU架构的二进制文件的热补丁功能（x86/x64/arm32/arm64）。

3.支持脚本化（即热补丁系统部署后，不再需要更新二进制文件，只需要更新脚本文件，即可完成对新漏洞的修复）。

4.支持回退。

其架构上至少应该包含三部分，主进程模块，注入模块，驱动模块。

按照上面提到的功能点，在技术上可以划分为4个技术问题。

1.对二进制文件的任意代码位置，任意代码长度的通用的hook。

2.对任意进程的注入。

3.对内核驱动的hook。

4.hook后的处理函数的逻辑脚本化。

下面详细讨论这几个技术问题。

对二进制文件的通用hook

1）hook方案的选择

为了保障hook和unhook的稳定性，我们需要针对不同的cpu架构，hook的目标位置的机器码，采用不同的hook策略。

a.微软系统模块提供的很多导出函数

这类函数由于微软故意预留的热补丁的坑位，我们可以百分百安全的实现热补丁的功能。

如图就是一个微软预留了热补丁坑位的函数CreateProcessW。第一条指令是mov     edi,edi，这是一条毫无意义的指令；而且这条指令的上方，还有大量的0xcc这种空白的地址空间。只需将8b ff（mov edi,edi）修改为eb f9（jmp 0x75d7f30b）,往上跳5个字节，在0x75d7f30b处填充真正的跳转地址  e9 xx xx xx xx（其中xx xx xx xx为我们的处理函数），即可完成安全的hook功能。

b.一些未导出的内部函数

在函数的入口处的几条指令，一般都是不需要重定位的（也就是地址无关的，把指令拷贝到别的地方，不需要修正指令，可以直接执行）。还是以上面的CreateProcessW为例，前5个字节的机器指令，都是位置无关的，只需申请一块内存，保存这5个字节的指令，再跳转到第6个字节执行即可。

c.其他非函数头的任意内存位置的hook

与b不同的地方有以下几个方面：

1.需要利用反汇编引擎（推荐：https://github.com/capstone-engine/capstone）

解析出目标地址的完整汇编指令，备份完整的机器指令，当超过5个字节的部分，hook时需要用nop填充掉，避免破坏机器指令。

2.备份的代码一般都需要处理重定位信息，重定位分为三类：重定位表里面的变量，导入表里面的变量，以及一些根据相对位置计算的偏移的指令（如0xe9,0xff 25等）。

2）代理函数的设计

代理函数应满足以下功能：

1.在目标函数执行前，执行onEnter逻辑。onEnter逻辑里面，可以读取和修改参数信息。

2.如果onEnter返回阻止，则不再回调目标函数，直接返回onEnter中设定的返回值到之前的调用方。

3.如果onEnter不阻止，则执行目标函数。在目标函数执行后，执行onLeave逻辑。onLeave逻辑里面，可以读取参数信息和返回值信息，也可以修改函数的返回值。

下图是X64架构的代理函数的参数保存和返回地址构造部分，其他CPU架构的原理类似，只是指令集存在一些差异。

对任意进程的注入

进程注入这个古老的话题，在终端安全领域永远也绕不开。作为热补丁这个功能来说，它的注入器，至少需要满足以下要求：

1.尽可能早的注入到进程中，确保执行hook逻辑时，不会破坏其他线程的机器指令（最好是还没有其他线程，当前只有1个线程）。

2.可以注入到开启了ACG，CFG，签名校验等注入保护的进程中。

3.需要支持从XP-Win11全版本，支持x86/x64/arm32/arm64/arm64ec这几类CPU架构的程序的注入，不需要硬编码或者动态寻找未导出函数。

4.良好的兼容性，不会与市面上的其他安全产品、虚拟化产品冲突。

虽然目前windows终端上大约有20几种注入方法，但是能达到以上的效果，只有内核APC注入这个一个选项可以实现。

内核APC注入目前网络上虽然有比较多的讨论，但却没有比较稳定的代码。这里也只是介绍一个能满足热补丁功能的内核APC注入的方案。

1.ProcessNotify的回调里面，判断是否是需要注入的进程。

2.ImageNotify里面，在APC投递中需要用到的模块初始化完以后，利用KeInsertQueueApc投递APC执行注入逻辑。

3.业务dll应该只依赖kernel32.dll,避免因为导入表的原因产生dll初始化的时序问题。

4.在开始注入前能关闭acg或cfg等保护措施，模块注入后能还原保护。

对内核驱动的Hook

内核驱动的hook和应用层的hook有几点不一样的地方：

1.由于页保护的存在，所以不能直接通过函数地址对函数中的字节进行修改。需要通过内存描述符(MDL)描述一块包含该内存区域的起始地址，拥有者进程，字节数量，标记等信息的内存区域，并通过将它修改具有可写的属性来实现对函数的读写。

2.由于多CPU的存在，修改需要挂一个SPIN_LOCK来防止CPU的切换。大致代码如图：

3.由于被hook函数与代理函数的间距一般都会大于4GB，所以不能用0xe9这个jmp指令来hook。一般推荐push eax, xx xx xx xx;call eax这种方式来hook。

hook后的代理函数脚本化

一般考虑使用JS或者lua脚本来做这个事情，像python这种就不太合适了。但是由于希望驱动层和应用层采用相同的处理方式，更加推荐使用lua脚本来控制逻辑，因为无论是quickjs或者v8，想要移植到内核都不是件容易的事情。如果不考虑内核补丁，明显JS用起来更加简单一点。

脚本需要在原语言的基础上，提供以下功能：

读取和修改参数信息。

读取和修改寄存器信息。

读取和修改返回值信息。

动态调用系统中的一些函数。

至于脚本绑定，以及如何在c++代码中直接运行JS或者lua的脚本，可以参考腾讯的一个开源项目：https://github.com/Tencent/ScriptX。代码写得非常优雅，而且性能还不错。

实现了以上功能后，一个Windows平台的热补丁框架就已经初具雏形。后面我们再继续掰扯Linux平台以及Java虚拟机的热补丁方案。