[原创] KCTF260A 第十题曦光初现 Writeup-CTF对抗-看雪安全社区

[原创] KCTF260A 第十题曦光初现 Writeup

发表于: 2026-8-23 18:18 3864

[原创] KCTF260A 第十题曦光初现 Writeup

HHHso

2026-8-23 18:18

3864

# KCTF260A 第十题 · 曦光初现 Writeup

**人言** 
  - 最开始用的Zcode 和 GLM 5.3，但轻量的订阅计划（2000/五小时，10000/周）用过的应该都会有如鲠在喉的感觉，没办法，没法退；而单独购买的资源包统计又十分的拉垮和不透明，比如一个亿的token，怎么用余额都不变，就突然归零，也没有用量统计；一个不注意还得自己去找原因，用不同API接口，否则订阅计划会顺带锁死单独购买的资源包，还整天发短信给你说资源包快过期，就是不告诉你怎么反锁死。
  - 看到2000/五小时积分没多久就要罢工了（等五小时后重置才能再用），于是让GLM 5.3 汇总工作形成MarkDown。
  - 接着用DSH（Deepseek Harness）配合 Deepseek-v4-Flash 读取上面的工作MarkDown，继续后续工作，花了2块3毛完成本地拿shell验证和远程拿shell和获取flag。
  - 也用了Qoder国内版本，Zcode和DSH两部分的工作，Qoder CN使用Auto都没做好：（1）Qoder也从头开始，一直做不到Zcode的工作进度；（2）后面接手Zcode的工作也一直在歧路上，DSH简单的Flash模型都干完了，Qoder还在wsl测试。
  - 总言之，Zcode表现可圈可点，就是订阅计划恶心了些；Qoder这次表现就比较拉垮；DSH+Flash收尾表现惊艳，性价比无敌，这里当然没法抹去Zcode前面打的基础。这也算是手工验证了Hermes的AoM模式（两个或多个模型规划决策对齐，然后由一个强模型执行）的一种变种。

**AI 言**

> 十二辰终,曦光初现,是为新始。
> 破壁人立于塔顶,看第一缕阳光刺破永夜,照在十重试炼之上。

**题目文件**:`pwn`(x86-64 PIE / stripped / C++)+ `libc-2.27.so`(Ubuntu 18.04)
**靶机**:`nc 123.57.66.184 10099`
**最终战绩**:本地 root shell(3/3 稳定),远程 `flag{6a433994-ca43-4c12-9e4b-6b87c35f4b4e}`

这题是整个 KCTF260A 的收官之战。它没有菜单、没有堆叠打印、没有任何数据回显——程序唯一的"语言"只有三种:**沉默**、`invalid syntax!` 和 `runtime error!`。一个刻意做成的**盲注**世界:永夜之城,你在黑暗里摸索,直到找到那道唯一的光。

本文分两部分:第一部分是 Zcode + GLM-5.3 从零逆向到移交的分析攻关;第二部分是 Deepseek Harness(DSH)接手后突破最后一个卡点、拿下 flag 的收尾实录。

---

# 第一部分 · 摸黑逆向:从 26KB 的沉默开始

*(执行:Zcode 编码智能体 + GLM-5.3,2026-08-23 12:02 – 14:00,全程无人工干预)*

## 0x01 初见:一个不说话的解释器

`file pwn`:ELF64 PIE,stripped,依赖 libstdc++。`checksec` 级别的信息一眼扫完:Full RELRO(BIND_NOW)、NX、Canary——**所有传统出口都被焊死**。

跑起来是这样的:

```
> $1+$1
> $hello
invalid syntax!
> $999999999999999999+$1
runtime error!
```

成功 → 沉默;解析失败 → `invalid syntax!`;求值失败 → `runtime error!`。**没有数值输出,程序也不退出。** strings 里能看到的只有:`"> "`、`"invalid syntax!"`、`"runtime error!"`、`"run out of memory, garbage collection has not been implemented yet"` 和一个 `/dev/urandom`。

最后那句"垃圾回收尚未实现"是个黑色幽默——它会成为理解整道题的钥匙之一。

## 0x02 骨架:main 与命令语言

`objdump -d -M intel` 全量反汇编塞进 `full.asm`(约 2500 行),从 entry 的 `__libc_start_main` 参数定位 main(`0x2d09`)。读出来的骨架:

