本文为外挂巡查系列第一篇文章，我们将以每月一款的频率分析盘错于各热门游戏的外挂，深入剖析技术原理

本样本将分三次披露，第一篇为概览，第二次为特别技术详细分析，第三次为技术对比溯源及作者追踪，没错，这次我们会直接追踪作者

> 鉴于某些人已急不可耐，我们决定提前公布第三部分的部分内容，该外挂作者经调查为c27K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4y4o6l9I4x3e0V1&6x3U0j5J5
后面为QQ，曾于腾讯就职，我们暂时不想扩散实际有用的样本，欢迎ace及执法机构与我们联系，我们会提供内嵌驱动与证据
如何是利益相关方也欢迎拿出证据

> 截至目前该外挂已关闭新用户注册，但仍保留存量用户并提供非法服务，明显的是该作者认为AXE并无能力对其进行检测

Loader.sys是mapper驱动，第二篇会放出内嵌在里面的真实驱动

本外挂自去年11月被采集，至今已将近一年，外挂通过高度严格管理与特殊反分析技巧，很难被反作弊分析与处理，实现了长期稳定与巨额盈利

外挂后端登录地址为：ba6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1x3o6M7^5y4q4)9J5k6h3y4G2L8g2)9J5c8V1y4S2M7X3c8Q4x3V1k6x3L8$3N6A6L8R3`.`.

所有版本都由网页端卡密注册下载，内置一个网页版本的聊天室，体现出高度定制性，但其后端协议存在漏洞，可通过技巧绕过验证（将在第三部分披露），经核实目前日激活量200-300，激活卡总数量超过2万张，结合聊天室内容与部分外挂群组信息交叉验证，作者盈利2000万以上（第三部分我们会放出详细证据）。

附件中bat为启动文件，loader.sys为mapper驱动（混有大量hv字样内容，经分析无实际作用，仅为干扰分析）

假设你是反作弊分析人员。样本刚拖进 IDA，Wireshark 还开在旁边。对大多数驱动，这只是分析的开始；对这个样本，你打开工具的动作已经进入了它的业务流程。

进程名命中本地名单或服务端规则后，sub_1400648C0 会把目标交给 sub_14007F370。它不急着退出，而是先从 DWM/WDDM DirectX 上下文同步生成 JPEG，把画面冻进全局缓冲区。Worker 随后采集进程、驱动、网络和 Windows 历史痕迹，把截图、诊断与冻结报告送往 /reportData。父路径最多给它 90 秒；窗口耗尽后，代码再替换 IDTR、访问 CF9，尝试让机器失去现场。

更麻烦的是，这条“发现—截屏—取证—上传—掀现场”的链不在普通 WDM 回调里。它背后有 Intel VMX 和 AMD SVM 两套 L0，核心决策待在 Host；需要 Windows API 时，再通过 Guest API Bridge 把任务送回 Guest。

故事真正的入口反而很不起眼：load.bat，只有 173 字节。

表面上看，它只是让 rundll32 调用 load.dll 的导出函数 R。继续往后翻，load.dll 里却同时摆着：

再把 RegCreateKeyW、RegSetKeyValueW、RegDeleteKeyW 等导入和目录中的 Loader.sys 放到一起，外围链路的意图就很难装作没看见了：先争夺开机阶段的加载时机，再由 Loader 把真正的业务驱动映射进内核。

能够直接确认的是，load.bat 调用了 load.dll,R；load.dll 具备创建驱动服务项所需的字符串和注册表 API；Loader.sys 与提取出的 inner driver 存在投递关系。loader.sys通过注册为boot驱动于ACE-BOOT前启动避开预启动监控

真正值得看的，是已经提取并修复 PE 元数据的 dumped3_inner_ida_fixed.sys。我最初也把它归进“套 VT 的内核挂”一类，继续往下追才发现，这个标签太轻了：Intel 侧不只起了 VMX L0，还接管了 Guest 的整套 VMX 指令；AMD 侧另有 SVM/VMCB/NPT 后端；再往上，是共用的 Host Bridge、外挂业务、主机取证和后端风控。

它不是在外挂驱动里加了几条反调试，而是给外挂搭了一层自己的虚拟化操作系统。

三万多个函数很容易把人拖进细节。先不绕路，把决定这个样本威胁等级的六件事摆出来。

