[原创]KCTF2026 - 第四题：未时·车流困城题解（AI）-CTF对抗-看雪安全社区

## Summary

32 位 PE，但真正的逻辑经 **Heaven's Gate** 跑在 x64 长模式，代码藏在可执行的 `.data` 段里，
外面裹着 jmp 链、计算跳转、常量掩码，**特权指令当 VM opcode 用**（`in`/`out` 触发 #GP，
`int3` 触发 VEH，由 exe 导出的 `Warning` 函数统一分发）。

注册码校验是五层套娃：

![图片描述](upload/attach/202608/1085268_GFQZ2YGP3H7AJPA.webp)

三个卡点，都不在算法本身：

1. **环境门是父进程名检查** —— 必须由 `explorer.exe` 拉起
   否则 `PEB->BeingDebugged` 停在 `0x1A` 而非 `0x5A`，VM 字节码解密成垃圾，
   **任何注册码都 Failed**。
2. **MengXinQiuFangGuo 是换了 S 盒的 AES-128 解密**（题面"十六层嵌套网络"）。
   而那张 S 盒由 `BeingDebugged` 参与生成，取 `0x40` 还是 `0x5A` 得到**完全不同的两张表**。
3. **尾部 NUL 填充不能跨过一个完整的 AES 块**（填充 ≤ 16 字节）。
   样例文本 6897 → 总长 6912，填充 15。`KCTF` 的根文本只有 6891，
   照抄总长 6912 就是填充 21 > 16，被 gate2 拒掉。
   最省事的修法是把总长取成「≥文本长度的最小 16 倍数」→ **6896**（填充 5）。

## 题目结构

`main` 的骨架一屏可见 —— 五次调用全部经同一个trampoline函数 `sub_4010E0`，
第 4 个参数是 x64 函数指针：

![main 的五段调用链，五次 call sub_4010E0 分别传入 DayDayUp / unk_7A6920 / MengXinQiuFangGuo / unk_8386B4 / GoodGoodStudy](upload/attach/202608/1085268_KCY7QAKXFEQXAPQ.webp)

*图 1　`main` 全貌。红框 ①～⑤ 就是五层套娃。
注意 ⑤ 之前那一大段 `mov eax, offset unk_4D40A0 / unk_7A4448 / unk_4240A0` + `mov [ebp+var_28], 0Bh` ——
把**三张表的指针和常数 11**打包成一个结构体传给 `GoodGoodStudy`，
这三张表分别是 CSR 的 data、VM 字节码、CSR 的 row_ptr，11 = 多项式系数个数（10 次首一多项式）。
另外 ② 和 ④ 后面各跟一个 `test eax,eax / jz loc_4013DA` —— 两个提前失败出口，
后面会看到它们其实不是"校验函数"，而是伪装成函数的异常陷阱。*

序幕就是一发 anti-VM，而且它**同时承担了初始化职责**：

![main 序幕的 VMware backdoor 探测：mov eax,564D5868h / in eax,dx / jmp 跳过 int3](upload/attach/202608/1085268_9MH8J5PYC3YX34M.webp)

*图 2　`in eax, dx` 在 ring3 必定 #GP。真机走 SEH → `int 3` → VEH，
VEH 里那次隐藏初始化把 `.data` 段建成可执行、注册 `Warning` 处理器；
而在 VMware 里 `in` 不 fault，直接 `jmp` 跳过 `int3`，初始化不做，后面全是 decoy。

trampoline 本体只有 10 条指令：

![sub_4010E0：pusha/pushf 后取四个参数，push 33h; call $+5; add [esp],5; retf 切入长模式](upload/attach/202608/1085268_QSFUBNCV2HX8K4J.webp)