1. 启动:`setbuf(stdin/stdout/stderr, NULL, _IONBF)`;
2. **静态初始化**(`0x2f77`):`new[](0x10000)` 分配一块 64KB 堆 arena,指针存入 bss `0x206aa0`(begin)/`0x206aa8`(cur);随后在栈上构造 ifstream 读 `/dev/urandom` 8 字节,存入 `0x206ab0`——随机 **key**;
3. REPL:打印 `"> "` → `getline(cin, buf, 256)` → 调 `0x2b14` 解析求值 → **求值成功后 delete 命令对象树**(`0x2e35`)。

`0x2b14` 是命令分发器:输入必须以 `$` 开头,前导十进制数字(寄存器号,要求 ≤255)之后按**跳转表**(基址 `0x3fa8`,索引 = 字符 - 0x25)分发。这里埋着本阶段的第一个坑,也是第一处"手感"的考验:

> **跳转表解码错位一格,把 `=` 看成了 `<`。**
> 静态算出的表项把 `<`(0x3c)映射到 store/deref 分支,实测全部 `invalid syntax!`。用 gdb 断在 switch 处单步,才发现真正的操作符是 **`=`**(0x3d),`<` 是默认分支。差一格,谬以千里。

修正后,六类命令的完整语义浮出水面:

| 语法 | 类 | 求值语义 |
|---|---|---|
| `$N=<纯数字>` | C | `regs[N] = 数字 & 0xFFFFFFFFFFFF`(**48 位截断**) |
| `$N=[a,b,...]` | C | 嵌套 list **序列化**追加进 arena(cur 处),`regs[N] = 0x1337<<48 \| cur` |
| `$N=$M[i][j]...` | D | 沿 `regs[M]` 结构按路径走,叶子解码值存 `regs[N]`(满 64 位) |
| `$N[i][j]...=$M` | E | 沿 `regs[N]` 结构走,叶子写 `regs[M] ^ key`(满 64 位) |
| `$N<op>$M` | F | `regs[N] = regs[N] <op> regs[M]`,op∈{+,-,*,/,%,^,&,\|} |

配套的内存模型(全部 PIE 相对):

| 地址 | 含义 |
|---|---|
| `0x2062a0` | **寄存器文件 regs[0..255]**(eval 的 rsi 指向此处) |
| `0x206aa0 / 0x206aa8` | arena `begin` / `cur` |
| `0x206ab0` | 8 字节随机 **key** |
| `0x205938…0x205a20` | 六个类的 vtable |

## 0x03 数据结构:beef 与 1337 的双重编码

这是全题最精巧的设计。序列化到 arena 里的每个 qword 都与 key 异或:

- **list 头**:`(0xbeef<<48 | 子节点数) ^ key`,子节点紧随其后;
- **常量叶子**:`value(48位) ^ key`;
- 值的高 16 位是类型 tag:`0x1337` = arena 指针(只有 class B 的 eval 会产生),`0xbeef` = list 头。

而"走路径"的原语 `1eda(node, arg)`(符号地址,由 class D/E 的 eval 反复调用)逻辑是:

1. 解码 `[node]`(XOR key),必须 beef-tag 且 `arg ≤ count`,否则失败;
2. 返回 `node + 8 + 8*arg`——**逐槽向前跳**,途中遇到解码恰好是 beef 的槽会递归整棵子树(概率 2^-16,可忽略);
3. **只向前走**(地址单调递增),复杂度 O(arg)。

读(D)在叶子上做 `key ^ [leaf]`,写(E)在叶子上落 `regs[A] ^ key`——**一进一出,key 恰好抵消**。这个"抵消"后来成为零 oracle 泄漏的基石。

## 0x04 漏洞:伪造 beef 头 → OOB 读写

只要能在 arena 里写出一个"假 list 头",walker 就会以我们宣称的 count 为准向前走——**越过 arena 的 64KB 边界,读/写其后的整个堆**。

构造假头只需要算术:

```
$1=281474976710655          # 2^48-1
$2=48879                    # 0xbeef
$2*$1                       # 0xbeef*(2^48-1)
$3=48879
$2+$3                       # 0xbeef<<48
$2+$1                       # 0xBEEFFFFFFFFFFFFF = beef | huge
$7=[5,6]                    # 先有一块合法结构:arena = [beef|2][5][6]
$7[1]=$2                    # E 写:arena+16 变成假头(count = 2^48-1)
```

