首页
课程
问答
CTF
社区
招聘
峰会
发现
排行榜
知识库
工具下载
看雪20年
看雪商城
证书查询
登录
注册
首页
社区
课程
招聘
发现
问答
CTF
排行榜
知识库
工具下载
峰会
看雪商城
证书查询
社区
CTF对抗
发新帖
2
4
[原创]腾讯游戏安全技术竞赛2026决赛题解
发表于: 2026-4-24 17:09
8521
[原创]腾讯游戏安全技术竞赛2026决赛题解
relost
1
2026-4-24 17:09
8521
# 腾讯游戏安全技术竞赛2026决赛题解 ## 驱动分析 从三环程序中可以直接提取出驱动，我个人比较习惯先分析驱动，因此直接开始  发现没有导入表，膨胀严重且驱动入口加了虚拟化，先选择hook一下常见api跑一下，但是导入表无了，这说明驱动是自己解析内核导出来调用的，不过一般驱动都会自己用MmGetSystemRoutineAddress解析几个导出来用，所以先hook一下跑一下日志来收集证据。 ```c t!DbgBreakPointWithStatus: fffff805`47c28610 cc int 3 0: kd> bp MmGetSystemRoutineAddress 0: kd> g Breakpoint 0 hit nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx ss:0018:fffff88c`37a5f5a0=0000000000040286 1: kd> dt _UNICODE_STRING fffff88c37a5f5d0 nt!_UNICODE_STRING "KdDebuggerEnabled" +0x000 Length : 0x22 +0x002 MaximumLength : 0x24 +0x008 Buffer : 0xfffff88c`37a5f614 "KdDebuggerEnabled" 1: kd> g Breakpoint 0 hit nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx ss:0018:fffff88c`37a5f5a0=9be7f70164f3dbf0 1: kd> dt _UNICODE_STRING fffff88c37a5f5d0 nt!_UNICODE_STRING "KdDebuggerNotPresent" +0x000 Length : 0x28 +0x002 MaximumLength : 0x2a +0x008 Buffer : 0xfffff88c`37a5f63a "KdDebuggerNotPresent" 1: kd> g Breakpoint 0 hit nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx ss:0018:fffff88c`37a5f5a0=9be7f70164f3dbf0 1: kd> dt _UNICODE_STRING fffff88c37a5f5d0 nt!_UNICODE_STRING "KdDisableDebugger" +0x000 Length : 0x22 +0x002 MaximumLength : 0x24 +0x008 Buffer : 0xfffff88c`37a5f5ee "KdDisableDebugger" 1: kd> g Breakpoint 0 hit nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx ss:0018:fffff88c`37a5f5a0=9be7f70164f3dbf0 1: kd> dt _UNICODE_STRING fffff88c37a5f5d0 nt!_UNICODE_STRING "KdEnableDebugger" +0x000 Length : 0x20 +0x002 MaximumLength : 0x22 +0x008 Buffer : 0xfffff88c`37a5f666 "KdEnableDebugger" 1: kd> g Breakpoint 0 hit nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx nt!MmGetSystemRoutineAddress: fffff805`47f56d20 48895c2408 mov qword ptr [rsp+8],rbx ss:0018:fffff88c`37a5f530=0000000000040282 1: kd> dt _UNICODE_STRING fffff88c37a5f5d0 nt!_UNICODE_STRING "IoDriverObjectType" +0x000 Length : 0x24 +0x002 MaximumLength : 0x26 +0x008 Buffer : 0xfffff88c`37a5f5f2 "IoDriverObjectType" [HyperCharge-debug]:D:\UGit\HyperCharge2\src\kernelsys\ddma.cpp:ddma::Init:91 :failed to find disk,status : 0xc0000225 [HyperCharge-error]:D:\UGit\HyperCharge2\src\kernelsys\main.cpp:DriverEntry:36 :#1,status : 0xc0000225 ``` 对这里面和反调试相关的api下断点再跑一遍 ```c Breakpoint 0 hit nt!KdDisableDebugger: fffff801`1f1673b0 4883ec28 sub rsp,28h ``` 发现驱动确实在调用 KdDisableDebugger 将其ret后发现驱动调用 IoDriverObjectType ，因此可能是在和驱动对象通信 hook RtlInitUnicodeString 找一下字符串 ``` ffff980b`b99975b6 5c 00 44 00 72 00 69 00-76 00 65 00 72 00 5c 00 \.D.r.i.v.e.r.\. ffff980b`b99975c6 44 00 69 00 73 00 6b 00-00 00 20 00 22 00 00 00 D.i.s.k... ."... ffff980b`b99975d6 00 00 66 76 99 b9 0b 98-ff ff 18 00 1a 00 00 00 ..fv............ ffff980b`b99975e6 00 00 b6 75 99 b9 0b 98-ff ff 37 44 49 00 6f 00 ...u......7DI.o. ffff980b`b99975f6 44 00 72 00 69 00 76 00-65 00 72 00 4f 00 62 00 D.r.i.v.e.r.O.b. ffff980b`b9997606 6a 00 65 00 63 00 74 00-54 00 79 00 70 00 65 00 j.e.c.t.T.y.p.e. ffff980b`b9997616 00 00 a2 95 45 ac d9 23-28 7f 00 00 00 00 00 00 ....E..#(....... ffff980b`b9997626 00 00 e2 05 00 00 00 00-00 00 a2 95 45 ac d9 23 ............E..# ``` 很可能是在用 IoEnumerateDeviceObjectList 扫其下的设备  果然发现命中，执行完就返回了失败逻辑，猜测其是做了某些校验 hook RtlCompareMemory 发现了比较逻辑一共比较两次，综合起来预期的返回值应当是Msft Virtual Disk  伪造返回值，让其成功通过校验试试  大量MmCopy 和 MmMapVideoDisplay（其实就是MmMapIOSpace) 后蓝屏了，传入的地址可以看出是物理地址，参数不断+0x1000扫页，驱动在拿到合适的磁盘设备后，进行了爆搜物理地址的操作 **总结一下** 驱动手动解析出一堆api，尝试获取一个 Msft Virtual Disk 的磁盘设备，成功后进行爆搜内核，现在给了驱动的一个fake返回值而蓝屏，目前不清楚驱动真正想要的设备是什么样的 根据以上的证据我找到了一个老项目 <mark class="encrypted">7c5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1N6r3u0V1i4K6u0r3k6r3c8E0j5b7`.`.</mark> 和 在运行时修改 Hyper-V 和SLAT绕过有关，先把题目往这方面想 获取 Msft Virtual Disk 的磁盘设备 可能是为了 访问/修改 Hyper-V 的某些函数，劫持某些功能，结合后面爆搜内核地址的逻辑来看，很可能存在特征码，因为固定偏移就不需要爆扫内核了。 在驱动中找相关的逻辑  发现明显的特征码扫描特征 分析一下看看命中的是什么组件 直接用我的分析系统 22631 pattern ``` 66 83 FE 01 75 0A E8 00 00 00 00 48 8B 4C 24 00 FB 8B D6 0B 54 24 00 E8 00 00 00 00 E9 ``` mask ``` xxxxxxx????xxxx?xxxxxx?x????x ``` patch_offset ``` 0x17 ``` 命中了 **hvix64 .text 的 RVA 0x23E407**   里面似乎是VmExithandle 结合ida中有关扫内核和windbg的hook日志  不难判断出驱动使用了一种类似 <mark class="encrypted">3adK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1N6r3u0V1i4K6u0r3k6r3c8E0j5b7`.`.</mark> 的技术来绕过 Hyper-v SLAT 搜索并定位相关 VmExithandle，因为现在还没有分析三环程序 我只猜测可能改了 VmExithandle 的hypercall之类的把校验逻辑藏在里面 既然大概的逻辑可以分析出来，接下来就是定位它往VmExithandle里面到底改了什么 尝试伪造磁盘信息骗过驱动 ``` eb 56 69 72 74 75 61 6c 20 44 69 73 6b 20 20 20 20 ``` 之后却发现驱动总是失败退出或蓝屏，定位不到目标区域，在这里卡了好长一段时间 后来想到既然三环程序总归是能独立加载并拉起驱动的，说明三环程序有着让驱动能真正找到patch点的能力 因此转到三环进行分析 ## 三环程序分析 从驱动入手可以基本分析得到可能是一个 Hyper-v SLAT bypass 因此首先想到三环程序可能是检测了 Microsoft Hv 搜一下 cpuid 果然如此  sub_144A06650  xor恢复结果 ```c ModuleHandleA = GetModuleHandleA("ntdll.dll"); result = GetProcAddress(ModuleHandleA, "NtQuerySystemInformation"); ``` 逻辑如下 通过动态解密字符串后获取 firmware table 相关 API 枚举 ACPI / firmware table 扫描表项签名 若发现： `DMAR` 或 `IVRS` 则返回成功 上述的两个函数检查了 是否运行在 **Microsoft Hyper-V** 是否存在 IOMMU / VT-d / AMD-Vi 相关 ACPI 表 ## （1）成功运行shadow_panel.exe 开启 Hyper-V 关掉 iommu 虚拟化 ，程序运行成功且成功加载了驱动  根据前面的分析 三环程序大概率 是有创建 VHD 的功能，不过既然能成功加载驱动并正确使用其功能，我们可以继续进行驱动的分析  字符串定位到加载驱动的逻辑，这里再system32/driver下面落地了一个随机名字的驱动，给他patch成固定的ACEDriver.sys方便我们在windbg调试时少打一条lm ## 驱动分析续 能成功启动三环程序说明对 Hyper-V 的修改是已经发生了，我们逆向一下对应的 读/写 函数所在位置，准备打断点分析   通过查找手动解析的发io请求的导入的调用位置 我们可以恢复出未被虚拟化的驱动读写函数 地址位于140003E60 其中 **ddma_sptd_transfer_page** 是底层函数，其调用的api如下图所示 ```c [I][GenericMonitorHandler():2948] Function: IoEnumerateDeviceObjectList Hooked Address: fffff8011efc64b0 RCX: ffffaf0a39f9f960, RDX: ffffaf0a425fd2d0, R8: 8, R9: ffff980bb82371e4 Return Address: fffff8012de91bca [I][GenericMonitorHandler():2948] Function: KeInitializeEvent Hooked Address: fffff8011eeaf840 RCX: ffff980bb8236fb8, RDX: 0, R8: 0, R9: 67b35c77cbf19e2b Return Address: fffff8012dea8788 [I][GenericMonitorHandler():2948] Function: IoBuildDeviceIoControlRequest Hooked Address: fffff8011ee51430 RCX: 4d014, RDX: ffffaf0a39fa1060, R8: ffff980bb8236fd0, R9: 60 Return Address: fffff8012deaa6f3 [I][GenericMonitorHandler():2948] Function: IofCallDriver Hooked Address: fffff8011ee2ef10 RCX: ffffaf0a39fa1060, RDX: ffffaf0a46767080, R8: ffffaf0a42469040, R9: f9ba63ab8ae24c95 Return Address: fffff8012deaaf53 [I][GenericMonitorHandler():2948] Function: KeWaitForSingleObject ``` 其中构造 ``` IOCTL_SCSI_PASS_THROUGH_DIRECT = 0x4D014 TransferLength = 0x1000 opcode： 0x28 = READ(10) 0x2A = WRITE(10) ``` 发 IOCTL_SCSI 请求虚拟磁盘按页读写，加载驱动后发现多了 vhdmp 设备对象  设备是 vhdmp 驱动就是用这个设备对象发 IOCTL_SCSI_PASS_THROUGH_DIRECT 进行类ddma读写  驱动爆搜内核找 hvix64的 vmexithandle 如果 MmCopyMemory 读不到 就走 MmMapIoSpace+ ddma_disk_copy_page 的类ddma读写 查引用发现还有一个使用ddma_disk_copy_page 类ddma读写 的函数  一共找到如下的ddma写入函数 ``` bp ACEDriver+0x3E4C（单页读） bp ACEDriver+0x5001（10页写） bp ACEDriver+0x96BB （底层） ``` 之后对于驱动的ddma读写函数都进行了hook来分析驱动是怎样劫持vmexit的  dump出来一堆看似有用的垃圾数据 既然驱动要劫持vmexit 必然会写hyper-v地址空间 因此hook全部的ddma写函数来分析驱动ddma写入行为  找到一个看起来像是pe的页写入，先保存下来  经过长时间的调试 终于在 HyperCharge-debug 释放完日志后的一次ddma写入函数调用中找到了目标hyperv进程  原本是0xcc的代码洞被驱动写入了一个stub ```c# ffff9600`8ff78406 50 push rax ffff9600`8ff78407 53 push rbx ffff9600`8ff78408 48bb00e0dfbf7fffffff mov rbx, 0FFFFFF7FBFDFE000h ffff9600`8ff78412 48b80030150001000000 mov rax, 100153000h ffff9600`8ff7841c 4883c803 or rax, 3 ffff9600`8ff78420 48898320030000 mov qword ptr [rbx+320h], rax ffff9600`8ff78427 0f20db mov rbx, cr3 ffff9600`8ff7842a 0f22db mov cr3, rbx ffff9600`8ff7842d 48bb0000e0ff7f320000 mov rbx, 327FFFE00000h ffff9600`8ff78437 488b03 mov rax, qword ptr [rbx] ffff9600`8ff7843a e800000000 call FFFF96008FF7843F ffff9600`8ff7843f 58 pop rax ffff9600`8ff78440 482500f0ffff and rax, 0FFFFFFFFFFFFF000h ffff9600`8ff78446 4805a038fdff add rax, 0FFFFFFFFFFFD38A0h ffff9600`8ff7844c 4881c380400000 add rbx, 4080h ffff9600`8ff78453 488903 mov qword ptr [rbx], rax ffff9600`8ff78456 5b pop rbx ffff9600`8ff78457 58 pop rax ffff9600`8ff78458 e84334fdff call FFFF96008FF4B8A0 ffff9600`8ff7845d e982ffffff jmp FFFF96008FF783E4 ``` 对比winddbg中原逻辑 发现他 call FFFF96008FF4B8A0 后 jmp FFFF96008FF783E4 jmp到了 FFFF96008FF4B8A0 的下一条指令处 这说明 call FFFF96008FF4B8A0 应该会被修改为 jmp ffff9600`8ff78406 FFFFFF7FBFDFE000当前没法访问 stub把 生成出来的 **PDPT 物理地址** 0x100153000 写到它的 +0x320 FFFFFF7FBFDFE000 无法访问，可能是hyper-v私有页表之类的 mov cr3后立刻去访问 **0x327FFFE00000 这块隐藏虚拟窗口** 0x327FFFE00000 = PML4[100] / PDPT[511] / PD[511] / PT[0] 0x320 / 8 = 100是 **PML4 第 100 项** 这说明 327FFFE00000 很可能就是这段stub带起来的逻辑，解题的关键就在 327FFFE00000 附近的可执行逻辑里面 ``` call FFFF96008FF7843F pop rax and rax, 0FFFFFFFFFFFFF000h add rax, 0FFFFFFFFFFFD38A0h ``` 随后解析了 原来Hyper-v的handle所在的地址 传到 0x327FFFE00000+0x4080  继续找下一个写入点 果然stub被改了，这说明我们之前的分析是正确的  FFFFFF7FBFDFE000这个地址我识别，在 <a href="elink@456K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1j5h3y4C8k6h3&6Y4K9h3&6W2k6i4u0A6L8X3N6Q4x3V1k6h3L8%4W2S2k6$3g2J5i4K6u0r3N6s2u0W2k6g2)9J5c8X3#2S2M7%4c8W2M7R3`.`.">Voyager</a> 这个项目中也有使用 Voyager 是一个旨在为 AMD 和 Intel 版本的 Hyper-V 提供模块注入和 vmexit 钩子的项目 这说明我们分析的驱动逻辑基本上正确  从voyager的源码来看 驱动应该也有一个映射器，这和我们前面观察到的一个类pe页相符合，驱动很可能早就将最终payload映射到了内存中 重新分析下驱动 果然在 14000E630 找到了对应的映射函数此函数 构造了新的 PT/PD/PDPT 三页页表，有明显识别pe的特征，并且映射后抹去了pe头，这解释了之前为什么只看到像pe但没找到pe头  也能通过地址确定这就是我们找的释放最终payload的函数   打断点dump下来分析一下，可以看dump的驱动和我们在运行态抓到的写入操作完全匹配  payload1偏移是 4080 与 前面提到过的 handle所在的地址 传到 0x327FFFE00000+0x4080 符合，确实有这么一个全局变量 驱动入口 只拦 CPUID VM-exit 命中 magic leaf 就自己处理 不命中就回原始 handler  分析下140001000 逻辑如下 ```c orig = payload_1; //前面stub传的原Hyper-V的vmexit handle指针 page = orig & ~0xFFF; q500 = *(u64 *)(page + 0x500); q508 = *(u64 *)(page + 0x508); r8 = q500 ^ 0x5348414430574E54; r9 = q508 ^ 0x4859504552564D58; 循环 8 轮 mixer return (in1 == r8 && in2 == r9); ```  sub_1400013A0 分析出来是 cpuid handle **0x114514分支** 直接返回： ``` *a1 = 0x01919810; return 1; ``` **0x1919810分支** 调 sub_140001000(*a2, *a4) 成功返回 [OK] 失败返回 [!!] **0xb16b00b5分支** 调 sub_140001000(*a2, *a4) 成功时输出一个解码后的 token 失败时输出 "Access Denied" 成功 token 是： ``` ShadowCore Destroyed ``` **0xCAFED00D分支** 调 sub_140001000(*a2, *a4) 失败时输出 "TRY AGAIN" 成功 token 是： ``` MISSION COMPLETE ``` 虽然现在还没分析到对应三环最终校验证据，但是可以先保存下来，之后找三环逻辑会轻松不少 #### （2）「根」使用特殊方法，对操作系统底层进行了攻击，并借此将关键核心代码隐藏了起来，分析其完整实现流程。 现在已经能完整解答题目 （2） 了 「根」的实现不是把核心逻辑直接放在 Windows 驱动里，而是先由**shadow_panel.exe**加载驱动，驱动先找shadow_panel.exe创建的vhd之后用vhdmp进行读写，然后驱动解析内核导出并扫描 hvix 隐藏页，依据版本寻找不同特征码，在我分析机上通过**vhdmp**进行**类 DDMA** 的 SCSI 读过掉slat爆扫内核物理地址定位到hvix64!0x23E41E 这一 VM-exit 关键 call 点； 随后驱动通过**vhdmp**进行**类 DDMA** 的 SCSI 读写链，搬运隐藏页正文与payload代码，并由在相同函数中构造新的PT/PD/PDPT三页页表。之后驱动在 hvix 目标页中植入 stub，并再次使用通过**vhdmp**进行的**类 DDMA**写入把原始call改成jmp stub。当 Hyper-V 后续自然执行到该 VM-exit 路径时，执行流即被导向 stub； stub 再将**0xFFFFFF7FBFDFE000+0x320**（是Hyper-v在510处的自映射）处的 PML4 项改为驱动准备好的 PDPT，刷新 CR3，使**0x327FFFE00000**隐藏映射窗口生效，并进一步call原handle把执行流切到真正的payload。最终，核心功能不再依赖原始驱动，而是在 hvix / VMX-root 的匿名驻留页中长期存在并运行，因此驱动卸载后功能仍在，模块枚举也难以发现，从而完成了对操作系统底层的攻击与关键核心代码的隐藏。 ## 三环程序分析续 分析驱动已经知道是用的特殊cpuid做的隐蔽通信，因此直接找就行  `cpuid(EAX=0xDEADBEEF, ECX=0x114514)` 的 `EAX` 必须等于：0x01919810 剩下两个cpuid似乎在虚拟化路径中，但是不影响解题，因为驱动失败提示已知 第一次 Access Denied对应B16B00B5 第二次自然对应0xCAFED00D 因此恢复处三环程序cpuid校验过程 0x114514 -> 0x01919810 -> 0xB16B00B5 -> 0xCAFED00D #### （1）成功部署条件 这里三环程序的成功部署条件也全部分析出来了 1.运行在 **Microsoft Hyper-V** 2.关掉 iommu 虚拟化，因为如果启用了 IOMMU，Hyper-V 也会通过它隐藏自身，使其免受运行时 DMA 攻击。 3.管理员运行以加载驱动 4.`cpuid(EAX=0xDEADBEEF, ECX=0x114514)` 的 `EAX` 必须等于：0x01919810 ## （4）计算出正确的终止密码，输入到shadow_panel.exe中，使得其返回成功。 ```c orig = payload_1; page = orig & ~0xFFF; q500 = *(u64 *)(page + 0x500); q508 = *(u64 *)(page + 0x508); r8 = q500 ^ 0x5348414430574E54; r9 = q508 ^ 0x4859504552564D58; 循环 8 轮 mixer return (in1 == r8 && in2 == r9); ``` 自己手动按分析出的逻辑从hvix64提出payload_1 ``` handle地址 + 0x500 q500 = 0x33574D8B48000000ULL; handle地址 + 0x508 q508 = 0x8B4C2824448948D2ULL; ``` 写个脚本 ```python MASK = (1 << 64) - 1 q500 = 0x33574D8B48000000 q508 = 0x8B4C2824448948D2 X1 = 0x5348414430574E54 X2 = 0x4859504552564D58 K1 = 0x9E3779B97F4A7C15 K2 = 0x40A7B892E31B1A47 def rol64(x, n): return ((x << n) | (x >> (64 - n))) & MASK print(f"q500 = 0x{q500:016X}") print(f"q508 = 0x{q508:016X}") r8 = q500 ^ X1 r9 = q508 ^ X2 print(f"init r8 = q500 ^ X1 = 0x{r8:016X}") print(f"init r9 = q508 ^ X2 = 0x{r9:016X}") print() for i in range(8): t1 = (rol64(r9, 13) * K1) & MASK r8 = (r8 + t1) & MASK t2 = (rol64(r8, 29) - K2) & MASK r9 ^= t2 r8 ^= (r9 >> 17) r9 = (r9 + ((r8 << 7) & MASK)) & MASK print(f"round {i+1}:") print(f" r8 = 0x{r8:016X}") print(f" r9 = 0x{r9:016X}") print() password = f"{r8:016X}{r9:016X}" print(f"secret1 = 0x{r8:016X}") print(f"secret2 = 0x{r9:016X}") print(f"PASSWORD = {password}") ``` 成功得到密码 ``` PASSWORD = C453CA26984755FD16FA037F03D99807 ``` 成功截图  ## （5） 编写keygen，使得在任意机器，任何一次运行shadow_panel.exe，都可以正确计算出终止密码。 先把驱动中全部特征码匹配逻辑 找出来，然后写keygen先获取版本号，匹配特征码匹配逻辑，寻找磁盘上hvix64.exe并处理偏移问题，之后计算出正确终止密钥。  后面还有一段amd的 ida没识别出来  特征码逻辑 ``` intelcpu hvix64.exe 1）build >= 22621 分支入口： xxxxxxx????xxxx?xxxxxx?x????x 对应 pattern bytes：66 83 FE 01 75 0A E8 00 00 00 00 48 8B 4C 24 00 FB 8B D6 0B 54 24 00 E8 00 00 00 00 E9 2）19041 <= build < 22621 pattern：0x140021070 长度：0x19 patch offset：0x13 mask： xxxxxxxxxxxxx?xxxx?x????x pattern： 65 C6 04 25 6D 00 00 00 00 48 8B 4C 24 00 48 8B 54 24 00 E8 00 00 00 00 E9 3）17763 <= build < 19041 pattern：0x140021090 长度：0x19 patch offset：0x13 mask： xxxx?xxx????xxxxxx?x????x pattern： 48 8B 4C 24 00 EB 07 E8 00 00 00 00 EB F2 48 8B 54 24 00 E8 00 00 00 00 E9 4）17134 <= build < 17763 pattern：0x1400210B0 长度：0x19 patch offset：0x13 mask： xxxxxxx?xx????xxxx?x????x pattern： F2 80 3D FC 12 46 00 00 0F 84 00 00 00 00 48 8B 54 24 00 E8 00 00 00 00 E9 5）10586 <= build < 17134 pattern：0x1400210D0 长度：0x19 patch offset：0x13 mask： xx????x?xx????xxxx?x????x pattern： D0 80 00 00 00 00 00 00 0F 84 00 00 00 00 48 8B 54 24 00 E8 00 00 00 00 E9 6）10240 <= build < 10586 pattern：0x1400210F0 长度：0x19 patch offset：0x13 mask： xxxxxxxxxxxxxxx????x????x pattern： 60 C0 0F 29 68 D0 80 3D 7E AF 49 00 01 0F 84 00 00 00 00 E8 00 00 00 00 E9 7）build < 10240 amd分支 hvax64.exe E8 00 00 00 00 48 89 04 24 E9 "x????xxxxx" ``` 直接用ai prompt： ``` 我找出了全部特征码匹配逻辑并落到了readme.md 将现在脚本改成根据版本进行特征码匹配找seed 要满足 使得在任意机器，任何一次运行shadow_panel.exe，都可以正确计算出终止密码。用py编写 ``` 完整代码见keygen.py ```python def main(argv: Optional[Iterable[str]] = None) -> int: args = parse_args(argv) if args.cpu: cpu = args.cpu vendor_text = f"manual:{cpu}" else: cpu, vendor_text = detect_cpu_from_registry() build = args.build if args.build is not None else detect_build_from_registry() if args.file_path: file_path = Path(args.file_path) else: file_path = get_windows_hv_file(cpu) sig = select_signature(cpu, build) try: pe = parse_pe(file_path) except ValueError: print(f"failed to parse PE: {file_path}", file=sys.stderr) return 1 hits = mask_search_all(pe.data, sig) if not hits: print(f"signature not found: {sig.name}", file=sys.stderr) return 1 match_raw = hits[0] patch_raw = match_raw + sig.patch_offset if patch_raw + 5 > pe.size or pe.data[patch_raw] != 0xE8: print("selected call site is not E8", file=sys.stderr) return 1 try: match_rva = pe.raw_to_rva(match_raw) patch_rva = pe.raw_to_rva(patch_raw) except ValueError: print("failed to convert raw offset to RVA", file=sys.stderr) return 1 rel32 = struct.unpack_from("<i", pe.data, patch_raw + 1)[0] handler_rva = (patch_rva + 5 + rel32) & 0xFFFFFFFF seed_page_rva = handler_rva & 0xFFFFF000 try: q500_raw = pe.rva_to_raw(seed_page_rva + 0x500) q508_raw = pe.rva_to_raw(seed_page_rva + 0x508) except ValueError: print("failed to read seed qwords", file=sys.stderr) return 1 if q500_raw >= pe.size or q500_raw + 8 > pe.size or q508_raw >= pe.size or q508_raw + 8 > pe.size: print("failed to read seed qwords", file=sys.stderr) return 1 q500 = struct.unpack_from("<Q", pe.data, q500_raw)[0] q508 = struct.unpack_from("<Q", pe.data, q508_raw)[0] part1, part2 = derive_key_parts(q500, q508) key_hex = f"{part1:016X}{part2:016X}" key_le = (part1.to_bytes(8, "little") + part2.to_bytes(8, "little")).hex().upper() ``` 运行结果 driver:19041+   不同机器运行结果  确实能兼容驱动适配的对应版本 ## （3） 编写检测代码，检测（2）中「影」核心系统攻击操作系统底层的特殊方法。 是对类 DDMa 读写的检测，自然想到监控三环设备创建虚拟磁盘和驱动向虚拟磁盘发请求等 ### 驱动侧检测 可在内核中监控以下行为： **枚举设备检测** Hook \Driver\Disk 的 IRP_MJ_DEVICE_CONTROL，识别： IOCTL_SCSI_PASS_THROUGH_DIRECT (0x4D014)，CDB0 == 0x28 / 0x2A，DataTransferLength == 0x1000，LBA == 0，blocks == 8 **vhdmp读写检测** Hook \Driver\vhdmp 的 IRP_MJ_INTERNAL_DEVICE_CONTROL，识别： vendor='Msft' ， product='Virtual Disk'，READ10 / WRITE10，xfer == 0x1000，LBA == 0，blocks == 8 **告警规则** 若短时间内在同一 Msft Virtual Disk 上出现大量： READ10/WRITE10 4KB LBA=0 blocks=8 则可判定为样本使用虚拟盘执行页级运输/DDMA-like 访问。 **测试结果**  ``` identity via='vhdmp' dev=FFFFDC0C43028050 vendor='Msft' product='Virtual Disk' exactMsftVirtualDisk=1 ``` 可以发现探测到了Msft Virtual Disk 这一vhd的选中 在 nt!KdDisableDebugger 调用前还没进入爆扫内核路径，在调用后立马出现 ``` [ALERT] DDMA-like translated 4KB page transport detected via='vhdmp' dev=FFFFDC0C43028050 vendor='Msft' product='Virtual Disk' exactMsftVirtualDisk=1 ``` 说明确实探测到了驱动发大量 IRP_MJ_INTERNAL_DEVICE_CONTROL来读写的操作 部分代码 ```c static VOID TryHookKnownStorageDrivers(VOID) { InstallHookByName(L"\\Driver\\Disk", TRUE, FALSE); InstallHookByName(L"\\Driver\\vhdmp", FALSE, TRUE); } static VOID ImageLoadNotify( _In_opt_ PUNICODE_STRING FullImageName, _In_ HANDLE ProcessId, _In_ PIMAGE_INFO ImageInfo ) { CHAR baseName[MAX_ID_LEN]; UNREFERENCED_PARAMETER(ProcessId); if (!ImageInfo || !ImageInfo->SystemModeImage) { return; } CopyUnicodeBaseNameToAnsi(baseName, sizeof(baseName), FullImageName); if (_stricmp(baseName, "disk.sys") == 0) { InstallHookByName(L"\\Driver\\Disk", TRUE, FALSE); } else if (_stricmp(baseName, "vhdmp.sys") == 0) { InstallHookByName(L"\\Driver\\vhdmp", FALSE, TRUE); } } ``` ### 用户态检测 抓： CreateVirtualDisk OpenVirtualDisk AttachVirtualDisk 方式是： Frida 注入目标进程 监控 virtdisk.dll 加载对这 3 个导出函数挂钩，打印调用参数和返回值 结果  可以看到确实有初始化 Virtual Disk 的api调用
登录后可查看完整内容
传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！
收藏
・
2
点赞
・
4
打赏
分享
分享到微信
分享到QQ
分享到微博
赞赏记录
参与人
雪币
留言
时间
wx_晨梦
为你点赞！
2026-7-16 08:37
KRIGERNM1G
感谢你分享这么好的资源！
2026-6-15 11:15
Itachi_
这个讨论对我很有帮助，谢谢！
2026-6-7 03:52
5m10v3
+10
谢谢你的细致分析，受益匪浅！
2026-4-24 18:04
查看更多
赞赏
×
1 雪花
5 雪花
10 雪花
20 雪花
50 雪花
80 雪花
100 雪花
150 雪花
200 雪花
支付方式：
微信支付
赞赏留言：
快捷留言
感谢分享～
精品文章～
原创内容～
精彩转帖～
助人为乐～
感谢分享～
最新回复
(
2
)
git_94983linye9999
雪 币：
204
能力值：
( LV1，RANK：0 )
在线值：
发帖
1
回帖
6
粉丝
0
关注
私信
git_94983linye9999
2
楼
有没有大佬有决赛的附件，求
2026-8-7 18:00
0
FUA陈探乐
雪 币：
1330
活跃值：
(603)
能力值：
( LV4，RANK：50 )
在线值：
发帖
15
回帖
17
粉丝
2
关注
私信
FUA陈探乐
1
3
楼
大佬
2026-8-9 21:16
0
游客
登录
|
注册
方可回帖
回帖
表情
雪币赚取及消费
高级回复
返回
relost
1
2
发帖
0
回帖
50
RANK
关注
私信
他的文章
[原创]腾讯游戏安全技术竞赛2026决赛题解
8521
[原创] 第五届“鹏城杯”初赛 Reverse-MDriver wp
16861
关于我们
联系我们
企业服务
看雪公众号
专注于PC、移动、智能设备安全研究及逆向工程的开发者社区
看原图
赞赏
×
雪币:
+
留言:
快捷留言
为你点赞！
返回
顶部
