2023年8月11日，火绒安全收到大量用户反馈：在同时安装火绒与卡巴斯基的终端上，出现关机后反复重启、无法正常进入系统桌面的情况。经过火绒安全工程师本地排查和测试确认，此问题由卡巴斯基近期升级存在Bug导致。

升级后的卡巴斯基驱动程序（klupd_klif_arkmon.sys 版本号：2.16.1.0）会拦截火绒虚拟沙盒驱动模块正常的内部程序逻辑，导致火绒获取到错误的物理地址数据，进而发生系统异常。

此外，卡巴斯基的驱动程序（klupd_klif_arkmon.sys 版本号：2.16.1.0）还存在其他Bug，造成火绒产品其他功能也存在无法正常使用的情况。

针对本次情况，火绒安全已与卡巴斯基反馈，目前还未得到有效回复。为保障用户不受到卡巴斯基产品Bug的影响，火绒产品已采取临时规避措施，但该调整会影响火绒查杀速率和查杀率，还请用户注意。

未同时安装火绒和卡巴斯基的用户不会受到该调整影响。我们会继续与卡巴斯基官方尝试沟通以解决该问题。

另：今年4月卡巴斯基也曾因为HOOK了火绒驱动，影响到火绒产品查杀效率，该问题现已解决。

火绒安全

2023年8月15日

附文中所述卡巴斯基Bug的具体分析：

此次用户系统大面积崩溃的关键原因是因为卡巴斯基的驱动程序(klupd_klif_arkmon.sys) HOOK了火绒驱动(sysdiag.sys)IAT里的MmGetPhysicalAddress函数导致的。如下图：

卡巴斯基驱动(klupd_klif_arkmon.sys)HOOK了火绒驱动(sysdiag.sys)

在对卡巴斯基驱动(klupd_klif_arkmon.sys)进行分析后发现，klupd_klif_arkmon.sys会对火绒驱动(sysdiag.sys)进行IRP HOOK和IAT HOOK，相关代码如下：

IRP HOOK和IAT HOOK相关代码

安装IAT HOOK相关代码如下图:

安装IAT HOOK相关代码

卡巴斯基驱动会根据驱动文件信息判断是否需要进行IAT HOOK，相关代码如下图：

判断驱动是否需要进行IAT HOOK

如果驱动IAT表内存在以下函数就会被IAT HOOK，如下图：

会被IAT HOOK的函数

卡巴斯基驱动(klupd_klif_arkmon.sys) 对MmGetPhysicalAddress函数进行IAT HOOK后的相关代码如下图：

对MmGetPhysicalAddress函数IAT HOOK后的相关代码

在此能发现他会对参数一BaseAddress进行判断，相关代码如下图：

参数一BaseAddress相关的判断

在上图check_prot_physical_addr 函数里能发现有一组列表，当被HOOK的驱动程序想使用MmGetPhysicalAddress访问某一地址时会拿BaseAddress和列表内的数据进行比较，判断是否在列表的访问范围内。如果是在访问范围内会被拒绝。

通过windbg查看后得知此列表内保存的地址是所有驱动程序的开始地址和结束地址，如下图：

被保护的地址列表

此时不难看出，当火绒驱动(sysdiag.sys)在被HOOK后调用 MmGetPhysicalAddress函数访问自身程序地址时会被拒绝并返回0。

卡巴斯基的驱动程序(klupd_klif_arkmon.sys)在初始化时会保存所有驱动程序的开始地址和结束地址，对于后续加载的驱动程序会在PsSetLoadImageNotifyRoutine回调里也进行保存。最终形成一个保护表，被IAT HOOK的驱动里使用MmGetPhysicalAddress函数访问被保护的驱动程序的地址时，MmGetPhysicalAddress会返回物理地址0，后续火绒虚拟沙盒的虚拟化逻辑被破坏，进而导致系统崩溃（即使火绒判断返回的物理地址0，也会导致逻辑失败进而导致火绒反病毒引擎业务逻辑出现问题）。驱动程序获取自身镜像或分配的内存的物理地址属于正常操作，而卡巴斯基的HOOK本质上是破坏了第三方程序的业务逻辑，进而导致第三方程序或系统出现异常。

火绒驱动(sysdiag.sys)使用 MmGetPhysicalAddress获取火绒自身代码页、数据页物理地址（实现虚拟沙盒相关逻辑使用）相关代码如下图：

火绒驱动(sysdiag.sys)使用 MmGetPhysicalAddress获取火绒自身代码页、数据页物理地址（实现虚拟沙盒相关逻辑使用）

同时卡巴斯基的驱动程序(klupd_klif_arkmon.sys)也会对火绒驱动(sysdiag.sys)设备对象“\\Device\\HR::Actmon“的IRP_MJ_DEVICE_CONTROL进行HOOK，相关图如下：

设备对象“\\Device\\HR::Actmon“的IRP_MJ_DEVICE_CONTROL被HOOK

安装IRP HOOK相关代码如下图:

卡巴斯基驱动程序会根据字符串特征来判断当前驱动是否需要安装IRP HOOK，相关代码如下图：

判断当前驱动是否需要安装IRP HOOK

最后获取并保存设备对象“\\Device\\HR::ActMon“，相关代码如下:

获取并保存设备对象“\\Device\\HR::ActMon“

卡巴斯基的驱动程序(klupd_klif_arkmon.sys)安装完IRP HOOK后会拦截修改火绒驱动(sysdiag.sys)相关功能，并且造成影响，相关代码如下图：

判断IoControlCode相关代码

但这里依旧出现了BUG，”\\Device\\HR::ActMon”设备对象的IoControlCode值0x220044是属于其他功能模块的。但通过分析发现此处是在判断文件路径，而在火绒驱动(sysdiag.sys)设备对象” \\Device\\SysDiag::IOKit”里的0x220044是驱动删除文件功能。猜测他是想保护自身文件不被火绒剑删除，但他却判断错了设备对象。判断文件路径相关代码如下图：

判断文件路径

早在2023年4月卡巴斯基的IRP HOOK在代码上存在bug、导致误拦截了部分IOCODE消息、从而导致火绒部分功能失效。如下图:

早前伪码说明

此前BUG用户反馈图如下:

用户反馈