[原创]KCTF 2026 第二题 "绿光幽语" WriteUp-CTF对抗-看雪安全社区

# 第二题 "绿光幽语"WriteUp

目标文件：`题目.exe`（PyInstaller onefile 打包，x64，Python 3.13.1）

分析工具：GPT 5.6 + IDA Pro + 官方 CPython 3.13.1 解释器（marshal/dis 还原字节码）

## 0. 题目主题与线索映射

出题人在简介里埋了三条技术线索，破解后可一一对应：

| 简介中的隐喻                           | 对应的真实技术点                                                |
| -------------------------------- | ------------------------------------------------------- |
| "文件分段加密：**古典密码、时间戳算法、硬件密钥**"     | 重复密钥异或（Vigenère 型古典密码）+ 单字节 XOR + 密文分段                  |
| "硬件密钥被拆成**十六个碎片，分散在十六个存储扇区**"    | 提示明文被拆成 8×16=128 字节碎片，藏在**重编译的 python313.dll** 里        |
| "三年前 KCTF 上那款**工业路由器**，用的就是这套逻辑" | 自定义/固化 Python 运行时（把逻辑冻结进 DLL 的 frozen module），路由器固件常见套路 |
| "终端机化为灰烬" / "**空白照片**的工牌"        | `main.pyc` 是空壳诱饵（`sys.exit(0)`），真正的"人"（逻辑）藏在别处          |

整个解题过程遵循"**由外到内、由静到动**"的顺序：外壳 → 解包 → 诱饵识别 → 动态运行 → 定位真实逻辑 → 还原算法 → 恢复密钥。

***

## 1. 第一层：识别外壳（IDA 静态分析）

### 1.1 确认是 PyInstaller 壳

在 IDA 中对入口相关函数做 F5，很快能看到大量 `Py_*` C-API 被**运行时动态解析**。例如 `sub_140001C80`（Python DLL 符号加载器）的 F5 伪代码节选：

```c
__int64 __fastcall sub_140001C80(__int64 a1)
{
  // a1 是一张"函数指针表"，逐个用 GetProcAddress 从 python 主 DLL 拿地址
  Py_DecRef = GetProcAddress(*(HMODULE *)a1, "Py_DecRef");        // 0x140001c93
  *(_QWORD *)(a1 + 16) = Py_DecRef;
  if ( !Py_DecRef ) { /* 报错 "Failed to import symbol %hs from Python DLL." */ }

Py_DecodeLocale             = GetProcAddress(*(HMODULE*)a1, "Py_DecodeLocale");
  Py_Finalize                 = GetProcAddress(*(HMODULE*)a1, "Py_Finalize");
  ...
  PyMarshal_ReadObjectFromString = GetProcAddress(*(HMODULE*)a1, "PyMarshal_ReadObjectFromString"); // 反序列化 pyc
  PyEval_EvalCode                = GetProcAddress(*(HMODULE*)a1, "PyEval_EvalCode");                 // 执行 code object
  PyImport_ExecCodeModule        = GetProcAddress(*(HMODULE*)a1, "PyImport_ExecCodeModule");
  PyRun_SimpleStringFlags        = GetProcAddress(*(HMODULE*)a1, "PyRun_SimpleStringFlags");
  ...
  return 0;
}
```

> **解读**：这段一次性解析了 50+ 个 `Py_*` 符号并存入结构体偏移，是 **PyInstaller 官方 bootloader 的标准行为**（`pyi_pylib_load_python_dll` / `_pyi_pylib_set_runtime_paths` 那套）。没有任何自定义算法。

### 1.2 全局字符串搜索确认无自定义逻辑

在 IDA 里搜索 `flag / KCTF / serial`：

- `flag` 只命中 Windows API 的 `dwFlags`、`pyi-python-flag` 等噪声；
- `KCTF` 零命中。

**结论 1：原生 EXE 层是标准 PyInstaller 壳，flag 逻辑不在原生代码里。** 这正是"工牌上的空白照片"——外壳是障眼法。

***

## 2. 第二层：解包 CArchive（结构分析）

用脚本解析 PyInstaller 的 CArchive（`parse_toc.py` / `full_toc.py`），定位文件尾部的 `MEI\x0c\x0b\x0a\x0b\x0e` cookie，读出 21 个 TOC 条目：

