[原创] 看雪·2026 KCTF 第四题：未时·车流困城 WP-CTF对抗-看雪安全社区

[原创] 看雪·2026 KCTF 第四题：未时·车流困城 WP

发表于: 2026-8-17 15:49 110

[原创] 看雪·2026 KCTF 第四题：未时·车流困城 WP

DNLINYJ

2026-8-17 15:49

110

## 前言
本文做出来的时候, 使用的是网页端的 `GPT-5.6-Sol xhigh`, 之前使用 `Opus 4.8 + GPT 5.5/5.6 Terra` 的时候一直卡在动态调试导致的数据流错误上, 然后就一直卡在模拟和插桩上了（至于为什么用这两个老模型是因为这玩意不爆 Cyber，我又不想装破限提示词怕把我号爆破了）, 这几天拿这两个叼毛的完整上下文对账去，~~顺便可以水水文章（）~~

后面用 Codex 里面的 Sol 指定函数纯静态逆向的时候又不爆 Cyber 了，怪

下面的 WP 为网页端 `GPT-5.6-Sol xhigh` 生成, 整体解题过程用时约 3 小时（不算我被那两个老模型耗的时间）

---

> 样本：`CrackMe.exe`
>
> 目标：给定用户名，构造能够通过校验的超长 password。
>
> 最终结论：整个校验可以拆成三层：`DayDayUp -> MengXinQiuFangGuo -> GoodGoodStudy`。最麻烦的不是数学，而是 MengXin 中的控制流混淆、反调试状态字节，以及一处非常容易误判的 key schedule DWORD 符号扩展。

---

## 0. TL;DR

程序对 password 的实际处理链可以抽象成：

反向 keygen 则反过来：

公开成功向量：

```text
Name = 338F493766CFC94B
```

可以完整重建出公开 serial。

---

# 1. 为什么一开始特别难分析

`MengXinQiuFangGuo` 外面套了大量保护：

- 64/32 位 `retf` 切换；
- fault/exception 驱动的 VMJMP；
- `hlt`、`out` 等异常控制流；
- opaque predicate；
- 动态解析系统导出；
- `ZwGetContextThread` 检查 Debug Registers / Trap Flag；
- `PEB+2` 参与真实密码运算。

最初使用的 `deobf3.py` 还有一个非常重要的限制：它对所有条件跳转只走一条统一路径，默认 fall-through。因此 `path2.txt` 能帮助看结构，但不能被当成“真实动态执行轨迹”。

这也是前期出现“结构看起来像 AES，但怎么算都不匹配”的主要原因之一。

---

# 2. 总体校验结构

主程序读入 username 和 password 后，大体依次执行三层逻辑：

```text
password
   |
   +--> DayDayUp
           |
           +--> MengXinQiuFangGuo
                    |
                    +--> GoodGoodStudy(username, decimal_text)
```

因此构造 password 时也只需要把这三层逐层求逆。

---

# 3. GoodGoodStudy：真正的“数学题”

## 3.1 Username 选择 100 个 row

先对 username 做一个简单的 31-base hash：

```python
def username_hash(name: bytes):
    h = 0
    for b in name:
        h = (h * 31 + b) & 0xffffffff
    return h
```

然后使用一个 Murmur 风格的 `fmix` 更新 state：

```python
def fmix(x):
    x ^= x >> 16
    x = x * 0x5bd1e995 & 0xffffffff
    x ^= x >> 13
    x = x * 0xc2b2ae35 & 0xffffffff
    x ^= x >> 16
    return x & 0xffffffff
```

每次取：

```python
idx = state & 0x3fff
```

即从 `0..16383` 中选 row，直到得到 100 个不重复 row。

恢复出的逻辑：

```python
def rows_for(name):
    h = username_hash(name.encode())
    state = h
    seen = set()
    out = []

while len(out) < 100:
        state = fmix(state)
        idx = state & 0x3fff
        if idx not in seen:
            seen.add(idx)
            out.append(idx)
        state = (state + h + len(out)) & 0xffffffff

return out
```