它不是 Intel-only，也不是检测到 AMD 就退回普通内核路径。

sub_1401163C0 查询 CPUID 0x8000000A，按逻辑处理器准备 VMCB、NPT 和 #VMEXIT 分发表；启动桩设置 EFER.SVME，执行 VMSAVE，写入 VM_HSAVE_PA，最后进入 VMLOAD → VMRUN → VMSAVE 循环。SVM #VMEXIT 进入 sub_140116A20，再与 Intel VMX 路径汇合到同一套 Host 业务层。

能落锤的是 AMD SVM L0 与 NPT。Nested SVM 不能顺手认领：Guest 的 VMEXIT_VMRUN (0x80) 当前仍走默认 #UD 注入。

看到 VMLAUNCH 字符串不算 Nested，替 Guest 维护第二套 VMCS 才算。

VM-exit 表中，VMLAUNCH 指向 sub_14012A310，VMRESUME 指向 sub_14012AC10，两条路径最终进入 sub_140126C20。这个函数含 223 条 VMX 指令：VMREAD 保存原状态，VMCLEAR/VMPTRLD 切换 VMCS，VMWRITE 合成 Guest、Control、Host 字段，最后再次 VMLAUNCH。

再加上 VMPTRST 对主、次 VMCS 的判断和双分发表，Intel Nested VMX 的 Guest 指令接管、状态机、字段搬运和嵌套 VM-entry 已经闭环。

样本甚至把“我现在是不是在 Host”写进了自己的诊断报告。

sub_14011FB10 读取 IA32_GS_BASE (0xC0000101) 或执行 RDGSBASE；CurrentIsInHost 的赋值就是：

在当前 IDA 数据库中，这个环境判定有 515 个交叉引用。GS Base 为零时，代码处在样本定义的 Host 语境；作弊状态、内存翻译、取证与上报决策都以这条边界为中心展开。

VMX root/SVM Host 不能把 Windows 内核 API 当普通本地函数调用，样本的办法是把调用“送回去”。

Guest API Bridge sub_140121CD0 在当前数据库中有 259 个交叉引用。它保存目标函数和最多 15 个参数，翻译 Guest 栈页，写入返回桥，改写 Guest RIP/RSP；翻译失败时，还会按当前后端设置 VM-entry/VMCB 异常字段，把 #PF 注回 Windows。API 在 Guest 执行，调用的编排权仍在 Host。

IDA、x64dbg、Wireshark 或 BurpSuite 命中后，第一步是同步留住画面。

sub_14007F370 立即调用 sub_1400943C0，从 DWM/WDDM DirectX 上下文取出像素，重排成 RGB，以质量 85 编码 JPEG。Worker 随后把 capture.jpg 连同 diag.txt、冻结报告上传到 /reportData。

诊断内容还覆盖 UserAssist、AppCompatCache、MuiCache、AppSwitched、BAM、Recent、Prefetch、进程、驱动、服务、网络、QQ/MSDK、BootState 和 SMBIOS。工具退出了也不代表痕迹消失：它还会翻 Windows 的历史账本。

PsCreateSystemThread 返回 0 代表成功，这个条件在这里非常关键。

Worker 创建成功后，父路径等待 90 秒，把时间留给截图、诊断和冻结报告上传；Worker 自己完成或放弃上传后再等 3 秒。随后代码替换 IDTR，向 CF9 Reset Control Register 写入复位值，并保留疑似 KeBugCheckEx 的后备路径。

所以这不是上传线程和蓝屏线程的随机竞速，而是一扇有上限的证据外传窗口：先把现场带走，再把现场掀掉。

先别急着追 VMXON 或 VMRUN。这个样本的第一处误导，是让一条只有 173 字节的批处理看起来像全部入口；真正决定威胁等级的代码，还隔着 load.dll、Loader.sys 和一层被提取修复的 inner driver。

整个投递关系可以先画成这样：

先把两条证据边界钉死：

文件本身只有约 6.69 MiB，虚拟映像却超过 232 MiB。主要原因是 .data 的虚拟范围异常庞大：

文件尺寸和虚拟映像的巨大落差，已经把保护器和运行时状态区暴露出来；.vbv0 更不是普通代码节，入口下一跳就会钻进去。接下来如果把这层软件虚拟机和硬件 Hypervisor 混为一谈，整篇分析都会从术语上跑偏。