*图 3　Heaven's Gate。`push 0x33` 压的是 64 位代码段选择子，
`call $+5` + `add [esp],5` + `retf` 把返回地址改成下一条指令再远返回，于是 CPU 切到长模式继续执行。
切过去之后是 `mov rcx/rdx/r8` ← 前三个参数、`call r9` ← 第四个参数（x64 函数指针）。
所以 `sub_4010E0(a,b,c,fn)` 的语义就是 `fn(a,b,c)`，只不过 fn 跑在 64 位。*

最终判定：

![0x4013B0 起：mov ecx,offset aFailed / mov eax,offset aSuccessful / test esi,esi / cmovnz](upload/attach/202608/1085268_52RPNTAD4X4V7VE.webp)

*图 4　`GoodGoodStudy` 的返回值在 `esi`，非 0 才 `cmovnz` 选中 `Successful!`。
没有任何花活，说明**真正的校验全在 ⑤ 里**。*

## 五层拆解

### ① DayDayUp —— 自定义字母表 base64

`serial` 去掉头 `lI|0O` 和尾 `Il1|!` 后，payload 每 4 字符解成 3 字节：

```
ALPHABET = "Il1|!ijJL`oO0QDSs5$Zz2B8gq96nNmMWwUuVvRrPpCc({tT+7xXKkYyAa4Ee3FH"
v_i  = (REV[payload[i]] + 27*i + 51) & 0x3F      # 位置相关旋转
out  = 标准 base64 4→3 打包(v_i)
返回 declen = 3*(n/4)
```

**它的输出是白噪声，不是明文**（熵 7.977 bit/byte，256/256 个字节值都出现）。
我一度以为解码结果就该是整数文本，被这一步误导了很久 —— 真正的明文在 ③ 之后。

### ②④ 两个 gate —— 伪装成函数的异常陷阱

`unk_7A6920` 和 `unk_8386B4` 各自只有 **2 个字节**：

```
0x7A6920:  ED C3      in  eax, dx  ; ret
0x8386B4:  EE C3      out dx, al   ; ret
```

`in`/`out` 在 ring3 触发 #GP（`STATUS_PRIVILEGED_INSTRUCTION`），
由 64 位 VEH `Warning`（**exe 的导出函数**，VA 0x81139C）按**触发指令的 opcode 字节**分发：

| opcode | 语义 |
|---|---|
| `0xED` (`in eax,dx`) | gate1：查 `declen != 0 && declen % 16 == 0`，再查 Dr0–Dr7 全 0、EFlags.TF=0 |
| `0xEE` (`out dx,al`) | gate2：查硬件断点/单步，再校验 ③ 解密后的缓冲 |
| `0xEC` (`in al,dx`) | **计算跳转**：`RIP = [RSP] ^ 0xFFFFFFFF87678580; RSP += 0x18` |
| `0xFA` (`cli`) | QueryPerformanceCounter 计时检查 |
| `0xFB` (`sti`) | 按 name-hash 遍历 PEB->Ldr 解析 API |

处理完把结果写进 `CONTEXT.Rax`、`CONTEXT.Rip += 1`（跳过那 1 字节），
返回 `EXCEPTION_CONTINUE_EXECUTION`，于是落到 `ret` —— 从调用方看就像一个普通函数返回了值。

**这也是反调试的核心**：挂调试器时 `int3` 被调试器先吃掉，`Warning` 根本没机会注册，
后面所有陷阱都会变成未处理异常。

### ③ MengXinQiuFangGuo —— 换了 S 盒的 AES-128 解密

这一层是全题的重心，也是我误判最多的地方（早期在 decoy 路径下观测，一度以为它是 no-op）。
把 `Warning` 的 `0xEC` 计算跳转实现出来之后，它才真正跑起来 —— 从 ~80 条指令暴涨到数百万条、
118 次模式切换。去混淆后的结构：

* state 是 `frame+0x60` 的 **4×4 dword** 网格（每个 state 字节被展开成一个 dword），列优先
* **AddRoundKey**：`xor [state_col], ecx/r8d/r10d/r11d`
* **SubBytes**：查 `frame+0xE0` 的表，索引 `(x&0xF0)+(x&0xF)`，读出后 `xor esi`（`esi=0x1F2A025C`，
  即表在栈上是**掩码存储**的）再 `add -4`
* **ShiftRows**：`pshufd 0x93 / 0x4E` —— dword 行轮转
* **MixColumns**：GF(2⁸)，约简多项式 `0x1b`（AES 的）
* **16 层**，轮密钥**反序**消费（RK10→RK0）—— 这是解密方向的特征

结论：**MengXin ≡ AES-128 解密**，只是 S 盒换成了自定义的 256 置换，
标准的 InvShiftRows / InvMixColumns 一个没改。
所以我们要的加密方向就是对应的 **AES-128 加密**。

主密钥来自 `main` 栈上的 `var_54`（`ebp-0x54`，16 字节），
它在 `scanf` 读输入**之前**就由 `sub_401160` 设好，跨运行固定：

```
var_54       = c2 a7 00 23 51 78 83 4f 3e a6 38 43 c6 27 4a 30
frame+0xa10  = 2300a7c2 4f837851 4338a63e c6274a30   (每个 dword bswap)
D(全0块)     = d6 75 71 13 d0 e7 bc 93 60 f8 70 6b 66 40 7b 2e
```

**S 盒依赖 `BeingDebugged`**，这点极其隐蔽：

| BeingDebugged | D(0 块) |
|---|---|
| `0x00` | `d42908cb…` |
| `0x40` | **`d6757113…`（正确）** |
| `0x5A` | `e7e47f50…` |

`0x40` 是 `Warning` 加的，`+0x1A` 由后面另一处再加、凑成 `0x5A`。
**MengXin 执行时还是 `0x40`**，3.9 秒后才变 `0x5A`（那是 ⑤ 的取值）。
用错值提出来的 S 盒和正确的**一个字节都不重合**（0/256）。

### ⑤ GoodGoodStudy —— 多项式的根

```c
h = 0; for (c in name) h = h*31 + (u8)c;          // javaHashCode
st = h; cnt = 0;
while (cnt < 100) {
    st = fmix32(st);                               // x^=x>>16; x*=0x5BD1E995;
                                                   // x^=x>>13; x*=0xC2B2AE35; x^=x>>16
    c  = st & 0x3FFF;
    if (!seen[c]) { seen[c]=1; groups[cnt++]=c; }
    st += h + cnt;                                 // 命中/碰撞都执行，cnt 取递增后的值
}
```

![fmix32 的乘数常量 0x5BD1E995 在 .data 的 x64 blob 里](upload/attach/202608/1085268_HR48PJNF68FJTDY.webp)

*图 5　`0x808D19` 处的 `95 E9 D1 5B` 即 `0x5BD1E995`。
这段代码在 IDA 里是未定义字节（合成 PE32+ 里 `.data` 没被自动分析成代码，
何况它被 jmp 链彻底打散），所以这里用 Hex View 给常量本身当证据，
控制流靠自写的去混淆追踪器还原。*

拿到 100 个 14-bit 组号后，每组去 CSR 表取 11 个系数，拼成 10 次首一多项式，
把解析出的整数代回去做 Horner 求值，要求 `P(x) == 0`：

![图片描述](upload/attach/202608/1085268_CZY79SQ3Q9FRA5U.webp)

*图 6　`row_ptr` 紧跟在 `Successful!` 字符串之后。每项 `(offset & 0xFFFFFF) | (count << 24)`，
共 11×16384 项。全表 180224 项里 `count == 0` 的一个都没有。*

![图片描述](upload/attach/202608/1085268_4UCVBPUFWEQB722.webp)

*图 7　系数本体。**看上去完全随机** —— 因为每个字节都被
`mixbyte(idx*0x9E3779B9 ^ row*0x517CC1B7 ^ i*0x85EBCA6B)` 异或过。
解密后才是「符号 + 位数 + 压缩 BCD」。这正是题面"路线矩阵"伪装成随机矩阵的地方。*

解析规则：`-` 分隔，空格/换行忽略，NUL 结束，必须**恰好 1000 个**整数；
第 k 组用 `nums[10k..10k+9]`。它**不检查升序、不检查组内互异**，比的是数值不是文本。

反解方向很轻松：多项式已知且首一，直接对每组求整数根即可，**不需要任何搜索**。

## 环境门：父进程必须是 explorer.exe

`Warning` 里那条 `BeingDebugged += 0x40` 挂在一串检查后面，决定性的一环是：

```c
r13 = gs:[0x40];                                   // 自己的 PID
NtQuerySystemInformation(SystemProcessInformation);
  找到自己 → rax = InheritedFromUniqueProcessId    // 父 PID
  再找父进程 → rcx = ImageName.Buffer              // UTF-16 进程名
h = 0xF13093F0; for (wc in name) h = h*33 + tolower(wc);
cmp edx, 0x8EED4105 ; je  通过                     // "powershell.exe"
cmp edx, 0x9D1337F1 ; jne 放弃                     // "explorer.exe"
```

![explorer.exe 的 djb2 hash 常量 0x9D1337F1](upload/attach/202608/1085268_BWY77N4UM5WSPHJ.webp)

*图 8　`0x8136A1` 处小端 `F1 37 13 9D`。我按 djb2（seed `0xF13093F0`、乘数 33、tolower）
正向算了一遍：`hash33("explorer.exe") == 0x9D1337F1`、`hash33("powershell.exe") == 0x8EED4105`，
两个都对得上，确认了这是父进程名白名单。
Readme 里那句「运行方式：**双击运行**」不是废话，是硬约束。*

**这解释了我前期所有的"诡异现象"**：从 python/PowerShell 用 subprocess 拉起 CrackMe 时，
父进程不在白名单 → `BeingDebugged` 只到 `0x1A` → VM 字节码解密成垃圾 →
**连作者公布的合法 Name/Serial 都显示 Failed**。我曾因此怀疑样例损坏、怀疑 VBS、
甚至关掉 Hyper-V 重启机器，全是白费。

对应的本地验证器：用 `explorer.exe` 启动，`AttachConsole` + `WriteConsoleInput` 注入，
再读屏拿结论（`verify_via_explorer.py`）。这样验证不消耗看雪的提交次数。

## Solution

### Step 1　把 cipher 拼出来

pev2（自写的模式感知静态部分求值器）能完整跑通 MengXin，但它的 key schedule 依赖
ntdll 导出遍历，算出的轮密钥和真机不同。而真机的轮密钥是**固定**的，于是两边互补：

* **结构**取自 pev2 的白盒执行（轮函数、S 盒、层序）
* **轮密钥**从真机 frame+0xa10 dump（176 字节 = 11×16，RK0 == 主密钥）
* **S 盒**用 `BeingDebugged=0x40` 重采（多块随机输入喂进去，记录 SubBytes 前后 state，
  攒到 255/256 项后，最后一项因为是 256 置换可唯一推断）

拼出来的干净实现一次通过全部硬验证：

```
decrypt_block(0)                  == d6757113d0e7bc9360f8706b66407b2e   ✓
decrypt(C_public)[:6897]          == golden_plain_author.bin            ✓
encrypt(decrypt(C_public))        == C_public                           ✓
corpus 1287 对   decrypt 1287/1287   encrypt 1287/1287                  ✓
```

### Step 2　用作者样例做端到端自证

最强的一次验证 —— 用完整链条**逐字符重现作者公开的 Serial**：

```
name → 组号 → 多项式 → 根 → 明文 → MengXin.encrypt → DayDayUp.encode
                                        ↓
                        == Readme 里的公开 Serial（9226 字符，逐字符相同）
```

这一步把"每一环都对"钉死了，后面出问题就只可能是 `KCTF` 特有的东西。

### Step 3　计时 oracle 定位失败层

`GoodGoodStudy` 会**检查完全部 100 组**（不提前返回），某组失败时内层 break 会少算几个数，
所以**耗时本身就是"通过了多少组"的探针**。测「MengXin 完成 → 出结论」这一段：

| 输入 | GGS 段耗时 | 判读 |
|---|---|---|
| 作者 serial + 作者 name | **2.24 s** | gate2 过 + 100 组全过 → Successful |
| 作者 serial + name=KCTF | **0.24 s** | gate2 过，GGS 跑了但每组首个数就失败 |
| 我们的 KCTF serial | **0.00 s** | **gate2 直接拒绝，GGS 根本没执行** |

三档分离得很干净，一下就把锅从 ⑤ 摘到了 ④。

### Step 4　最后一个坑：明文总长

gate1 已经要求 `declen % 16 == 0`。反查作者的明文：文本 6897 → 总长 6912，**填充 15 字节**。
而 6912 是「≥6897 的最小 16 倍数」。我一直照抄 6912，对 `KCTF` 就是 6891 + **21** 填充 ——
填充跨过了一个完整块，gate2 拒。

改成同一条规则：

```python
L = (len(text) + 15) // 16 * 16      # 作者: 6897→6912(+15)   KCTF: 6891→6896(+5)
plain = text + b'\x00' * (L - len(text))
```

一次通过：

```
serial_KCTF_6896.txt  name=KCTF  MengXin=3.77s  verdict@5.89s  GGS=2.12s  -> Successful
（复现一次：MengXin=4.52s verdict@6.95s GGS=2.43s -> Successful）
```

`GGS=2.12s` 与作者成功时的 `2.24s` 同档，说明 100 组确实全过了。

### 附：解不唯一

另一条并行推进的路线（多 agent workflow）独立走到了同一个约束，但换了个方式满足它 ——
**给第一个数字补前导零**（解析器忽略前导零，值和根都不变，组内严格递增也不破）
把文本从 6891 撑到 6897，再按作者的老样子填充 15 字节到 6912：

| 方案 | 文本长 | 总长 | 填充 | serial 长 | 真机 |
|---|---|---|---|---|---|
| 缩总长（本文） | 6891 | 6896 | 5 | 9205 | Successful |
| 补前导零 | 6897 | 6912 | 15 | 9226 | Successful |

两份 serial 内容完全不同，都能通过 —— 说明**合法注册码不唯一**，
gate2 卡的确实只是「填充 ≤ 一个 AES 块」这一条，而不是某个特定长度。
这也反过来印证了对约束的理解没有过拟合到单个样本。

## 一个差点翻车的岔路

中途以为是**组号推导**出了问题，因为 `KCTF` 在生成 100 个组号时发生了 **1 次碰撞**，
而作者的 name **零碰撞**：

```
'338F493766CFC94B': 迭代 100 次, 碰撞 0 次
'KCTF':             迭代 101 次, 碰撞 1 次
```

零碰撞意味着 `st += h + cnt` 里 `cnt` 取"已收集数"还是"迭代数"**对作者完全等价** ——
也就是说，那个漂亮的 1000/1000 对拍**根本区分不出这两种语义**，是个验证盲区。
我据此做了 5 个变体（v1/v2/D/E/F）逐个真机试，全 Failed。

最后回二进制把循环读死才排除掉这条岔路：

```x86asm
loc_00805497:                      ; 循环体
  ... fmix32 ...                   ; st ^= st>>16 ; st *= 0x5BD1E995 ; ... ; st ^= st>>16
  and  ecx, 0x3fff                 ; c = st & 0x3FFF
  cmp  [rax + rcx*4], 0            ; seen[c]?
  jne  loc_007fffd7                ; 已见过 → 碰撞路径

loc_007fe2e5:                      ; 命中路径
  mov  [rax+rcx*4], 1              ;   seen[c] = 1
  movsxd rdx, ebx                  ;   旧 cnt
  inc  ebx                         ;   cnt++        ← 先递增
  mov  [r15+rdx*4], ecx            ;   groups[旧cnt] = c
  mov  ecx, [rsp+0x30]             ; ecx = h
  add  ecx, ebx                    ; h + cnt        ← 用递增后的值
  add  [rsp+0x38], ecx             ; st += h + cnt
  cmp  ebx, 0x64 ; jge 退出

loc_007fffd7:                      ; 碰撞路径：同样的三条，ebx 不变
```

两条路径汇合后都执行 `st += h + cnt`，`cnt` 就是"已收集数" —— 原实现是对的，
问题从来不在这里。**盲区不等于错误**，但它足以让人在错误的方向上跑很久。

## Flag

```
Name   : KCTF
Serial : 9205 字符，lI|0OCLzopJ(69VmDBJcPKUnWRF`ll48{3RTtFoY8IKizBD5C6rv+ITiTFnc...
         ...I4Jmll8Ck`UHuuHOQ(IJeRImIHcESa4SNsrIl1|!
```

## 工具

| 文件 | 用途 |
|---|---|
| **Claude Code（Claude Opus 5）** | 全程驱动：反汇编阅读、假设生成与证伪、反推器编写与调试、任务编排 |
| `mengxin_aes.py` + `mengxin_sbox.json` + `mengxin_roundkeys.bin` | MengXin 的干净 AES 实现（encrypt/decrypt 双向） |
| `daydayup.py` | ① 层编解码 |
| `solve.py` | ⑤ 层：name → 组号 → 多项式 → 根 → 明文 |
| `verify_via_explorer.py` | 本地验证器（explorer 启动 + 控制台注入 + 读屏） |
| `verify_timed.py` | 带计时的验证器，用于 GGS 段耗时探针 |
| `golden_plain_author.bin` | 从活进程 dump 的作者明文，全程当 ground truth |

回复或点赞可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-8-17 13:19 被星野安全编辑，原因：

#CrackMe

最新回复 (11)
mb_tnqoqsdv 雪币： 0 活跃值： (2169) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 62 粉丝 1 关注私信	mb_tnqoqsdv 2 楼学习学习 2026-8-17 14:01 0
海风月影雪币： 7546 活跃值： (4339) 能力值： (RANK：1130 ) 在线值：发帖 93 回帖 2318 粉丝 127 关注私信	海风月影 22 3 楼学习学习 2026-8-17 14:14 0
落音吹雪雪币： 205 活跃值： (186) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 44 粉丝 0 关注私信	落音吹雪 4 楼牛逼 2026-8-17 14:28 0
method 雪币： 1992 活跃值： (8198) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 269 粉丝 134 关注私信	method 1 5 楼 1 2026-8-17 15:44 0
落音吹雪雪币： 205 活跃值： (186) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 44 粉丝 0 关注私信	落音吹雪 6 楼期待开源实现代码 2026-8-17 22:27 0
Midsw 雪币： 28 活跃值： (1425) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 136 粉丝 1 关注私信	Midsw 7 楼 6666666 2026-8-18 05:15 0
noahze 雪币： 204 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	noahze 8 楼 666 2026-8-18 21:09 0
RascallyDog 雪币： 138 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 4 关注私信	RascallyDog 9 楼 6 2026-8-18 21:21 0
秋白雪币： 260 活跃值： (115) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 12 粉丝 0 关注私信	秋白 10 楼 111 2026-8-20 15:37 0
manyuegong33 雪币： 434 活跃值： (340) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 59 粉丝 13 关注私信	manyuegong33 11 楼 666 2026-9-8 18:36 0
xyzliao 雪币： 738 活跃值： (5714) 能力值： ( LV3，RANK：20 ) 在线值：发帖 4 回帖 134 粉丝 4 关注私信	xyzliao 12 楼牛逼 2026-9-9 10:44 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

[原创]KCTF2026 - 第四题：未时·车流困城 题解（AI）

[原创]KCTF2026 - 第四题：未时·车流困城题解（AI）