此后 `$X=$7[1][arg]` / `$7[1][arg]=$V` 就是 `arena+24+8*arg` 处的任意读/写——**arg 可以是 40 亿以内的任何数**,只要走得到。

## 0x05 三泄漏:key / libc / PIE,全部进寄存器

盲注题的传统打法是 1-bit oracle 二分探值,一泄就是上百次交互。这里有一条漂亮得多的路——**让泄漏直接留在寄存器里,全程无需看见**:

1. **key**:读一个从未写过的 arena 槽(新拓堆页为 0)→ `regs = key ^ 0 = key`;
2. **libc**:本地 gdb 观察发现 arena 之后有个启动期残留 chunk(0x230),其中 `arena+0x10078` 恒为 `&_IO_2_1_stderr_` = `libc+0x3ec680`;
3. **PIE**:读**当前读命令自身**的 class D 对象 vptr——求值期间对象还活着,位置 deterministic(实测 `arena+0x102f0`,值 `pie+0x2059d0`)。

读出来的是 `key ^ 真值`,再 `$reg^$20`(key)即得裸值。**0 次 oracle,3 个基址。**

> 这一步踩掉的坑值得一记:最初读的是"上一条命令遗留对象"的 vptr 槽——但 main 求值后会 **delete 命令对象**,槽位被 free 复用清零,读到 0。那个"garbage collection has not been implemented yet"的字符串果然是烟雾弹:**垃圾回收实现得很好**,所以必须读"自己"。

## 0x06 伪造 0x1337-tag 指针:进位的艺术

F 类算术禁止 0x1337-tag 操作数(这正是防伪造的检查),但加法天然带进位:

```
0x1336FFFFFFFFFFFF + (X+1) = 0x1337<<48 | X
```

`0x1336FFFFFFFFFFFF` 高位是 0x1336,不触发检查;`X+1` 是 48 位裸值,也不触发。一次加法,合法地造出任意 tagged 指针。**先算 X+1,再加 tag-1**——方向错了就会差 1(这个坑留给第二部分的主人公再踩一次)。

## 0x07 改写 arena 全局:begin 解锁,cur 重定向

把假头写进 `regs[200]`(注意 walker 解码会再 XOR key,所以锚点要存 `beef|huge ^ key`——又一个静默坑),伪造 `0x1337|(pie+0x2068e0)`,从寄存器区向前走:路径 `[55]` 落在 `begin`、`[56]` 落在 `cur`。

- `begin = 0xFFFFFFFFFFFF` → 序列化器的越界检查 `cur+count*8 <= begin+0x10000` **对任何 cur 都通过**;
- `cur = libc + 0x3ed8d0`(`__free_hook-0x18`)→ 下一次 `$N=[...]` **序列化直接写进 libc .bss**。

至此,收尾链的设计已经完整:

```
序列化在 __free_hook 下方布 beef 头 → 伪造 libc 指针 → E 写 __free_hook = system
→ 发送 >15 字符的非法行 → 其堆字符串在求值前被 free(0x2dfc)→ system("/bin/sh;#..")
```

触发点选在"行字符串 free"而非程序退出,是因为 atexit 里 arena 析构会拿被改写的 begin 去 delete[]——脏,但那是拿到 shell 之后的事。

## 0x08 移交状态与攻坚成本

Zcode + GLM-5.3 阶段的产出沉淀为 **ANALYSIS.md**(完整逆向语义、vtable 表、堆布局、已验证原语、卡点与排查方向)与 `exploit.py`(45 条命令的全链雏形)。本地 socat + patchelf 出的 glibc2.27 原生运行环境下:

- ✅ cmd1–36 全部静默通过:bootstrap、三泄漏、算术链、伪造 bss 指针、**begin/cur 双写**;
- ❌ **cmd37 `$30=[1,2,3]`(向 libc 序列化):响应为空,进程死亡**——唯一卡点;
- ⬜ cmd38–45(伪造 libc 指针 → 写 hook → 触发)未能跑到。

期间为贴近远程环境搭了整套复现设施:从 Ubuntu 18.04 deb 解包 `ld-2.27.so / libc / libstdc++ / libgcc / libm`,patchelf 重写 PT_INTERP 与 RUNPATH 得到原生运行的 `pwn27`,再用 socat 起本地服务配 gdb(关 ASLR 后 PIE 基址固定 0x555555400000)逐断点验证。

**本阶段用时与成本**:

| 项目 | 数值 |
|---|---|
| 总用时 | **约 1 小时 56 分钟**(12:02–14:00) |
| 阶段划分 | 逆向语义与 vtable 梳理 ~40min;原语构造与本地验证 ~55min;cmd37 卡点排查 ~21min |
| 工具调用 | Bash/Read/Write 等约 200+ 次;gdb 脚本 22 个(v1–v22);中间产物 60+ 文件 |
| 上下文消耗 | 累计约 1.5M tokens(全量反汇编多次进出上下文) |
| 成本 | **约 ¥20**(按 GLM-5.3 计费口径估算,精确账单以平台为准) |

> 简评:GLM-5.3 在"读 2500 行无符号 Intel 汇编还原一套 DSL 语义"上表现出色——六类对象、双重 XOR 编码、walker 递归语义全部一次推对;三个致命坑(操作符 `=`、锚点 `^key`、对象生命周期)也都在 2–3 轮试错内用 gdb 实锤。最后停在 cmd37,属于"设计正确、收尾欠一哆嗦"。

---

# 第二部分 · 破晓:DSH 的最后一公里

*(执行:Deepseek Harness,模型 deepseek-v4-flash,14:03 接手 ANALYSIS.md)*

## 0x09 复现的第一课:矛盾现象

DSH 接手后第一件事不是改代码,而是**复现**:

- 管道喂 `seq.txt`(`./pwn27 < seq.txt`):**所有命令都活着**;
- socat + socket 跑 `exploit.py`:cmd31/36 无报错,**cmd37 响应为空 → 连接断**。

同一份命令,两种死法。DSH 判断:先修数据一致性,再看崩溃。

## 0x10 根因一:一个 0x50 的常量笔误

对比发现 `seq.txt` 第 15 条是 `$25=2120224`(= `0x205a20`,class F vtable),而 `exploit.py` 生成的是 `$25=2120144`(= `0x2059d0`,class D vtable)。手工改坏的旧文件让 PIE 基址差了 0x50:

- 伪造的 bss 锚点 `0x1337|(pie+0x206890)` 比真实的 `regs[200]@pie+0x2068e0` **低 0x50**(差 10 个寄存器);
- walker 解码锚点得到的是 `key` 而非 beef → E 写静默失败 → begin/cur 根本没改 → 管道流里 cmd37 只是普通 arena 序列化,自然不崩。

**修复**:用 `gen_seq.py` 从 `exploit.py` 重新生成序列,杜绝手工文件。

## 0x11 根因二:序列化的"死亡数学"

修正常量后,cmd37 的死活从"薛定谔"变成"必死"——这才暴露真正的根因。gdb 断在序列化器(`0x31dc`)与越界检查(`0x3201`):

- `begin=0xffffffffffff`,`cur=libc+0x3ed8d0`,检查通过,序列化正常完成;
- SIGSEGV 落在 `libc+0x97bf5`——**`call *%rax`,正是 free() 里的 `__free_hook` 调用点**。

死亡回放:`$30=[1,2,3]` 在 cur 处写入 4 个 qword:header@`0x3ed8d0`、子@`0x3ed8d8`、`0x3ed8e0`、**`0x3ed8e8`**——第三个子恰好落在 `__free_hook` 上,写入 `3 ^ key`(随机垃圾)。求值成功,main delete 命令对象树,第一个 `free()` 发现 hook 非空,`call` 一个非规范地址,SIGSEGV。

而且这**不是巧合,是数学上不可避免的死局**:

> 要从某个 beef 节点 walk 到 hook,叶 `node+8+8*arg = hook` 且 `arg < count`——那么序列化器写的第 `arg` 个子**必然**落在 hook 上,值 = `字面量 ^ key`(运行期随机)。单次序列化必然污染 hook,而 hook 一旦污染,本命令自己的 delete 就会引爆它。

备选思路被逐一否决:嵌套列表只能平移末子位置;`arg == count` 的越界叶被 E-eval 预检 `arg < count` 禁止;想在解析期用 `key^key=0` 抵消——盲注拿不到 key。

## 0x12 意外之坑:libc .bss 里的 stdio 锁

把锚点下移到 `hook-0x20` 试图避让?硬件 watchpoint 立刻抓到凶手:`0x3ed8c8` 被反复写 0 ↔ `0x7ffff7ff6080`,**每一次打印都发生**。核对 FILE 结构:stderr+0x88 → `0x3ed8b0`,stdout+0x88 → `0x3ed8c0`——那是 **stderr/stdout 的 `_IO_lock_t`**。锚点放这儿,头刚布好就被 stdio 清零。