DriverEntry 短得近乎挑衅：不初始化设备、不注册回调，只把分析者往下一层跳板推。

再跟一层：

入口从正常 .text 很快跳进 .vbv0，可以确认样本使用了 VMProtect 一类的软件代码虚拟化保护。这里最容易出现一个术语事故：看到 VMP 的“虚拟机”，又看到 VT-x 的“虚拟机”，最后把两者一起叫“嵌套虚拟化”。

实际上，这个样本里同时存在四件必须分开的东西：

当前文件完成的是 PE 容器级修复：IDA 能正常装载，VMP 入口能够识别，但这绝不等于所有虚拟函数都已语义级还原。好消息是，真正决定能力边界的 Hypervisor、反分析和上报逻辑，大量落在可读的 .text 中。门帘不用整块拆掉，我们已经能从门缝里看见 Intel 与 AMD 两套硬件后端。

只搜 VMX 指令，会得到一个看似完整、其实漏掉半边的答案。这个 inner 没有要求用户必须用 Intel：它先按 CPU 能力分流，再让 VMCS/EPT 与 VMCB/NPT 两条路径汇入同一套 Host 控制面。

样本中直接残留了：

以及一批高度一致的 [hv] 日志：

公开的 jonomango/hv 是一个轻量级 x86-64 Intel VT-x Hypervisor。样本显然复用或深度改造了这套基础设施；但后面看到的 Nested、Host 调用桥和业务控制面已经远超一个原样搬运的开源 Demo，所以本文只把上游当作设计背景，不拿上游代码代替样本证据。

sub_14012E580 是最直观的启动函数：

正常启动后，Windows 从 L0 的视角变成 VMX non-root Guest。VM-exit 入口 sub_14012D830 会读取：

然后按 exit reason 进入 funcs_14012D906[]。它不是只有一个 VMCALL 后门，而是一套完整的 VM-exit 控制面。

如果分析停在这里，最多只能说它有一个 Intel L0 Hypervisor。但样本没有把 AMD 用户扔回普通驱动路径：同一套 Host 控制面下面，还压着一套完整的 SVM/VMCB 后端。

如果只在二进制里搜 VMXON、VMREAD、VMWRITE，结论会直接错一半。样本用 byte_14828F2FA 区分两套硬件后端：该值进入 Intel 分支时，代码读写 VMCS；进入 AMD 分支时，同一批函数改为直接读写 VMCB，并通过 sub_1401E0327 回到 VMRUN 循环。

先把整个分叉画出来：

这张图里最重要的不是“同时支持两家 CPU”，而是两套硬件入口最终汇入同一套 Host 业务层。换了厂商，底层控制结构从 VMCS/EPT 变成 VMCB/NPT，外挂的取证、截图和上报逻辑并没有降级。

sub_1401163C0 在 0x1401164B2 执行：

0x8000000A 是 AMD 的 SVM Revision and Feature Identification 叶。样本保存返回的版本、ASID 数量和能力位，然后按逻辑处理器准备 AMD 后端所需的大块状态、VMCB、Host Save Area、NPT 与拦截位图。

真正把处理器推进 SVM 模式的代码位于 0x1401161E2 一带：

按照 AMD 的定义，EFER.SVME 是 SVM 总开关；VM_HSAVE_PA 保存一块 4KB Host State Save Area 的物理地址，第一次 VMRUN 前必须设置。样本不仅把两个条件都做了，还先用 VMSAVE 保存扩展 Host 状态，随后切换自己的 GDT/IDT 和 Host CR3，在 0x14011634D 调用 0x1401E0280 进入 SVM 汇编桩。

sub_1401E0288 只有 159 字节，却是 AMD 后端的心跳：

VMRUN 从 RAX 取得 VMCB 物理地址并进入 Windows Guest；发生 #VMEXIT 后，处理器回到下一条 VMSAVE，样本保存寄存器现场，把控制交给 sub_140116A20，处理完再恢复现场继续 VMRUN。

sub_1401E0327 则是从 Host 业务代码返回 AMD Guest 的恢复入口。更关键的是，它的调用者里直接出现了 sub_140121670、sub_140121900 和 Guest API Bridge sub_140121CD0。换句话说，AMD 后端不是一座孤岛：Host 里编排 Windows API、注入 Guest 异常、翻译 Guest 页表的那套控制面，确实能沿 SVM 路径回到 Windows。

