记录一下今年 2026 决赛过程

（1） 「影」核心系统「根」需要在一些开启了特殊特性的机器上才能部署成功，逆向找到成功部署条件！成功部署「影」核心系统，即成功运行shadow_panel.exe，控制台程序成功运行进入至输入终止密码的终端。(满分0.5分)

（2） 「根」使用特殊方法，对操作系统底层进行了攻击，并借此将关键核心代码隐藏了起来，分析其完整实现流程。（满分2.5分）

（3） 编写检测代码，检测（2）中「影」核心系统攻击操作系统底层的特殊方法。（满分2分）

（4） 计算出正确的终止密码，输入到shadow_panel.exe中，使得其返回成功。(满分1.0分)

（5） 编写keygen，使得在任意机器，任何一次运行shadow_panel.exe，都可以正确计算出终止密码。(满分2.5分)

（6） 详细描述完整的解题过程和思路，提供所有编写的程序的源代码。做到清晰易懂，操作可以复现结果。编码工整风格优雅、注释详尽。相同实现方法下，提交时间靠前者得分更高，AI可用于辅助分析，其产出的内容(代码/文档等)需明确标注并提交完整提示词和**聊天记录，**赛事方针对此项的判断具有最终解释权。(满分1.5分

有三个：

这三个条件满足之后，成功进入系统：

「根」系统采用 EPT Shadow Page（EPT影子页） 技术攻击操作系统底层。该技术利用Hyper-V hypervisor提供的Extended Page Tables（EPT，扩展页表）机制，在CPU的内存地址翻译层面实现"读/执行分离"——同一个虚拟地址的读操作和执行操作被映射到不同的物理内存页。这使得PatchGuard等内核完整性校验机制读取到的是未修改的原始代码，而CPU实际执行的却是被篡改后的恶意代码。攻击完成后，驱动自行卸载销毁，但EPT修改作为hypervisor层的配置将持续生效，实现了真正意义上的"代码隐藏"。

根据题目要求，sub_144A07540 检测环境是否满足要求：

通过两次 cpuid 的调用，第一次检测 ECX.bit31（Hypervisor Present位），第二次检测Hypervisor厂商字符串为 "Microsoft Hv"（Hyper-V），经过这里的分析，第一问的配置就出来了，需要开启 hyper-v。

把驱动提取一下，断 ControlService，然后找到驱动文件即可。

通过 pdb 文件可知，驱动原始名字为 hypercharge.sys，加载的时候会把名字随机化。

lumina可以识别少量函数，0x140001060 检测了 CPU 的特性。

0x14000BEB0 检查了当前 CPU 是 Intel 还是 AMD，决定后续EPT/NPT操作的代码路径，我的 CPU 是 Intel。

继续往下跟，驱动本身没有导入表，很多 API 都是通过 FNV-1a hash 动态解析的。比较关键的几个 hash 如下：

这里可以看出来它不是简单的驱动 hook，而是在内核里继续调用 Hyper-V 相关的设备接口。

sub_140009530 是一个很关键的函数，它封装了一次操作，大概流程如下：

其中 0x4D014 是发给 Hyper-V 设备对象的控制码，输入结构大小是 0x38。里面有页大小 0x1000，目标物理地址，还有一个操作码。

操作码这里比较有意思：

也就是：

因此它操作码只有两种，一个是 0x2A，一个是 0x28

这个就是后面隐藏代码的基础，根据逻辑：

可以大概得到 IoBuildDeviceIoControlRequest 的输入参数结构体：

既然已经分析出了 hook 的函数，那么直接上内核调试器断下看参数即可，应用层调试器断 StartServiceW，内核调试器下一个断点

断 StartServiceW 的时候驱动名已经是固定的了，所以直接写死。

分析第一次命中断点

先看看 0x28 操作的表示，rcx 指向了一个 DriverObject，对应了 vhdmp 设备，之前在用户层有见到过 create_vhd 之类的，感觉有一些关联。

不过第三个参数给了一个 nonepaged 内存，上面描述了一些字符信息。

Msft Virtual Disk 1.0，跟到 API 去看，基本也坐实是 vhd 的初始化

后面紧跟着断了一个 0x2a 的操作。

从调用栈来说，是从 sub_140003E10 调过来的

对应的也就是第一次的 EPT_Operation。

一次一次的比较慢，选择直接 inline hook 3E10和3EB0，找到关键的LOG，dump关键的页。

日志推断，它应该是 hook 了 vmexit 的 handler，中间是在做扫秒页表用特征码判断 vmexit 的操作。

从dump的结果来看，基本可以确定就是 Terminate Code 算法的页面了。

代码直接让ai分析，可以分析得到一些结果

也是终于看到了验证成功的输出。

随后发现，dump的页面中存在 payload.sys 字符，那么无疑是驱动里面应该是释放了一个 PE 文件，找PE标志位，发现 14000E630 是一个 PE loader，下断，dump，拿到完整 PE 文件。

这个注册机判定比较简单，基本就是直接算出明文去比对的，借助一下ai的神力，得到keygen。

现在最主要的是 payload1的地址不知道如何获取，陷入了僵局，只要拿到这 16 字节的数据，就可以完美还原出 key。

几经辗转还是认为特征码的判断这边有大说法，最后也认定了，AI 给的特征码是判断 NT 的结论是错误的，因为 NT 就在内存中，没必要通过 vmhd 设备去读物理内存再去比较特征码，经过一些资料的查找，最终认定关键文件 hvix64.exe，这个是 hyper-v 的关键文件。

特征码函数 sub_140018260：

根据对自己虚拟机的windows版本判断，最终可以扫描序列 65 C6 04 25 6D 00 00 00 00 48 8B 4C 24 ?? 48 8B 54 24 ?? E8 ?? ?? ?? ?? E9 得到一个结果。

找到结果，它的 SIG 扫描传了一个 len 一个 offset，我系统的分支中，len 和 offset 分别是 0x1D 和 0x13，刚好对应了一个 CALL 的指令，如图所示

最终经过一些尝试，在 call 指向的内存就是 payload1 的值。

如图选中的就是 keygen 所需的内存。

该 Key 就是对应我系统上正确的 Key 了。

上述分析的流程比较杂乱，因为是边调边写的，这里做一个完整的总结。

以上就是关于隐藏代码的具体方式。

首先在应用层通过 search pattern 给所有可能的 CPUID 指令下断点，定位关键校验位置。

输入 0x61626364656667687172737475767778，观察断点处的寄存器上下文。

此时大概可以猜出它的数据传递方式：

在 payload.sys 中可以找到对应 hook 的 VM-exit handler。

继续查看处理函数，通信逻辑会更加清楚。

由此可以得出结论：

flag 校验和 CPUID 通信逻辑至此分析完毕。

将上面手动分析出的流程用代码实现即可。需要注意的是，seed 来自 Hyper-V 原 handler 所在页的固定偏移，因此需要根据 CPU 厂商区分目标模块：

驱动根据系统版本选择对应特征码，定位 Hyper-V 中的目标 call site，再解析原 handler 地址。sub_140001000 会取该地址所在页的 +0x500 和 +0x508 两个 qword 作为 seed，经过 8 轮 64 位混合运算后得到最终需要传入的两个 64 位值。

因为我的主机是 Intel 的，所以 Intel 的分支不需要重复分析，唯一需要找一下 AMD 的，经过寻找找到了对应的逻辑。

根据代码产生的特征码应该是 E8 ?? ?? ?? ?? 48 89 04 24 E9，可以在虚拟机对应的版本找到唯一的匹配。

AMD 平台似乎没有对于 Build Number 的判断，尝试一下本机（Win11 25H2）能否命中，经过检测发现也是可以的，看来逻辑就是这样了。

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