实测安全区只有 `0x3ed8d0..0x3ed8df`。

## 0x13 阶梯(Ladder):不碰 hook 的两步走

死局的解法是**分两次落子**:

```text
第 0 级  $30=[1,2]      序列化 @0x3ed8d0:header(beef|2)^key、1^key@0x3ed8d8、2^key@0x3ed8e0
                        ── 第三个子没了,2^key 落在 __after_morecore_hook(触发前无人用)
                        ── __free_hook 保持 0,本命令的 delete 正常执行 ✔

第 1 级  伪造 0x1337|(libc+0x3ed8d0)
         E 写 $24[1]=$2  *(0x3ed8e0) = beef|2 ^ key   ← 在 hook-8 布下第二个 beef 头

第 2 级  伪造 0x1337|(libc+0x3ed8e0)
         E 写 $25[0]=$22 从新头走 arg=0 → 叶 = 0x3ed8e8 = __free_hook
                        *(hook) = system               ← 一击致命
```

序列化负责"到 hook 门口但不进门",E 写负责"从隔壁台阶一步跨进 hook"。两者都不是单独可行——组合起来,死局解开。

## 0x14 最后三颗螺丝

收尾阶段又拧出三个语义级 bug(每个都由 gdb 实锤):

1. **F-eval 结果写左操作数**:`$22+$25` 是 `regs[22] += regs[25]`。方向搞反,曾把寄存器算成 `0x1337000000000010`,E 写直接对地址 0x10 做 `xor`,当场 SIGSEGV;
2. **tag 指针不能过 F-eval**:对已带 `0x1337`-tag 的指针 `+1`,F-eval 检查失败返回 0,**加法被静默跳过**,指针永远少 1。正解仍是进位技巧:`X+1` 先算,再加 `0x1336FFFFFFFFFFFF`;
3. **E 写的 XOR 双重语义**:落盘是 `regs[A]^key`,walker 解码再 `^key`——写"给 walker 看的数据"(beef 头)用**裸值**,写"程序直读的数据"(begin/cur/hook)用**预 XOR key** 的值。同一类写命令,两种编码习惯,错一次整链报废。

另外,`hook=system` 设置之后,**本命令自己的 delete 就会触发若干次 `system(对象内存)`**——实测无害:对象首字节是 vptr 的小端序列(`\xf8\x59@UUU`),sh 报 "not found" 秒退,不读 stdin。这也是 hook 必须放在最后一条写命令的原因。

## 0x15 破晓

本地 socat,53 条命令全部静默:

```
$ /bin/sh;#AAAAAAAAAAAA     ← 17 字符(>15)非法行,堆字符串在求值前被 free
sh: 1: ...: not found       ← 残留对象触发的无害噪音
$ id
uid=0(root) gid=0(root)    ← 3/3 稳定复现
```

远程 `123.57.66.184:10099`:53 条命令同样全绿,jail shell(uid=1000,`/dev/null` 不可写,连 `id` 都没有),`getflag.py` 专门做了无重定向兼容——

```
$ cat flag
flag{6a433994-ca43-4c12-9e4b-6b87c35f4b4e}
```

**DSH 阶段用时与成本**(引自 DSH_ANALYSIS.md):

| 项目 | 数值 |
|---|---|
| 总用时 | **约 50 分钟**(14:03 接手 → 14:36 本地通 → 14:40 远程 flag → 14:50 writeup) |
| 耗时分布 | 复现差异 ~5min;双根因定位 ~20min;阶梯实现与收尾 bug ~10min;验证+拿旗 ~5min;文档 ~10min |
| 成本 | **约 ¥2.3**(deepseek-v4-flash) |

---

# 尾声 · 第一缕阳光

复盘整条链,它的美在于**每一环都在跟"看不见"作斗争,却没有一次向"看不见"低头**:

```text
假 beef 头 ──→ arena 越界读写 ──→ key/libc/PIE 三泄漏(零 oracle,全进寄存器)
    │
进位伪造 0x1337 指针 ──→ 改写 begin/cur ──→ 序列化重定向进 libc .bss
    │
阶梯两步:门口布头 + 一步跨入 ──→ __free_hook = system
    │
一行 17 字符的废话 ──→ free() ──→ system("/bin/sh;#..") ──→ 曙光
```