```
typ  flag      dlen      ulen   name
m    1          235       289   struct
m    1         2831      4914   pyimod01_archive
m    1        13630     31786   pyimod02_importers
s    1         1027      1881   pyiboot01_bootstrap
s    1         1470      2779   pyi_rth_inspect
s    1          121       159   main            ← 入口脚本，仅 159 字节
b    1       ...                 _decimal.pyd / _hashlib.pyd / _socket.pyd ...
b    1      2676210   7127552   python313.dll   ← 注意这个体积
z    0      1372950   1372950   PYZ.pyz         ← 112 个标准库模块
```

关键观察：

1. `main` 入口只有 **159 字节**，可疑地小；
2. 打包了 `_hashlib / _socket / _decimal` 等**非默认扩展**，说明原始 `main.py` 曾 `import hashlib/socket/datetime/csv/statistics/...`（与"时间戳/加密"主题吻合），但源码后来被替换了。

### 2.1 反汇编 main.pyc —— 确认是诱饵

从 CArchive 直接抽出 `main` 条目并 `marshal.loads` 反汇编：

```python
# main 的完整字节码（Python 3.13）
  1   RESUME              0
  1   IMPORT_NAME         sys          # import sys
  3   LOAD_ATTR           exit
      LOAD_CONST          0
      CALL                1            # sys.exit(0)
      RETURN_CONST        None
```

> **`main`** **只做了一件事：`import sys; sys.exit(0)`。** 这就是"化为灰烬的终端机"——入口脚本是空壳。
>
> 同时把 PYZ.pyz 里的 112 个模块全部与官方 3.13.1/3.13.7 源码做字节码级 diff，扣除"点版本差异 + `-OO` 去 docstring"的噪声后，**没有任何一个标准库模块被真正篡改**。

**结论 2：Python 脚本层（main + PYZ + base\_library）全是干净的标准库和诱饵，真实逻辑既不在原生层，也不在常规 pyc 里。**

至此静态分析陷入僵局——这是本题设计最"阴"的地方。破局点必须来自动态运行。

***

## 3. 第三层：动态运行（关键转折）

既然 `main` 号称直接退出，那就**实际跑一遍**看看：

```powershell
PS> .\题目.exe            # 控制台 GBK，输出乱码
PS> python -c "import subprocess; p=subprocess.run(['题目.exe'], input=b'\n', capture_output=True); print(p.stdout.decode('gbk'))"
```

GBK 解码后惊现**真实交互逻辑**：

```
提示，需要还原的代码

def my_function():

print("恭喜成功！")

请输入key还原代码（请输入6个字符）
```

> **重大发现**：程序明明"应该"在 `main` 里 `sys.exit(0)`，却打印出了 keygen 提示！说明真正的代码在 **`main`** **之前**就执行了。

在 Python 启动流程中，能早于用户入口脚本运行的，只有**解释器自带的 frozen module**（如 `os`、`importlib._bootstrap` 等，它们被冻结进解释器，`import` 时无需读磁盘）。而这些 frozen module 就编译进了 **`python313.dll`**——回想第 2 节里那个体积异常的 DLL。

***

## 4. 第四层：定位 DLL 中的 frozen 模块

对提示中出现的函数名 `my_function` 在所有文件做**裸字节搜索**：

```
FOUND b'my_function' in python313.dll @0x4dace9
   ctx: ...\xda\x0bmy_functionr...  s\x10\x00\x00\x00\xb3\xda\xc5\xb2\xf1\xef...
```

命中 `python313.dll`！`\xda\x0b` 是 marshal 的 `SHORT_ASCII_INTERNED`(len=11) + `my_function`，紧跟着一串 `s\x10\x00\x00\x00`（marshal `TYPE_STRING`, len=0x10=16 字节）——**正是"十六个碎片"**。

向前扫描定位到 marshal code object 的起点，用官方 3.13.1 解释器成功 `marshal.loads` 出一个 `co_name='<module>'`、内含 `my_function` 的完整模块——**这是一个被出题人魔改过的 frozen** **`os`** **模块**（起始偏移 `0x4d00e0`）。

> **对应线索**："工业路由器用的就是这套逻辑"——把校验逻辑冻结进运行时 DLL，是嵌入式/路由器固件里常见的反逆向手法。

### 4.1 提取魔改 os 模块的关键常量

递归遍历该 code object 的 `co_consts`，找到出题人注入的载荷：