## 3.2 每个 row 是一个十次整系数多项式

每个 row 保存 11 个系数：

```text
C0, C1, ..., C10
```

对应：

\[
P(x)=C_0+C_1x+\cdots+C_{10}x^{10}
\]

数据本身没有明文保存，而是通过 descriptor 指向编码 blob，再经一个 row / coefficient 相关的 keystream 解出十进制系数字符串。

恢复后发现选中的多项式都能分解为 10 个一次因子，因此每行可以得到 10 个整数根。

```python
p = Poly(sum(C[j] * x**j for j in range(11)))
roots = factor(p)
```

100 行 × 10 个根 = 1000 个整数。

最终 GoodGoodStudy 明文形态为：

```text
r0-r1-r2-...-r999
```

## 3.3 多解问题

当前恢复的验证模型对每组 10 个输入主要检查“值是否属于这一行多项式的可接受根集合”。因此至少从数学约束本身来看，根的排列并不天然唯一。

当前 keygen 为了得到稳定输出，主动执行了：

```python
roots.sort()
```

所以它只选了众多候选中的一个 canonical solution。

**已经很可信：同一行 10 个不同根的排列存在多解。**

至于“同一个根重复 10 次是否也能通过真实二进制”，目前还应保守处理：我们的高层验证器允许 membership-only，但是否存在隐藏的 distinctness 条件，最好再做一次真实程序实验后下最终结论。

---

# 4. GoodGoodStudy 明文的 NUL padding

这是后期才暴露出来的一个通用性坑。

得到十进制文本后，程序要求在**尾部**补 NUL，而且长度必须到“严格下一个 16-byte 边界”：

```python
def next_block16_with_nul(n):
    return (n // 16 + 1) * 16
```

也就是说，即使原长度已经是 16 的倍数，也仍然补一个完整 16-byte block。

例如公开向量：

```text
username           = 338F493766CFC94B
decimal text       = 6897 bytes
Meng buffer         = 6912 bytes
trailing NUL        = 15
```

而 `KCTF`：

```text
decimal text       = 6891 bytes
Meng buffer         = 6896 bytes
trailing NUL        = 5
```

之前错误地 padding 到 `lcm(3,16)=48` 的倍数，公开向量碰巧没有暴露问题，但 `KCTF` 立即失败。

---

# 5. MengXinQiuFangGuo：AES-128 解密骨架的魔改

这是整题最核心的一层。

它的干净数学结构可以看成：

> AES-128 Equivalent Inverse Cipher 骨架 + 两张自定义 S-box + 特殊 key schedule + 环境状态字节。

块大小和 key 大小都是 16 bytes。

## 5.1 Master key

恢复出的 master key 为：

```text
c2a700235178834f3ea63843c6274a30
```

入口处直接从 `R8` 读取 4 个 DWORD，`bswap` 后写入 `w[0..3]`，因此它就是 K0，而不是 Meng 内部再加工出来的某个中间 key。

这份 key 在样本中来自程序的完整性/self-check 逻辑，可理解为由多个区域的 CRC32 结果拼接而成。对写 solver 来说直接使用这 16 bytes 即可。

## 5.2 两张不同的 S-box

程序有两张独立 256-byte permutation：

```text
sbox_keysched.bin   # key expansion
sbox_round.bin      # round substitution
```

原代码中表项不是直接存 byte，而是类似：

```text
encoded_dword
    XOR 0x1f2a025c
    - 4
```

之后再混入保护状态字节。

## 5.3 最坑的地方：KeySchedule 不是普通 uint8 SubWord

一开始我们写成了：

```python
t = [sbox[b] for b in t]
```

这是错的。

原程序把 S-box 结果保留为 DWORD；当结果最高位为 1 时，值表现为 sign-extended DWORD：

```text
00..7f -> 000000xx
80..ff -> ffffffxx
```

随后直接移位、OR，没有重新 `& 0xff`。