sub_140116A20 从 VMCB + 0x70，也就是 a1 + 0x6070 读取 EXITCODE。退出原因小于 0x404 时，它用 EXITCODE 直接索引 funcs_140116AB3：

表基址是 0x14D293230。初始化函数先把 1028 个槽位全部填成默认 handler sub_140116B60，随后再覆盖真正支持的退出类型：

NPT 也有完整落点。sub_140115620 构造分层页表并建立大页映射，sub_140116B70 根据 NPF 的 EXITINFO 判断访问类型和映射状态，sub_140115FC0 在需要时更换 NPT 根、清理 VMCB 控制位并请求 TLB 刷新。

这里要把两个 “Nested” 拆开：Nested Page Table 是 AMD 的二阶段地址翻译，相当于 Intel EPT；它不等于 Nested SVM。 有 NPT，只能证明 L0 在翻译 Guest Physical Address，不能证明 Guest 里的 L1 还能再次执行 VMRUN 管理 L2。

判断 Nested SVM 最直接的办法，是看 Guest 执行 VMRUN 后，L0 有没有模拟下一层 VMCB。AMD 为这个事件定义的 EXITCODE 是 0x80，对应槽位为：

当前数据库中，0x14D293630 没有专用 handler 覆盖；它仍然是初始化阶段填入的 sub_140116B60。这个默认函数只做一件事：

0x80000306 解码后是 valid=1、type=3、vector=6，也就是向 Guest 注入 #UD。相邻的 VMLOAD、VMSAVE 等 SVM 指令退出同样没有发现一套类似 sub_140126C20 的 VMCB 搬运和嵌套 VM-entry 逻辑。

因此，这里的证据等级必须分开写：

AMD 后端已经足以把 Windows 放进 SVM Guest，并承载同一套 Host 控制面；但接下来要讲的真正嵌套虚拟化闭环，目前只在 Intel VMX 路径成立。

反作弊视角： 不要把 VMXON 当成 VT 外挂的唯一入口。CPU 厂商判断、EFER.SVME、VM_HSAVE_PA、VMRUN/VMCB 与 NPT 同样应进入驱动静态特征和虚拟化异常遥测，否则 AMD 机器会成为天然盲区。

上一节已经证明 AMD 后端能执行 VMRUN，却也证明 Guest VMRUN 会落入默认 #UD。真正跨过“L0 能跑”与“L0 能替 L1 再管一层”这道门槛的，是 Intel 路径。先把层级画清楚；VMP 软件 VM 不在图里，因为它是代码混淆，不是硬件虚拟化层。

Intel 定义的基本 VM-exit reason 中，20 是 VMLAUNCH，24 是 VMRESUME。把 funcs_14012D906 按 8 字节指针解析后，相关条目如下：

一个 L0 如果只想自己使用 VT-x，根本不需要为 Guest 的整套 VMX 指令准备 handler。这里从 VMCLEAR 到 VMXON 几乎齐全，已经是非常强的 Nested 信号。

sub_14012A310 会检查虚拟 VMCS 状态。状态允许时：

sub_14012AC10 则是：

错误码 4、5 与 Intel VM-instruction error 的语义相符。也就是说，它不仅拦住了指令，还在模拟 VMCS 生命周期和失败行为。

两条 handler 最终进入 sub_140126C20。这个函数有 751 条机器指令，其中搜索到 223 条 VMX 指令。它先从当前 VMCS 读出大批字段，覆盖：

中间最关键的切换只有两条，却非常扎眼：

切换后，它又用大量 VMWRITE 把刚才保存、合并后的字段写入 secondary VMCS。若是首次进入，函数尾部直接：

这不是“为了兼容 VMX 而留了几个字符串”，而是在真正构造下一层可运行的 VMCS。

总分发器 sub_14012D830 还存在以下逻辑：

这一步把证据补齐了：它知道当前退出来自 primary 还是 secondary VMCS，并为 secondary 状态准备了额外分发层。

到这里，Intel Nested VMX 才能写成 已确认：Guest VMX 指令接管、虚拟 VMCS 状态机、主/次 VMCS 切换、字段合成和嵌套 VM-entry，五个环节都由样本直接闭环。这个结论绝不外推到 AMD Nested SVM；下一步更值得追的是，这个 L0 为什么需要替业务代码频繁调用 Windows。