| 常量索引         | 内容                                                                       | 用途                          |
| ------------ | ------------------------------------------------------------------------ | --------------------------- |
| `const[145]` | **8 个 16 字节** bytes 元组（共 128 字节）                                         | 提示明文密文（"16 碎片"）             |
| `const[146]` | `85`                                                                     | 单字节 XOR key                 |
| `const[147]` | `'utf-8'`                                                                | 解码                          |
| `const[148]` | `6`                                                                      | 密钥长度校验                      |
| `const[149]` | `b'\xecbmucryb6tcr*c\x03ucryb6tCr\x1eb'`                                 | `my_function` 的加密 `co_code` |
| `const[151]` | `b'\x9f\xe3\x9b\x91\xf5\xee\x9f\xea\xa6\x91\xe9\xed\x96\xde\xb7'`（15 字节） | 加密的成功字符串                    |
| `const[143]` | `<code my_function>`                                                     | 待还原的函数（占位版）                 |

***

## 5. 第五层：还原校验算法（字节码分析）

对魔改 os 模块的**模块级字节码**（第 1185–1226 行）反汇编，逐段翻译成等价 Python。核心逻辑如下：

### 5.1 生成提示（单字节 XOR）

```python
# 反汇编片段（行 1192-1205）：
#   LOAD_CONST 144 (b'')  .join  [ *const[145] ]   → buffer  (128 字节)
#   for i in buffer:  b = i ^ 85;  w += b.to_bytes(1)
#   print(w.decode('utf-8'))
buffer = b''.join(FRAGMENTS)              # const[145]，8×16=128 字节
w = bytes(i ^ 85 for i in buffer)         # 逐字节 XOR 0x55
print(w.decode('utf-8'))                  # → "提示，需要还原的代码 ... 请输入6个字符"
```

> 这就是"**古典密码 + 时间戳算法**"里最简单的单表替换层：`XOR 85`。

### 5.2 读取并校验密钥长度

```python
# 行 1206-1208
key = input()
if len(key) != 6:        # const[148]=6
    continue             # 长度不对则重来（外层 while x<20 循环）
b_key = key.encode()
```

### 5.3 用密钥解密 `co_code`（重复密钥异或 = 古典 Vigenère）

```python
# 行 1210-1216：解密 my_function 的字节码
c   = b'\xecbmucryb6tcr*c\x03ucryb6tCr\x1eb'   # const[149]
buf = bytes(c[i] ^ b_key[i % len(b_key)]        # 重复密钥循环异或
            for i in range(len(c)))
my = my_function.__code__.replace(co_code=buf)  # 替换字节码
```

对应 F5 之外的字节码证据（行 1213）：

```
LOAD_NAME c; LOAD_NAME i; BINARY_SUBSCR                # c[i]
LOAD_NAME b_key; LOAD_NAME i; ... BINARY_OP %; BINARY_SUBSCR   # b_key[i % len(b_key)]
BINARY_OP 12 (^)                                       # c[i] ^ b_key[...]
LOAD_ATTR to_bytes; CALL 1; BINARY_OP += → buf
```

### 5.4 用同一密钥解密成功字符串，并回填常量

```python
# 行 1219-1224
succ = b'\x9f\xe3\x9b\x91\xf5\xee\x9f\xea\xa6\x91\xe9\xed\x96\xde\xb7'  # const[151]，15 字节
buf  = bytes(succ[i] ^ b_key[i % len(b_key)] for i in range(len(succ)))
my   = my.replace(co_consts=(None, buf.decode('utf-8')))   # 把成功文案塞回常量表

# 行 1224-1226
my_function.__code__ = my       # 装配好的新字节码
my_function()                   # 调用——密钥错则字节码非法直接崩溃（"否则自毁"）
```

> **校验原理（精妙之处）**：程序**不做任何** **`if key == ...`** **的显式比较**。密钥正确时，`c` 被异或还原成一段**合法的 CPython 字节码**（正好是 `print("恭喜成功！")`），`my_function()` 正常输出；密钥错误时还原出**非法字节码**，调用即抛异常/崩溃——这正是简介里"**三段必须同步解密，否则自毁**"。

***

## 6. 第六层：恢复密钥（已知明文攻击）