因此：

```text
44 b1 da 21
```

不能简单拼成：

```text
44b1da21
```

而可能因为 `ffffffb1 / ffffffda` 的高位参与 OR 变成完全不同的 DWORD。

这正是最初大量 AES variant 穷举全部失败的关键原因。

## 5.4 环境状态字节：不是 Boolean

原代码在 substitution 路径中出现：

```text
GS:[0x60] -> PEB
byte [PEB+2]
XOR substitution result
```

最初把它理解为普通 `BeingDebugged`，只考虑 0/1，也是不对的。

保护代码会把这个位置作为完整 8-bit 状态使用。

通过公开成功 pair 和独立 Meng block 测量，目前成功路径等价于：

```text
peb_byte = 0x40
```

旧的坏路径 dump 则等价于：

```text
peb_byte = 0x00
```

**这里要强调：0x40 的“成功路径有效值”已经被向量验证；但它在完整 VEH / protector 状态机中究竟由哪一组异常处理精确演化出来，目前没有必要为了 keygen 强行解释。**

## 5.5 Key expansion

总体仍是 AES-128 的 44-word 结构：

```python
w[i] = w[i-4] ^ temp
```

当 `i % 4 == 0`：

```text
RotWord
Custom KeySchedule S-box
PEB-state XOR
signed-DWORD concatenate
AES Rcon
```

Rcon 仍然在 Rijndael GF(2^8) 中通过 `0x1b` reduction 生成。

## 5.6 Round S-box + InvShiftRows

round substitution 为：

```python
state[i] = sbox_round[state[i]] ^ 0x40
```

接下来完全是标准 AES InvShiftRows。

机器代码中的：

```text
pshufd row1, 0x93
pshufd row2, 0x4e
pshufd row3, 0x39
```

正好对应三行右移 1、2、3。

## 5.7 InvMixColumns

这一层最终确认没有魔改，就是标准 AES InvMixColumns：

```text
0e 0b 0d 09
09 0e 0b 0d
0d 09 0e 0b
0b 0d 09 0e
```

有限域仍是：

```text
GF(2^8), polynomial = 0x11b
```

所以核心 `xtime`：

```python
def xtime(x):
    return ((x << 1) & 0xff) ^ (0x1b if x & 0x80 else 0)
```

## 5.8 XOR mask 的真相

早期动态追踪中，InvMixColumns 后面还出现了一组 16-byte XOR，看起来像额外 mask。

最后发现：

```text
mask_r = InvMixColumns(Kr)
```

它不是随机 mask，而是 AES **Equivalent Inverse Cipher** 的标准变形。

利用线性性质：

\[
IMC(S\oplus K)=IMC(S)\oplus IMC(K)
\]

所以：

```text
InvMixColumns(state)
XOR InvMixColumns(Kr)
```

和：

```text
(state XOR Kr)
InvMixColumns
```

是等价的。

## 5.9 最终完整 round structure

成功路径可以干净地写成：

```python
state = block ^ K10

for r in range(9, 0, -1):
    state = custom_sub(state, peb_byte=0x40)
    state = InvShiftRows(state)
    state = state ^ Kr
    state = InvMixColumns(state)

state = custom_sub(state, peb_byte=0x40)
state = InvShiftRows(state)
state = state ^ K0
```

或者按原始 Equivalent-Inverse 的写法：

```python
state = block ^ K10

for r in range(9, 0, -1):
    state = custom_sub(state)
    state = InvShiftRows(state)
    state = InvMixColumns(state)
    state ^= InvMixColumns(Kr)

state = custom_sub(state)
state = InvShiftRows(state)
state ^= K0
```

两者等价。

## 5.10 Meng 测试向量

成功路径 `peb_byte=0x40` 可以重新命中最早独立测得的两个 block vector：

```text
F(00*16) = d6757113d0e7bc9360f8706b66407b2e
F(AA*16) = a0165dfec4cd27c587749087dab11a7c
```

