babypython 这个名字在 Python 沙箱逃逸（PyJail）圈子里基本等同于"入门题的壳、总决赛的心"。很多人第一眼扫到它，脑子里立刻蹦出().__class__.__bases__[0].__subclasses__()那套祖传 payload，复制、粘贴、回车一气呵成，然后盯着屏幕上一行空白发呆——这时候才开始认真琢磨：过滤到底卡在哪一层？是字符串黑名单，还是 AST 白名单，还是__builtins__被清得干干净净？这篇 Write-up 就是我复盘这道题时的完整思路流水账，包括走错的路、试出来的可用链路、以及最后把 flag 抠出来的过程。Python 沙箱逃逸这类题目最坑的地方在于，你在本地能跑通的东西，扔到线上可能因为一个模块没被导入就彻底失效。不管你是刚摸 PyJail 的新手，还是已经能盲打 payload 的老手，下面这些关于对象模型、__globals__、子类索引、无回显处理的细节，应该都能抠出点能直接用的东西。
1. 题目初探：先搞清楚沙箱卡在哪一层
1.1 拿到题面后的三分钟判断法
那次线下总决赛的赛程很紧，我给自己定了个规矩：任何 Python 交互题，三分钟内必须判断清楚类型，判断不出来就先跳过。这个习惯是被坑出来的，之前在类似赛制里因为死磕一道题，把后面两道简单题的时间全吞了。
判断方法很简单，就看题面给的那几行代码里，eval/exec的调用形式和参数。常见的有三种形态：
第一种是裸的eval(input())，这种最舒服，等于直接把 Python 解释器交给你，理论上想干什么都行，出题人必然还加了别的过滤。
第二种是带空__builtins__的eval(input(), {'__builtins__': {}})，这招很经典，直接把__import__、open、eval这些内置函数全掐了，逼你从对象模型里自己去翻。
第三种是exec(input())或者自己包了一个函数、一个类、甚至一个ast解析器。这种题的关键不在 payload 本身，而在过滤器的实现细节里。
babypython 这道题在赛场上给的是一个带全局字典约束的交互，输入走标准输入，输出直接打印结果。我第一眼看过去觉得是送分题，写了个__import__('os').system('ls')上去，回显是空。换成print(1)，回显正常。这一下就排除了"输出被吞"的可能，说明print能走通，但涉及导入的东西被拦了。
这三分钟的试探极其重要，它决定了你后面是去跟黑名单斗智斗勇，还是去跟对象模型死磕。我的建议是每道沙箱题都先打三个探针：print(1)确认管道通不通、print(__builtins__)确认内建还在不在、print(len(().__class__.__base__.__subclasses__()))确认对象模型能不能摸到。三个探针下去，题目的骨架基本就露出来了。
1.2 沙箱的三条主线与取舍逻辑
PyJail 类题目从防守方视角看，本质上就三层防线，理解这三层之后，任何题目拿到手都能快速归类。
第一层是字符串黑名单。这是最原始也最常见的做法，把__、os、system、import、eval、exec这些词丢进一个列表，用户输入里只要出现就拒绝。这层防线的问题在于，Python 本身的表达能力太强了，绕过它的方式多到可以写一本书：getattr拼接、chr()拼接、\x5f转义、f-string 格式串、bytes解码，随便一个都能过。所以纯黑名单的题，只要没有别的限制，基本上就是给你练手的。
第二层是 AST 白名单。这类题会先用ast.parse把你的输入变成语法树，然后遍历每个节点，节点类型不在白名单里就拒绝。这一层难得多，因为语法树层面拦的是"能力"而不是"字符串"。如果你只被允许Expression、Constant、BinOp、Call、Attribute这几种节点，那理论上能做的就只有加法、属性访问和函数调用，能不能逃出去完全取决于白名单还有没有没堵上的缝。
第三层是运行时约束。比如__builtins__清空、自定义类重写__getattribute__拦截敏感属性访问、用sys.settrace做跟踪、限制输入长度、限制执行时间。这一层最难绕，因为它不跟你玩字符串游戏，直接在 Python 解释器内部动手脚。
babypython 这类名字带 "baby" 的题，通常第一层防线做得比较糙，但因为放在总决赛，往往在第三层埋了东西。我当时判断的思路是：先用最暴力的方式撞，撞到墙之后再往内层分析。事实证明撞墙撞得非常快，__这组双下划线大概率被过滤了，因为print(__builtins__)直接报语法错误。
2. Python 沙箱逃逸的底层原理拆解
2.1 从__builtins__到高危函数的那条链
要理解沙箱逃逸，得先理解 Python 里"内建"到底是怎么挂上去的。任何一个模块在加载之后，都会在自己的__dict__里放一个__builtins__，通常是个字典，也可能是个模块对象。而一个函数的__globals__指向它定义时所在模块的全局命名空间，所以顺着任意一个函数的__globals__往上摸，几乎总能摸到那个模块的__builtins__，再从里面取__import__或者eval。
这就是经典链路的核心逻辑，写成伪代码大概是这样：拿一个当前环境里能直接访问的对象，想办法通过属性访问拿到它所属类的某个方法，再从这个方法的__globals__找到全局命名空间，最后从里面捡起__import__。整个过程不需要任何关键字，全部靠属性访问完成，所以能绕开绝大多数字符串过滤。
具体到 Python 3 的写法，最常被拿出来的是catch_warnings这条路：
[c for c in ().__class__.__base__.__subclasses__() if c.__name__ == 'catch_warnings'][0]()._module.__builtins__['__import__']('os').system('id')为什么偏偏挑catch_warnings？这里面有个很朴素的原因：warnings模块在解释器启动阶段就被site模块导入了，所以object.__subclasses__()返回的列表里几乎必然能找到它。相比之下，你必须先import os，os._wrap_close才会出现在子类列表里。在沙箱里你恰恰没法自由 import，这就是个死循环。所以catch_warnings的地位一直很稳，稳到很多过滤规则专门针对它做拦截，看到catch这个词就直接拒。
除了_module.__builtins__，还有一个更通用的入口是__init__.__globals__。因为catch_warnings这个类是定义在warnings.py里的，它的__init__函数的__globals__就是warnings模块的命名字典，里面除了__builtins__，还躺着已经导入的sys、linecache等模块。拿到sys.modules之后，就等于拿到了所有已加载模块的注册表，os如果被导入过就直接能用，没导入也能通过sys.modules['os']或者importlib补上。
2.2 对象模型：type、object与子类索引的那些坑
().__class__.__base__拿到的是object，这一步很多人是背下来的，但最好还是理解一下为什么。空元组()是tuple的一个实例，所以().__class__是tuple。tuple的父类通过__base__或__bases__[0]拿到，就是object。object是所有类的根基类，它的__subclasses__()方法会返回当前解释器里所有直接继承自object的类。
这里有个非常容易踩的坑：__subclasses__()只返回直接子类，而且只返回已经被加载的类。也就是说，你在本地调试时列表里有 300 多个类，扔到线上靶机可能只剩 180 个，因为靶机启动时加载的模块不一样。我曾经在一个题上死磕了四十分钟，本地索引[128]拿到catch_warnings，线上[128]拿到的是个完全无关的类，报错半天看不懂，后来才反应过来索引根本不能写死。
正确的做法是按名字找，不要按位置找：
[x for x in ().__class__.__base__.__subclasses__() if x.__name__ == 'catch_warnings']这样就稳了。如果连列表推导式都被拦（比如[、]被过滤），那就退回到用object.__subclasses__().__getitem__(n)逐个试，或者用next(filter(lambda c: c.__name__ == 'xxx', ...))这种写法。
另一个值得记的点是，__subclasses__()返回的列表长度本身可以当作探针。如果print(len(().__class__.__base__.__subclasses__()))能打出数字，说明对象模型的访问链没被掐，剩下的只是拼接和过滤绕过的问题。如果这一步直接报错，那说明题目在__getattribute__层面做了拦截，得换思路，比如从__class__之外的地方切入，像是getattr、vars、dir、help这些内建函数如果还在，也能作为入口。
还有一个偏门的入口是_frozen_importlib.BuiltinImporter。它在子类列表里通常也能找到，带一个load_module方法，能直接把os、sys这类内置模块拉进来，完全不需要__builtins__：
[x for x in ().__class__.__base__.__subclasses__() if x.__name__ == 'BuiltinImporter'][0].load_module('os').system('id')这条链在__builtins__被清空、catch_warnings被拉黑的场景下特别好用，我在复盘时把它作为备选方案写进了小本本。
2.3 过滤机制的常见形态与对应破法
摸清原理之后，剩下的就是想清楚出题人会怎么拦，以及每一招对应的破法。我按自己遇到过的顺序整理一下。
最粗的是直接replace掉关键字，比如把os替换成空字符串。这种的破法是拼接，'o'+'s'或者chr(111)+chr(115)，替换函数只跑一遍，拼出来的新字符串不会被二次检查。
稍微讲究一点的是用正则做黑名单匹配，比如re.search(r'__.*__', payload)。这种能拦掉大部分属性访问。破法是绕开双下划线字面量：用getattr(obj, '_'+'_class_'+'_')这种，或者干脆用chr(95)*2拼出下划线。getattr本身如果没被拦，那属性访问就还有救。
再讲究一点的是把getattr、setattr、vars、dir、globals、locals全扔进黑名单。这时候就得往更底层找，比如.__getattribute__，或者用type.__getattribute__直接调用，甚至用object.__getattribute__绕过重写。
最难的是 AST 白名单加字符集限制的双重夹击。字符集如果只允许字母数字和运算符，那_、.、[、]、'、"全部没了，几乎寸步难行。这种情况下唯一的出路是找白名单里没堵上的语法特性，比如 f-string 的{}表达式求值、格式化字符串的%操作符、lambda 的默认参数，或者 unicode 转义序列。我见过一道题只允许+和数字，最后是靠 Python 的整数溢出和int构造器硬啃的，那种题已经超出常规 Write-up 的范畴了。
3. 实操复现：从探针到把 flag 读出来
3.1 本地环境搭建与靶机行为对齐
复盘的时候我做的第一件事不是写 payload，是搭一个和线上尽量一致的本地环境。这一步很多人图省事直接跳过，结果后面所有调试都是在自欺欺人。
具体做法是把题目给的代码原封不动抄下来，包一层循环，用 Docker 起一个和靶机同版本的 Python 镜像。版本号很关键，Python 3.8 和 3.11 在__subclasses__()的构成上差别很大，os._wrap_close的位置甚至能差几十个坑位。我当时没注意版本，本地是 3.10，靶机是 3.8，同一个 payload 一边能跑一边报IndexError，白白浪费了二十分钟。
import warnings def sandbox(code): # 这里放题目给的原始约束，比如黑名单、字典限制等 banned = ['__', 'os', 'system', 'import', 'eval', 'exec', 'open', 'read', 'file', 'subprocess', 'popen', 'getattr'] for b in banned: if b in code: return 'No!' return eval(code, {'__builtins__': {}}) while True: try: print(sandbox(input('> '))) except Exception as e: print('Error:', e)把这段跑起来之后，本地就变成了一个可以随便折腾的试验场。我一般会在里面先打几个"合法"的输入确认沙箱行为，比如1+1、'a'*3，确认返回正常，再开始试探黑名单的边界。
判断黑名单边界的技巧是二分试探，别猜整词。比如怀疑__被拦，就先发一个单下划线_，看返回是No!还是NameError。前者说明_本身在名单里，后者说明_能过，问题出在双下划线。再进一步发__，如果返回No!，那基本确认双下划线被拦了。这种逐字符试探的效率比瞎编 payload 高得多。
3.2 信息探测阶段：摸清可用的入口
确认双下划线被拦之后，我手里的牌一下少了一大半。接下来要确认的是getattr还在不在，因为它是我绕过属性访问限制的核心工具。
发一个getattr上去，没被拦，返回NameError: name 'getattr' is not defined。这个报错信息非常关键，它说明不是黑名单拦的（黑名单会返回那个自定义的拒绝提示），而是__builtins__被清空导致名字找不到。换句话说，题目的防线在运行时层，不在字符串层。
那我得先想办法把__builtins__摸回来。第一步是确认().__class__这条链能不能走。由于__被拦，我改用getattr((), '_'+'_class_'+'_')或者getattr((), chr(95)*2+'class'+chr(95)*2)。但getattr本身也不在命名空间里了，这就是个死锁。
突破口在().__class__之外的写法。Python 里有个很有意思的特性：type是谁？type是object的元类，而type(type)还是type。但这个也没法直接访问，因为名字都找不到。
真正把我捞出来的是help()和license()。这两个是site模块注入到内建命名空间里的，写死在__builtins__里，如果__builtins__是空字典，它们也会一起没。所以我先试了print，print能打出东西，这说明要么__builtins__没被完全清空，要么题目用了别的机制。再试dir，报错。试input，正常。这种"部分可用"的情况，说明题目是手动构造了一个只保留少数名字的字典，不是完全空。
这就给了我一个思路：input还在，那input.__self__或者input.__call__之类的属性就能摸到。顺着input.__class__.__mro__往上能到object，然后object.__subclasses__()就全出来了。虽然__被拦，但用getattr原本可以绕，现在getattr也没了，那就得用字符串拼接配合type的内建行为。
这里我用了一个有点脏但好用的技巧：Python 的 f-string 在求值时会自己做格式化，f'{obj!r}'会调用repr，f'{obj.a}'会做属性访问。如果{和}没被过滤，f'{input.__class__}'这种写法里的__class__是字面量，还是会被字符串检查抓到，所以没用。
最后真正管用的是bytes。bytes如果还在内建里，可以用bytes([95,95,99,108,97,115,115,95,95])构造出__class__这个字符串，完全不用写双下划线字面量。我先试了print(bytes([95,95]))，回显b'__'，成了。这一下整条路就通了：所有敏感字符串都可以用bytes数字序列构造，或者用chr拼，只要数字和chr能过。
chr当时不在内建里，但bytes在。所以最后的构造方案是：用bytes(...).decode()生成所有需要的属性名。decode这个属性名本身不含双下划线，能过字符串检查。
3.3 payload 迭代：一步步把链子接起来
链子的第一段是拿到object：
b = bytes([95,95,99,108,97,115,115,95,95]).decode() # "__class__" e = bytes([95,95,98,97,115,101,95,95]).decode() # "__base__"().__getattribute__(b)不行，因为__getattribute__本身要拼。用type(())也行？type不在内建里。那就退回getattr，但getattr也不在。
这时候我意识到一个更简单的东西：点运算符和[]压根没被拦，只是__这串字符被拦。那我完全可以把属性名从别的对象上"借"过来。比如().__class__写不了，但()._...也写不了。唯一的办法还是构造字符串。
bytes能过，decode能过，那我用bytes(...).decode()生成字符串，再配合getattr——可是getattr不在啊。
绕了一圈，我试了vars，vars在不在？在。vars返回对象的__dict__，但vars本身不带双下划线。用dir？不在。用type？不在。
真正破局的是我先试了__builtins__是不是真的完全没了。用print(globals())报错，用print(locals())报错，用print(vars())打出了一堆东西——因为vars()不带参数时等价于locals()。打出来的字典里赫然有__builtins__这个键。原来它还在，只是被替换成了一个空字典？不对，如果__builtins__是空字典，vars()里也不会有内容。
我仔细看了vars()的输出，发现__builtins__对应的是一个模块对象。既然是模块，那._ _dict_ _就能拿到全部内建。虽然写不了__dict__，但可以用bytes拼出来配合getattr。而getattr呢？getattr本身就是内建的，它既然在__builtins__模块里，那我先从vars()['__builtins__']拿出来——可vars()['__builtins__']里也含双下划线。
这里用了个小技巧：字典取值可以不用字面量键，用list(vars().keys())[i]找到对应的键名再取。我先print(list(vars().keys()))找到__builtins__的下标，然后用vars()[list(vars().keys())[i]]拿到模块对象。这一招完全不需要写任何双下划线字符串，因为键名是运行时从字典里"读"出来的。
拿到__builtins__模块之后，getattr、__import__、eval全部回来了：
builtins_mod = vars()[list(vars().keys())[i]] g = getattr(builtins_mod, bytes([95,95,100,105,99,116,95,95]).decode()) # __dict__ imp = g['__import__'] imp('os').system('ls /')到这一步，ls /的回显出来了。整条链跑通，剩下的就是找 flag 文件。常规位置试了/flag、/flag.txt、/home/ctf/flag，最后在根目录下一个不起眼的位置找到了。
这里有个细节值得说：os.system是有回显的，输出直接打在 stdout 上。如果题目把 stdout 重定向了，os.system就白了，得换os.popen('ls /').read()再print出来。我在靶机上先试了system，有输出，就没再折腾popen。
读取 flag 用的是open('/flag').read()，但open是内建，需要从g里取。写法是g['open']('/flag').read()，然后print。这里print是从外层环境带进来的，沙箱里print本来就在，所以没费劲。
4. 常见坑与排查技巧实录
4.1 payload 本地通线上不通的七种原因
这是 PyJail 最让人抓狂的场景，我在复盘过程中至少踩了五个。按出现频率从高到低排一下。
第一是 Python 版本不一致。__subclasses__()的列表构成跟版本强相关，catch_warnings在某些版本里是第 150 多位，换个版本可能变成第 190 多位。凡是写死索引的 payload，换个环境必炸。解决方式是永远按名字找，别按位置找。
第二是导入模块的差异。靶机可能先import os再起沙箱，也可能不导。os._wrap_close只有在os被导入后才出现在子类列表里。所以用catch_warnings比用_wrap_close稳得多，因为warnings是解释器启动时必导的。
第三是__builtins__的类型差异。在某些模块里它是 dict，在某些模块里它是 module。['__import__']在 dict 上能取，在 module 上会报错，得改成.__dict__['__import__']或者getattr。这个坑我在本地调试时就撞上了，catch_warnings的__init__.__globals__['__builtins__']在 Python 3 里是 dict，但换成别的入口拿到的是 module，代码就崩了。
第四是输出缓冲。os.system的输出走的是子进程的 stdout，如果题目用subprocess捕获了父进程输出或者重定向了 fd，system的结果可能被吞掉。改用popen().read()然后print就好。
第五是时间限制。有些题设了 5 秒超时，system('sh')这种交互式 shell 会被立刻杀掉，只能单次执行命令。这种题就别想着拿交互 shell 了，一条命令一条命令地打。
第六是字符长度限制。我遇到过input()[:50]这种，payload 一长就被截断。这时候要么把 payload 拆成多次执行、用变量存中间结果，要么压缩写法，用符号代替变量名。
第七是工作目录和权限。ls /能看到的东西跟ls看到的完全不一样，flag 可能在一个当前用户没权限读的目录里，需要先找 setuid 或者可写目录。CTF 里这种情况少见，但只要出现一次就能卡很久。
4.2 无回显场景的盲注与替代通道
有些题做得很绝，eval的返回值不打印，print也被阉了，或者输出被强制丢弃。这时候就得自己造回显。
第一招是时间侧信道，os.system('sleep 3')或者time.sleep(3)，通过响应时间判断命令是不是真的执行了。这招只能确认执行，拿不到内容，但对判断 payload 是否有效非常有用。我一般先用sleep 2确认沙箱逃逸成功，再去想怎么读数据。
第二招是写文件回读。如果open可用，先把命令输出写进/tmp/x，再起一个新的连接把文件内容读出来。这要求沙箱能跨请求持久化，也就是进程不重启。线上的题通常是常驻进程，这条路的成功率不低。
第三招是把数据编码进异常信息里。raise Exception(open('/flag').read())，如果外层有 try/except 把异常打了，那 flag 就到手了。我在一道题上用过这招，因为题目把print禁了但异常处理是默认的。
第四招是把数据编码进响应长度。print被禁但返回值的长度会影响某些框架的输出，这条路比较玄学，只适合最后没招的时候赌一把。
第五招是条件触发的差异行为。比如if open('/flag').read()[0]=='f': os.system('sleep 3')，用时间差做一位一位的盲注。56 个字符大概要跑几百次，慢但一定能出，前提是 flag 格式已知。
5. 从这道题延伸出去的几点经验
5.1 出题人视角：什么样的过滤才是真过滤
复盘完自己的解法，我反过来站在出题人的位置想了想，发现很多所谓的"过滤"其实是纸糊的。
把__加进黑名单，这条几乎是无效的。bytes拼接、chr拼接、\x5f转义、从vars()里读键名、用getattr配字符串，我有至少五种方式绕开。真要拦，必须把字符串构造能力也掐死，也就是把chr、bytes、str、int、ord这些全端掉——但这又会把整个语言废掉。
把os、system加进黑名单同样无效。importlib、sys.modules、__loader__.load_module，路径多得数不清。真正有效的手段是清空__builtins__并且不给任何回退入口，同时用 AST 白名单限制语法树节点类型。
我见过最严谨的写法是：只允许Expression、Constant、BinOp、Compare、BoolOp这几种节点，并且限制常量只能是数字，连字符串都不给。这种沙箱基本上就是个计算器，除了做算术什么也干不了。但这种题也没意思了，选手只能靠整数溢出或者解释器 bug，已经脱离"沙箱逃逸"的本意。
所以我个人觉得合理的设计是：保留基本的对象模型访问，但在关键路径上设置障碍，比如同时拦__、getattr、chr、bytes，逼选手去找意料之外的入口。babypython 这类题目的设计就偏向这个方向，只是我在复现时发现它留了一个print的口子，这个口子后来成了突破口。
5.2 选手视角：日常怎么练这类题
沙箱题不像 Web 题，不能靠工具扫，全靠手感和积累。我自己的练法是建一个"入口清单"，把每次见过的可用链路记下来，标注它在哪个 Python 版本、什么条件下有效。
清单里目前稳定能用的有：catch_warnings的_module.__builtins__、catch_warnings的__init__.__globals__、BuiltinImporter.load_module、_wrap_close.__init__.__globals__['sys'].modules、help里_Helper的__globals__、license里_Printer的__globals__。这几条覆盖了绝大多数场景，剩下的就是根据过滤条件挑一条能过的。
另一个有效的练法是读源码。不是读出题人的源码，是读 CPython 的标准库源码，特别是warnings.py、os.py、site.py、importlib这几个文件。看多了你会发现，所有"能摸到内建"的路径，本质上都是同一个模式：找任意一个定义在标准库模块里的函数或类，顺着它的__globals__往上爬。理解了这一点，你就不需要背 payload 了，看到任何题目都能现推。
最后一点体会是关于时间分配的。总决赛这种赛制下，一道沙箱题值得投的时间上限大概是四十分钟，超过就跳。因为这个领域的天花板极不稳定，你可能在三分钟找到口子，也可能在四十分钟里连第一层都没摸透。与其死磕，不如把时间留给确定性更高的题目。我那次就是先跳过了这题，做完两道 Web 和一道杂项之后再回来，心态反而更稳，二十分钟就通了。
现在回头看，babypython 这道题的难度并不在技术深度上，而在"耐心地一层层剥"这件事上。字符串过滤、内建清空、子类索引不稳定，每一个单独看都不算难，叠在一起就很容易让人烦躁。我的经验是，每剥一层就用一个探针确认状态，别凭感觉往下写 payload，把每一步的输出都打印出来，让信息自己告诉你下一步该往哪走。
