KCTF 2026 第二题：巳时·绿光幽语 writeup-CTF对抗-看雪安全社区

KCTF 2026 第二题：巳时·绿光幽语 writeup

发表于: 2026-8-12 20:18 503

KCTF 2026 第二题：巳时·绿光幽语 writeup

Magic丶

2026-8-12 20:18

503

# kctf02 Writeup：从 PyInstaller 运行时恢复动态字节码

## 结论

题目将答案称为六字符 `key`，正确值为：

```text
yb6tcr
```

它不是 `flag{...}` 形式。将其输入原始程序后会输出：

```text
恭喜成功！
```

## 题目文件

`题目.rar` 中只有一个文件：`题目.exe`。

| 属性 | 值 |
| --- | --- |
| 格式 | PE32+ x86-64 控制台程序 |
| 打包方式 | PyInstaller |
| 大小 | 7,438,179 bytes |
| SHA-256 | `f6b192f9ee87c4ad2bc8681291ca428cf8e98fec26fa5d7b82c6e791a7a90ead` |

`sample.exe` 与 `extracted/题目.exe` 的 SHA-256 完全一致，因此可将前者作为分析副本。

## 初步排查

PyInstaller CArchive 包含常规引导模块、`base_library.zip`、`PYZ.pyz` 和运行时 DLL。提取并反汇编 `main` 后，内容仅为：

```python
import sys
sys.exit(0)
```

`PYZ.pyz` 中也只有标准库模块。因此表面的 Python 入口是干扰项，真正的题目逻辑不在普通 PyInstaller 脚本内。

直接运行程序会显示一个六字符 key 输入提示，并展示待恢复函数：

```python
def my_function():
    print("恭喜成功！")
```

运行时加载的 `python313.dll` 与官方 Python 3.13.1 DLL 存在显著差异，因此后续分析转向该定制运行时。

## 定位隐藏校验逻辑

进程转储和解包后的运行时显示：修改版 `python313.dll` 中含有 marshal 序列化的 `<frozen os>` 模块。在 DLL 原始文件偏移 `0x4d00e0`，可由 CPython 3.13 加载出一个 code object；其常量中包含新增的 `my_function`，名称表中还包含：

```text
input, key, b_key, c, buf, __code__, replace, co_code, co_consts, succ
```

嵌套的原始函数故意是无害的：

```python
def my_function():
    print(666)
```

修改后的冻结模块尾部可还原为如下等价伪代码：

```python
while x < 20:
    x += 1

# 连接 8 个 16 字节块，对每个字节 XOR 0x55 后打印。
    # 得到的正是题目显示的源码与六字符 key 提示。
    print(bytes(value ^ 0x55 for value in prompt_cipher).decode("utf-8"))

key = input()
    if len(key) != 6:
        continue

key_bytes = key.encode()
    code = xor_repeating(CODE_CIPHER, key_bytes)
    patched = my_function.__code__.replace(co_code=code)

message = xor_repeating(SUCCESS_CIPHER, key_bytes).decode("utf-8")
    patched = patched.replace(co_consts=(None, message))
    my_function.__code__ = patched
    my_function()
```

校验使用的两段密文为：

```text
CODE_CIPHER    = ec626d7563727962367463722a63037563727962367443721e62
SUCCESS_CIPHER = 9fe39b91f5ee9feaa691e9ed96deb7
```

## 反推 Key

`CODE_CIPHER` 的长度为 26，恰好等于原始 `my_function.__code__.co_code` 的长度：

```text
original co_code = 95005b0100000000000000005301350100000000000020006700
```

校验器的核心计算为：

```text
plain_code[i] = CODE_CIPHER[i] XOR key[i mod 6]
```

而希望得到的字节码就在同一个 code object 中，所以可以直接逐字节反推：

```text
CODE_CIPHER XOR original_co_code
= 79 62 36 74 63 72 79 62 36 74 63 72 79 62 36 74 63 72 79 62 36 74 63 72 79 62
= "yb6tcr" 重复
```

因此，唯一同时满足全部 26 个字节约束的六字节周期 key 是：

```text
yb6tcr
```

再用相同 key 解密 `SUCCESS_CIPHER`，可获得 UTF-8 文本 `恭喜成功！`。最终恢复出的函数等价于：

```python
def my_function():
    print("恭喜成功！")
```

## 验证

直接向目标程序输入恢复出的 key：

```bash
printf 'yb6tcr\n' | './extracted/题目.exe'
```

实际输出：

```text
提示，需要还原的代码
def my_function():
    print("恭喜成功！")
请输入key还原代码（请输入6个字符）
恭喜成功！
```

作为反向对照，六字符输入 `abcdef` 不会输出成功信息，而是重新回到输入提示。

## 计算脚本

附带的 [solve_key.py](solve_key.py) 可自动完成字节级恢复。脚本执行流程为：

1. 在给定的修改版 `python313.dll` 中定位 `CODE_CIPHER`。
2. 扫描附近的 marshal 对象起始位置，找到包含它的 `<frozen os>` code object。
3. 提取原始嵌套 `my_function` 的字节码。
4. 计算并验证六字节循环 XOR key。
5. 解密成功信息。

该 DLL 内嵌的是 Python 3.13 marshal / bytecode 数据，应使用 CPython 3.13 运行：

```powershell
C:\python3\python.exe .\solve_key.py C:\path\to\unpacked\python313.dll
```

本次分析的 DLL 来自 PyInstaller 运行时临时 `_MEI...` 目录。该目录名会随进程变化；传入由题目运行时解包或从 CArchive 提取出的 `python313.dll` 即可。

预期输出：

```text
key=yb6tcr
success_message=恭喜成功！
```

## 解题元数据

| 项目 | 值 |
| --- | --- |
| 解题模型 | GPT-5，Codex coding agent |
| 已跟踪 token 消耗 | 1,420,518 tokens |
| 已跟踪解题时长 | 3,819 秒，约 1 小时 3 分 39 秒 |
| 主要静态分析方法 | PyInstaller CArchive 排查、运行时 DLL 对比、CPython marshal 解析、Python 3.13 字节码分析 |
| 动态验证 | 直接通过标准输入验证 `extracted/题目.exe` |

Token 和时长均来自已完成的目标追踪记录。当前环境未暴露更细粒度的 provider/model 标识，因此模型信息记录为 `GPT-5（Codex coding agent）`。

登录后可查看完整内容

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

上传的附件：

solve_key.py （2.39kb，3次下载）

收藏・0

点赞・0

打赏