Hypervisor 能拦截 Windows，不代表它能脱离 Windows。最反常的地方在于：样本把核心控制流留在 L0 Host，却把 Windows 内核当成一组需要时才调度的系统服务。

严格来说，ZwQuerySystemInformation、PsCreateSystemThread 仍必须在 Windows Guest 语境中执行；Intel VMX root 或 AMD SVM Host 都不能把这些内核代码当成本地普通函数随便调用。本文所说的“Host 主路径”，准确含义是：状态管理、内存翻译和业务决策长期驻留 L0；碰到必须依赖 Windows 的动作，再通过后端适配把调用编排回 Guest，完成后返回 Host。

正常 x64 Windows 内核里，GS Base 指向每 CPU 的 KPCR，不会是 0。公开上游 jonomango/hv 的 Host VMCS 初始化恰好执行：

样本的 BootState 又把 GS_BASE == 0 明确定义成 CurrentIsInHost=1。上游设计、样本判断和诊断输出三者互相吻合。

拿一个真实调用点看最清楚。很多函数都会先解码一个 Windows API 地址，然后写成：

这套双路径不只出现在 Hypervisor 初始化函数里。BootState 查询、内存分配释放、线程创建、延时、系统信息查询等大量位置都在使用。

sub_140121CD0 接收一个目标 API 地址和最多 15 个参数。核心流程可以压缩成下面这张图：

具体证据包括：

这座桥把架构关系彻底翻了过来：Host 不是 VM-exit 时看一眼寄存器的薄层，而是业务代码的主要运行环境；Windows 被降成了“需要系统服务时临时唤醒的 Guest 执行端”。后文所有“Host 主路径”都采用这个严格定义，不会把实际在 Guest 执行的 Windows API 冒充成 Host 本地调用。

反作弊视角： 单看驱动对象、回调和导入表，很可能只看到被 Host 临时借用的 Windows 外壳。调查时应把异常 Guest RIP/RSP 改写、跨地址空间栈构造、CR2/#PF 注入，以及 VMRESUME/VMRUN 前后的调用编排串成一条行为链。

两套 L0、Nested VMX 和 Guest Bridge 很容易让人忘记最基本的问题：设计者费这么大力气，究竟要保护什么？inner 里的明文配置没有绕弯子：

图形状态诊断尤其详细：

这也解释了后面的截图为什么不需要再走一套 GDI 桌面抓屏：样本本来就掌握着 DWM/DirectX 的 SwapChain 与缓冲区。

所以，Hypervisor 不是脱离业务的技术展示，而是自瞄、雷达、内存访问和内核绘制的隐蔽底座。功能面确认以后，下一条线就顺理成章了：它如何判断是谁在盯着这套控制面。

如果反分析只靠 14 个写死的进程名，改名就能绕过去。这个样本把名单拆成两层：驱动内置一批立即生效的目标，服务端再下发动态特征和额外取证动作。

off_140225370 指向 14 个字符串。sub_1400649F0 会取得进程映像名，逐项执行不区分位置的子串搜索，命中后把数组索引当作 feature code 交给 sub_1400648C0。

关键循环非常朴素：

这里没有什么“AI 检测”，胜在覆盖面直接：调试、反编译、内存修改、抓包、代理，一个都不想让你开。

sub_14007B900 会以 banned-features 为动作名请求配置，成功后进入 sub_140063FE0。解析结构为：

featureType 的静态行为可以分成三类：

进程名匹配函数 sub_140063E30 使用标准 64 位 FNV-1a：

FNV-1a 只是快速哈希和桶定位，不是加密。厉害的不是哈希，而是后面的运营能力：本地驱动不升级，服务端也能换一批要抓的人。

动态规则解析完成后，sub_14007B900 紧接着调用 sub_140078420。后者构造 reportType=reportData，以 application/octet-stream 交给通用上传函数 sub_140076D60。样本还保留了：

因此它不是只给后端发一句“发现 IDA”，还为某些远程特征准备了原始二进制证据通道。

样本中能直接找到：