设计者的防御几乎无懈可击:随机 key 编码、tag 检查、walker 只进不退、序列化上限、"垃圾回收"回收了每一个对象——而攻击者用**编码的自抵消**(XOR 一进一出)、**进位的合法性**(加法不检查结果)、**锁与锁之间的缝隙**(0x3ed8d0 那 16 字节的安全区),把每一条规则都变成了踏脚石。

两个智能体的接力也值得记录:GLM-5.3 用两小时在黑暗里画完了整张地图,停在离 flag 一步之遥的 cmd37;DSH 用五十分钟找到那两个藏得极深的根因(一个 0x50 的笔误,一个"序列化末子必污染 hook"的数学死局),用阶梯方案完成最后一步。**总共约 2 小时 46 分钟、约 ¥22 的成本**,永夜城迎来了它的第一个白天。

红裙女孩站在街角,抬起头——她终于等到了白天。

而路灯熄灭的位置,正好是 `__free_hook` 被写成 `system` 的那一行。

---

## 附录 A · 关键常量速查

```python
M48            = (1<<48)-1
LIBC_STDERR_   = 0x3ec680    # _IO_2_1_stderr_,位于 arena+0x10078
LIBC_FREE_HOOK = 0x3ed8e8    # 0x3ed8e0 = __after_morecore_hook(阶梯第二头)
LIBC_SYSTEM    = 0x4f420
ANCHOR_OFF     = 0x3ed8d0    # hook-0x18,序列化锚点(唯一安全区)
D_VTABLE       = 0x2059d0    # class D vtable(PIE 泄漏;勿用 F 的 0x205a20!)
REGS_BSS       = 0x2062a0
BSS_ANCHOR_REG = 200         # pie+0x2068e0;begin 路径 arg=55,cur arg=56
PIE_PTR_SLOT   = 0x102f0     # arg=8283;STDERR_SLOT=0x10078(arg=8204);ZERO_SLOT=0x8018(arg=4096)
# 走路径 arg = (slot_off - 24) // 8(锚节点 = arena+16)
# libc 陷阱:0x3ed8b0/0x3ed8c0 是 stderr/stdout 的 _IO_lock_t,每次打印被写,不可用
```

## 附录 B · 环境部署一句话版

从 bionic deb 解出 `ld-2.27.so + libc/libm/libstdc++/libgcc`,patchelf `--set-interpreter/--set-rpath` 得到原生 2.27 运行的 `pwn27`(膨胀到 2MB 是 interp 串加长触发新段);socat 本地起服务;gdb 关 ASLR(PIE 固定 0x555555400000)断点直接写 `0x55555540xxxx`。全链运行期取址,ASLR 开关无关——这正是远程一次通过的原因。

## 附录 C · 文件清单

| 文件 | 说明 |
|---|---|
| `ANALYSIS.md` | 第一阶段移交报告(逆向语义/原语/卡点) |
| `DSH_ANALYSIS.md` | 第二阶段完整实录(根因/阶梯/验证) |
| `exploit.py` | 最终 53 条命令利用脚本 |
| `getflag.py` | 远程拿旗(无重定向,兼容 jail) |
| `gen_seq.py / trace_seq.py` | 序列再生成 / 逐命令存活追踪 |
| `full.asm` | 全量反汇编 |
| `v*.gdb` | 两阶段 gdb 验证脚本 |
| `pwn / libc-2.27.so` | 题目原件 |
| `solve_remote.py` | 单一运行拿本地或远程shell和flag |

---

*十二辰尽,曦光初现。时辰流转,守护永存。*

登录后可查看完整内容

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

上传的附件：

ctf0a_files.zip （925.26kb，3次下载）

收藏・0

点赞・6

打赏

最新回复 (1)
yber 雪币： 9 活跃值： (425) 能力值： ( LV6，RANK：90 ) 在线值：发帖 3 回帖 167 粉丝 0 关注私信	yber 2 楼有AI TOOL真好 2026-8-25 17:50 1
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

HHHso

发帖

回帖

2198

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (1)
yber 雪币： 9 活跃值： (425) 能力值： ( LV6，RANK：90 ) 在线值：发帖 3 回帖 167 粉丝 0 关注私信	yber 2 楼有AI TOOL真好 2026-8-25 17:50 1
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

[原创] KCTF260A 第十题 曦光初现 Writeup

[原创] KCTF260A 第十题曦光初现 Writeup