无需爆破。第 5.4 节告诉我们：解密后的 `succ` 必然是成功文案。而提示里已经明明白白写着成功文案是 **`恭喜成功！`**，其 UTF-8 编码恰好 **15 字节**，与 `succ` 长度完全一致：

```python
plain = "恭喜成功！".encode("utf-8")   # 15 字节: e6 81 ad e5 96 9c e6 88 90 e5 8a 9f ef bc 81
# succ[i] = plain[i] ^ key[i % 6]  →  key[i] = succ[i] ^ plain[i]
key = bytes(succ[i] ^ plain[i] for i in range(6))
# → b'yb6tcr'
```

### 6.1 三重交叉验证

1. **密钥自洽**：`key = yb6tcr`，用它对整段 `succ`（15 字节）循环异或，还原得到 `恭喜成功！`（完美 UTF-8）；
2. **字节码自洽**：用 `yb6tcr` 解密 `c`(const\[149]) 得到 `95005b01...6700`，与 `my_function` 的**原始** `co_code` **逐字节一致**，反汇编为：
   ```
   RESUME 0
   LOAD_GLOBAL print
   LOAD_CONST '恭喜成功！'
   CALL 1
   RETURN_CONST None
   ```
3. **彩蛋**：密文 `c = b'\xecbmucryb6tcr*c\x03ucryb6tCr\x1eb'` 中肉眼可见子串 `yb6tcr`——密钥就"泄漏"在密文里（见第 8 节点评）。

### 6.2 实机验证

```python
import subprocess
p = subprocess.run(['题目.exe'], input=b'yb6tcr\n', capture_output=True)
print(p.stdout.decode('gbk'))
```

输出结尾：

```
请输入key还原代码（请输入6个字符）
恭喜成功！          ← 校验通过
```

**✅ 注册码** **`yb6tcr`** **经真机验证正确。**

***

## 7. 完整解题脚本

```python
import marshal

# 1) 从 python313.dll 偏移 0x4d00e0 提取魔改 os 模块的 code object
data = open(r'python313.dll', 'rb').read()
co = marshal.loads(data[0x4d00e0:0x4d00e0 + 0x20000])

frags = co.co_consts[145]     # 8×16 字节碎片
c     = co.co_consts[149]     # 加密的 co_code
succ  = co.co_consts[151]     # 加密的成功字符串(15字节)

# 2) 还原提示（单字节 XOR 85）
hint = bytes(b ^ 85 for b in b''.join(frags)).decode('utf-8')
print(hint)

# 3) 已知明文攻击恢复 6 字节密钥
plain = '恭喜成功！'.encode('utf-8')          # 15 字节
key = bytes(succ[i] ^ plain[i] for i in range(6))
print('KEY =', key.decode())                  # → yb6tcr

# 4) 验证：解密 co_code 应与原始 my_function 字节码一致
buf = bytes(c[i] ^ key[i % 6] for i in range(len(c)))
myf = next(k for k in co.co_consts if hasattr(k, 'co_code') and k.co_name == 'my_function')
assert buf == bytes(myf.co_code)               # 通过
```

***

## 8. 难度评估与出题点评

**综合难度：中上。** 对只会"pyinstxtractor + 反编译 pyc"流水线的选手是**硬门槛**；对有动态调试意识、了解 frozen module 机制的老手是中等。

### 设计亮点

- **诱饵入口 + 逻辑冻结进 DLL**：`main` 只 `sys.exit(0)`，把校验逻辑塞进 frozen `os`，让纯静态 diff 标准库的常规思路彻底失效。这是全题的灵魂。
- **无显式比较的校验**：不写 `if key==...`，而是"密钥即解密密钥"，错误密钥导致字节码非法自毁——既优雅又贴合"同步解密否则自毁"的剧情。
- **三段加密层次分明**：单字节 XOR（提示）+ 重复密钥异或（字节码/成功串）+ 密文分段（16 碎片藏 DLL），层层递进。
- **剧情与技术强绑定**：16 碎片 / 工业路由器 / 空白工牌，每条隐喻都能落到实处，出题用心。

> **一句话总结**：外壳干净、诱饵到位、逻辑藏得妙，是一道"考动态意识 + frozen module 冷知识"的好题；核心思路值得沉淀成模板。

**Flag / 注册码 / 序列号：`yb6tcr`**

登录后可查看完整内容

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

最后于 2026-8-11 17:13 被BenBenWen编辑，原因：