ACE 字符串说明它明确知道对手是谁；直播/录屏进程则更像产品风控的一部分。部分分支仍需动态验证，不能只凭字符串把所有进程都写成“命中即重启”。但本地表、远程规则和 Type-4 二进制回传已经证明：它面对的不是一次性调试，而是一套可以持续运营的反分析策略。就算工具已经退出，第二张网还在等着翻历史记录。

删进程、改文件名、关掉 IDA，现场就干净了吗？sub_14004FE60 给出的答案是否定的。它不是简单枚举当前进程，而是一个把 Windows 主机当取证现场的统一诊断编排器。

它为每个采集器记录：

然后把结果汇总成一份大诊断缓冲。Worker 紧急路径和正常会话路径都会调用它。

这张表里，前六项尤其狠。它们都是 Windows 取证里常用的历史痕迹。分析人员把 ida.exe 改名、用完后退出，甚至临时清掉当前进程，也不代表这些痕迹会一起消失。

服务/驱动记录格式为：

进程枚举还会统计：

也就是说，它不只是“扫进程名”，而是在整理一份可以交给运营人员复核的环境报告：路径、签名者、启动类型、最后写入时间都尽量带上。

sub_14004D8B0 输出：

普通外挂只需要找到游戏 PID；这个样本还要知道自己是不是 Boot 驱动、L0 是否启动、当前代码是否在 Host、HVCI 与测试签名是否开启。它收集的不是“游戏状态”，而是一份可以回放分析环境的档案。接下来那张截图，则把这份档案从文字证据变成了现场画面。

最容易看错的，不是 JPEG 编码，而是动作顺序。样本不是等异步线程慢慢判断后再截图；命中发生的同一条同步路径里，画面已经先被冻结，Worker 只负责把它和诊断材料一起送出去。

命中工具后，sub_14007F370 在创建 Worker 之前就执行：

这里的 qword_14026A988 就是诊断中打印的 DirectX 状态对象，内部包含 SwapChain、D3DDevice、D3DDeviceContext、RenderTarget 等指针。检测瞬间先同步生成 JPEG，再启动异步上报，能够避免分析人员在 Worker 真正运行前关闭窗口或切换桌面。

sub_1400943C0 先调用 sub_140094F80 从 DirectX/WDDM 上下文抽取原始像素、宽和高。随后按像素执行近似下面的转换：

调用签名、回调写出方式和最后一个参数 85 都符合 JPEG 内存编码器的形态。最终输出不是 BMP，也不是屏幕句柄，而是一块可以直接作为 image/jpeg 上传的内存。

常规路径 sub_140077F20 也会调用同一截图函数并上传 reportType=ss，说明截图既可周期执行，也可在检测命中后紧急执行。

旧式分析很容易在这里看错一个条件：Windows 的 PsCreateSystemThread 成功返回 STATUS_SUCCESS，数值就是 0。样本代码是：

所以真实流程是：

90 秒不是为了拖延分析人员，而是给证据外传设定一个最长窗口。正常情况下，Worker 完成上传后会先进入自己的 3 秒延时和终止链；如果 Worker 卡住，父路径最多等 90 秒后兜底。

通用上传函数 sub_140076D60 大小约 0x11B8，手工拼接 multipart body。固定 boundary 为：

核心字段如下：

重建后的截图请求大致为：

字段顺序会随报告类型变化，但 reportType 是字段值，附件 part 名固定为 file，这一点可以从拼接代码直接确认。

服务端响应还包含 needSs、needDiag、needOpenId、signatureWindowSeconds、expiresAtUtc 等字段。截图和诊断并非只能由本地固定逻辑触发，后端也能参与控制。到这里，“发现分析者”已经变成一条完整的取证外传链，而不是普通的退出保护。

反作弊视角： 内存中的 JPEG SOI、capture.jpg、固定 multipart boundary、ssfreeze、freezeReason 与 /reportData 应组合观测；单独命中任何一项都可能误报，按同一进程/会话时序关联后价值会陡增。

登录、配置和上传如果分开看，只像常见的外挂发卡系统；把动态名单、冻结原因和三类附件放回同一条调用链，后端的第二重身份才会露出来。

/api/software、banned-features 和动态 features[] 让后端可以更新检测策略；/reportData 接收截图、诊断和二进制证据；freezeCard、freezeReason 又把处置结果与软件会话绑定。它的后端显然同时承担认证、配置和反分析风控。

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。