这也是判断 good-path 模型是否正确的非常强的 regression test。

---

# 6. DayDayUp：自定义无 padding Base64

DayDayUp 最终比 Meng 简单很多。

外层固定 wrapper：

```text
prefix = "lI|0O"
suffix = "Il1|!"
```

64 字符 alphabet：

```text
Il1|!ijJL`oO0QDSs5$Zz2B8gq96nNmMWwUuVvRrPpCc({tT+7xXKkYyAa4Ee3FH
```

先按普通 Base64 的方式把 bytes 拆成 6-bit sextets，但**没有 `=` padding**。

然后第 `p` 个 sextet `v` 映射为：

```python
alphabet[(v - 51 - 27*p) & 63]
```

逆向 decode：

```python
v = (alphabet_index[ch] + 51 + 27*p) & 63
```

这里最后一个坑是：DayDayUp 支持不完整尾组。

```text
2 sextets -> 1 byte
3 sextets -> 2 bytes
4 sextets -> 3 bytes
```

因此 Meng buffer **只需要 /16，不需要 /3，更不需要 /48**。

---

# 7. 最终 keygen

把三层倒过来即可：

```python
def build(username):
    # 1. GoodGoodStudy
    roots = recover_1000_roots(username)
    decimal = '-'.join(map(str, roots)).encode()

# 2. strict-next-16 NUL padding
    n = (len(decimal) // 16 + 1) * 16
    target = decimal + b'\0' * (n - len(decimal))

# 3. inverse MengXin
    pre_meng = meng_inverse(
        target,
        key=bytes.fromhex('c2a700235178834f3ea63843c6274a30'),
        peb_byte=0x40,
    )

# 4. inverse DayDayUp
    return day_encode(pre_meng)
```

---

# 8. 公开向量和踩坑记录

公开成功样本：

```text
Name = 338F493766CFC94B
```

用最终 pipeline 生成出的 password 可以与公开 successful serial 完全一致。

过程中几个最关键的错误路径：

```text
错误 1：把静态 fall-through path 当真实路径
错误 2：把 key schedule S-box 当普通 uint8_t
错误 3：把 PEB+2 当 Boolean 0/1
错误 4：把 InvMixColumns 后 XOR 当成神秘随机 mask
错误 5：把 NUL padding 补到 48-byte multiple
错误 6：认为 DayDayUp decoded length 必须 %3==0
```

其中错误 5 很隐蔽，因为公开向量：

```text
6897 -> 6912
```

既是下一个 16 边界，也碰巧是 48 的倍数，所以单测公开 pair 看不出问题。

换成 `KCTF` 后：

```text
6891 -> 正确 6896
```

错误模型却会补到 6912，于是真实 CrackMe 直接 `Failed!`。

---

# 9. 最后的算法画像

如果只看去掉保护后的数学核心，这题其实非常漂亮：

```text
GoodGoodStudy
    = username-selected polynomial root constraints

MengXinQiuFangGuo
    = custom-Sbox AES-128 equivalent inverse cipher
      + signed-DWORD key schedule trap
      + full-byte protector state mixed into substitutions

DayDayUp
    = position-dependent custom unpadded Base64
```

真正的逆向难点并不是 AES 本身，而是作者故意让：

```text
“错误环境下执行出来的算法”
```

仍然保持高度自洽。

也就是说，你完全可以把坏路径 dump 下来、把每一轮都还原正确、甚至 forward/inverse 自己互逆——但最后仍然无法解释官方成功 pair。

只有把公开 pair 当作外部 oracle，逐层验证：

```text
DayDayUp ✅
MengXin   ❌
GoodGoodStudy ✅
```

才最终定位到 Meng 的 success-path 状态字节与 padding 语义。

这也是这题最值得写进 WP 的点：

> **“能自洽”不等于“还原了真实成功路径”。对于带 anti-debug / exception VM 的 CrackMe，必须保留至少一个真实 successful vector 做端到端回归。**

---

登录后可查看完整内容