简介面向CTF比赛和离线环境下的解码需求这份小巧工具由GitHub上的开源项目优化而来专门处理Brainfuck、Ook与Short Ook三种编码文本既适合CTF新手快速理解这类谜题也适合进阶选手在无法联网的机房、考场或内网环境中完成本地解码。压缩包整体仅13KB共5个文件3个txt分别存放brainfuck、ook和short ook的样例数据1个py为可直接运行的Python解码脚本1个png为执行效果截图核心逻辑与样例分离便于替换成题目密文进行调试无需依赖在线服务。目前已有7950人学习下载对CTF新手及需要准备离线工具链的参赛者都有参考价值。资源虽小但已经把解码逻辑、多种编码样例和预期效果整理到同一包内使用者可通过样例快速核对脚本行为也可以将解码函数抽出嵌入自己的解题流程作为常态化备用的离线解码模块。1. 为什么“解码”Brainfuck 的难点从来不是解释器拿到一段 Brainfuck / OoK 解码脚本的需求时大多数人第一反应是“这玩意不是有现成解释器吗”。但真正做过一次样本分析就会发现跑起来只完成了三分之一的工作——Brainfuck 和 OoK 本质上不是加密算法而是把程序逻辑压缩成极小的指令集解码的价值在于把这一堆符号还原成能看懂的真实行为而不是让脚本结束运行。反直觉的地方在于解释器本身几十行就能写完难的是后面这层“语义还原”。这套脚本解决的是三类场景CTF 逆向题里被故意混淆的 flag 校验逻辑、恶意代码里内嵌的 Brainfuck 变种 payload、以及老旧工具里用 OoK 包装的下载逻辑。适合读这篇文章的人是那些已经在终端里见过[-----].这种输出一串乱码却不知道下一步该怎么办的分析者以及想在一小时内给自己配一个轻量解码工具链的开发。下面从指令集映射开始一步步把脚本补成能落地的东西。2. Brainfuck 与 OoK 的指令映射先建立最小虚拟机模型2.1 八条指令背后的虚拟机模型Brainfuck 只有八个命令却对应一个功能完整的抽象虚拟机一段无限长的一维字节数组、一个可以在数组上移动的数据指针、以及一套基于当前指针所指单元内容的读写操作。理解这个模型比背指令更重要因为所有“解码”工作都是在还原这个模型的执行轨迹。Brainfuck 指令语义说明OoK 常见编码三词一组数据指针右移一格Ook. Ook.数据指针左移一格Ook. Ook?当前单元数值加一默认 0-255 循环Ook? Ook.-当前单元数值减一Ook? Ook?.把当前单元的值作为字节输出Ook! Ook!,从输入读一个字节写入当前单元Ook! Ook.[当前单元为零则跳到匹配的]之后Ook. Ook!]当前单元非零则跳回匹配的[之后Ook! Ook?注意 OoK 的编码表在不同实现里有过细微差别网上流传的版本并不是完全统一。我一般会在脚本里维护一张映射表而不是把转换逻辑写死在代码分支里这样遇到不同编码约定时只需要改表不用动主流程。OoK 的特点是每个 Brainfuck 指令被拆成三个“Ook 单词”三词一组的顺序和标点组合构成实际指令所以解析时不能按字符直接替换必须先把文本切成 Ook 单词序列再按三元组映射。2.2 抢先判定一段样本是不是 Brainfuck / OoK 家族在把脚本扔给解释器之前先做一次静态特征判定能省掉大量无意义的运行时间。Brainfuck 的特征非常明显整个有效字符集只有-.,[]八个其他字符在经典实现里会被当作注释忽略。OoK 的特征更是只有Ook、.、?、!四种词法单元。我在实战里常用一个两步过滤法第一步从可疑字符串中提取候选字符第二步统计有效指令占比和括号配平情况低于阈值直接放弃。def looks_like_bf(text: str) - dict: target set(-.,[]) allowed [c for c in text if c in target] ratio len(allowed) / max(len(text.strip()), 1) depth 0 min_depth 0 for c in allowed: if c [: depth 1 elif c ]: depth - 1 min_depth min(min_depth, depth) return { valid_ratio: ratio, bracket_balanced: depth 0, bracket_never_negative: min_depth 0, potential: ratio 0.3 and depth 0, }这个函数的逻辑是把可疑文本里的 Brainfuck 有效字符筛出来计算它们在整体内容里的占比同时检查方括号是否配平、是否出现负数深度——负数深度意味着]比[早出现基本可以判定不是合法的 Brainfuck。括号是否配平是比字符集更可靠的判据因为混淆样本往往会保留完整的循环结构而随机字符串很难天然配平。判定阈值0.3是我自己的经验值。纯 Brainfuck 源码的占比接近 1.0但如果样本外层包了 shellcode 或十六进制字符串有效占比会明显下降。低于这个值不一定是错的只是不值得继续投入。OoK 的判定类似但词法提取要复杂一点需要把三词一组切成完整的三元组我留到下一章和预处理入口一起讲。3. 手写解码执行器从最小解释器到 Ook 预处理3.1 一个带括号预匹配的最小解释器解释器的核心逻辑不难维护一个字节数组和一个指针按指令逐条执行。但直接“逐条解释”在遇到深层循环时会非常慢工程上更常用的做法是先做一次括号配对表的预计算循环跳转直接查表时间复杂度从平方级降到线性。def build_bracket_map(code: str) - dict: stack [] mapping {} for idx, ch in enumerate(code): if ch [: stack.append(idx) elif ch ]: if not stack: raise ValueError(f括号不匹配: 位置 {idx} 处出现多余的 ]) start stack.pop() mapping[start] idx mapping[idx] start if stack: raise ValueError(f括号不匹配: 位置 {stack[-1]} 处的 [ 没有闭合) return mappingdef bf_execute(code: str, input_bytes: bytes b, cell_wrapTrue, mem_size30000): code [c for c in code if c in -.,[]] bracket build_bracket_map(code) mem [0] * mem_size ptr 0 input_pos 0 output bytearray() step_count 0 max_steps 10_000_000 while step_count len(code) and step_count max_steps: ch code[step_count] if ch : ptr (ptr 1) % mem_size elif ch : ptr (ptr - 1) % mem_size elif ch : mem[ptr] (mem[ptr] 1) 0xFF if cell_wrap else min(mem[ptr] 1, 255) elif ch -: mem[ptr] (mem[ptr] - 1) 0xFF if cell_wrap else max(mem[ptr] - 1, 0) elif ch .: output.append(mem[ptr]) elif ch ,: mem[ptr] input_bytes[input_pos] if input_pos len(input_bytes) else 0 input_pos 1 elif ch [: if mem[ptr] 0: step_count bracket[step_count] elif ch ]: if mem[ptr] ! 0: step_count bracket[step_count] step_count 1 return bytes(output)这段代码里的三个设计点值得细说。第一个是cell_wrap参数——经典 Brainfuck 的内存单元是 8 位无符号整数加满 255 再加一应该回到 0但有的样本是按照“无限精度整数”来写的两边解释器行为不一致时输出就会分叉所以这个开关必须暴露出来。第二个是输入字节耗尽时的 EOF 行为这里返回 0是业界常见约定另一个常见选择是返回-1会在输出流尾部多出一串0xFF遇到这种差异时看输出尾部就能判断样本是按哪种约定写的。第三个是max_steps上限虽然拿了循环步数上限当保护但这里的递增逻辑是每执行一条指令加一真正的循环次数可能远大于代码长度10 万步对多数样本足够但遇到刻意写的死循环样本时依然会被卡住后面避坑章会专门再处理。3.2 Ook 预处理先转成 Brainfuck 再进解释器OoK 的样本长这样Ook. Ook? Ook. Ook! Ook. Ook.空格和换行都可能出现在任意位置。处理时先归一化标点再把连续的 “Ook 单词 标点” 切分成词法单元最后按三元组映射回 Brainfuck。import re OOK_MAP { (Ook., Ook.): , (Ook., Ook?): , (Ook?, Ook.): , (Ook?, Ook?): -, (Ook!, Ook.): ,, (Ook!, Ook!): ., (Ook., Ook!): [, (Ook!, Ook?): ], } def ook_to_bf(text: str) - str: 宽松模式忽略所有不在 Ook 词法单元里的字符。 严格模式遇到无法识别的字符直接抛错用于校验样本完整性。 tokens re.findall(rOok[.?!], text) if len(tokens) % 3 ! 0: raise ValueError(fOok 词法单元数量不是 3 的倍数: {len(tokens)}) bf_chars [] for i in range(0, len(tokens), 3): key (tokens[i], tokens[i 1], tokens[i 2]) if key in OOK_MAP: bf_chars.append(OOK_MAP[key]) else: raise ValueError(f无法映射的 Ook 三元组: {key}) return .join(bf_chars)这个函数的关键参数是re.findall(rOok[.?!], text)——它只提取完整的“Ook 标点”词法单元标点类型和单词之间不允许插入空格。转换完成后输出的字符串可以直接丢给上一节的bf_execute形成一条“Ook 样本 → Brainfuck 中间表示 → 执行结果”的完整链路。遇到长度不是三的倍数的情况直接抛错这是我在处理恶意样本时养成的习惯宁可报错也不要静默丢弃尾部数据因为尾部很可能藏着下一层 payload 的长度标记。4. 解码不是跑通把 Brainfuck 痕迹翻译成可读逻辑4.1 指令流压缩把 5000 个变成一行赋值执行器跑完只是拿到了输出字节但分析一个 Brainfuck 样本的真实诉求往往是“它到底做了什么计算”。直接看原始指令流不现实一个典型的字符串输出程序可能包含连续几百个。这时候要做指令流压缩——把连续的同类型指令合并成一条带参数的语句。def compress_bf(code: str) - list: 把连续同类指令合并成 [op, count] 结构。 移动指令和加减指令可以合并循环与 IO 指令不合并。 result [] for ch in code: if result and result[-1][0] ch and ch in -: result[-1][1] 1 else: result.append([ch, 1]) return result压缩后的指令流可以直接转成伪代码连续出现 n 次就是mem_ptr n连续出现 n 次就是mem[ptr] n。但这一步只是“翻译”还没有到“理解”。真正让分析省力的是对循环结构的模式识别——Brainfuck 只有一种循环结构就是[和]包裹的指令块但它能表达while、if、甚至memset三种语义区别在于循环体对当前单元做了什么。4.2 识别最常见的一种循环语义清零操作比较常见的模式是进入循环时当前单元非零循环体内只有-或最终把当前单元减到零后循环自然退出。这种循环实质上是一个“把当前单元清零”的操作在分析时可以直接折叠成一条赋值语句不用关心它循环了多少次。def fold_zeroing_loops(compressed: list) - list: 匹配模式: [ 当前单元非零 - 循环体只含 /- - 单元归零 ] 满足条件的循环整体折叠为 mem[ptr] 0 folded [] i 0 while i len(compressed): if compressed[i][0] [: body [] j i 1 depth 1 while j len(compressed) and depth 0: op compressed[j][0] if op [: depth 1 elif op ]: depth - 1 if depth 0: break body.append(compressed[j]) j 1 if depth 0 and body and all(op[0] in - for op in body): net_change sum((1 if op else -1) * count for op, count in body) if net_change 0: folded.append([zero_clear, 1]) i j 1 continue folded.append(compressed[i]) i 1 return folded这里的net_change 0判断是整个折叠逻辑的核心循环体里加的量和减的量相等说明不管循环跑多少轮最终效果就是把当前单元变成 0。这个模式在真实样本里出现频率非常高因为很多 Brainfuck 编译器用这种循环做临时变量复位。折叠能识别的模式有限但它提供了一个可扩展的分析框架后面遇到“指针移动 加减”的搬运模式往这个函数里再加一个匹配分支就行。解码脚本的价值就在这里——不追求把任意 Brainfuck 程序反编译成人类友好代码而是把样本里高频出现的固定模式快速标注出来让分析者把时间花在真正复杂的逻辑上。5. Brainfuck 解码脚本避坑指南四个真实翻车现场5.1 跑起来 CPU 直接拉满脚本再也没返回现象把样本喂给解释器后进程占用一个核心 100%十分钟过去没有输出只能强制 kill。原因构造的样本里有一个合法的循环但循环体内指针不断右移并给新单元加一永不回退。由于 Brainfuck 的循环条件只看当前单元是否为零只要这个单元的值在循环体内没有被修改循环就永远不会退出。这个行为在语义上完全合法不是解释器 bug。解决给解释器加一个真正的“指令执行次数”硬上限。前面代码里的max_steps是保护但默认值不能设得太小否则合法的大循环样本会被误杀。我的习惯是分两步走先用max_steps1_000_000跑一遍如果达到上限再改成max_steps10_000_000并用mem_size100000重跑两次都触顶基本可以判定是恶意死循环直接停止分析。5.2 输出全是对的但终端显示全乱码现象解释器返回的字节流在终端里显示成空白或乱码同一个样本在自己电脑上输出正常。原因内存单元默认按 8 位无符号整数处理这没问题。问题出在cell_wrap参数上——如果样本期望单元是无限精度整数而解释器用了 8 位回绕加法溢出会导致输出字节流整体错位。另一个常见原因是终端把字节流按 UTF-8 解码而样本输出的是二进制数据比如0x80、0xFF这类字节在 UTF-8 里是非法的。解决解释器出口永远返回bytes解码动作交给调用方。在命令行使用时先把输出写到文件再用十六进制查看器打开而不是直接打印到终端。分析恶意样本时尤其要习惯xxd / od -An -tx1这些工具肉眼直接看终端输出是最容易踩坑的习惯。5.3 被假阳性骗了检测脚本判定是 Brainfuck实际是普通字符串现象一段十六进制转储的文本被判定为“高度疑似 Brainfuck”花了半小时写映射表结果发现只是恰好字符集命中的普通数据。原因looks_like_bf只看字符集占比和括号配平这两个条件对随机二进制数据其实很容易满足尤其是把十六进制字符串转回 bytes 后其中的-等符号出现概率不低。恶意样本的外层经常包裹一层 base64 或十六进制直接解码后形成的中间层恰好“长得像” Brainfuck这就是典型的假阳性翻车。解决加一条硬性规则——OoK 样本必须能被完整分词Brainfuck 样本的有效指令比例必须超过 0.5且括号配平检查要在“剔除注释字符之后”再做而不是在原文本上做。我的经验公式是比率大于 0.5 才值得跑解释器0.3 到 0.5 之间先做轨道分析低于 0.3 直接放弃。这条阈值看起来像玄学但它背后是真实样本的字符分布规律误差容忍度还不错。5.4 内嵌在脚本里的 Brainfuck 代码识别出来了但提取不干净现象从一段脚本中提取 Brainfuck 代码时开头和结尾残留了几个字符导致括号永远配不平解释器报错。原因样本在外层嵌入了长度标记比如前四个字节是代码长度解码脚本把这四个字节也当成 Brainfuck 指令提取了[]数量失衡。或者是外层字符串拼接时混入了\0和不可见字符。解决提取脚本增加一个“前导长度标记解析”分支。常见格式是 4 字节 little-endian 长度标记可以先把原始数据按这个格式解析如果解析出的长度与后续指令总量一致就按标记截断不一致再回退到全量提取。这个逻辑放在looks_like_bf之前因为长度标记通常落在数据头部。另外一个更稳妥的做法是提取后先跑括号配平配平失败时自动截掉头尾各一个字符再试试两轮后仍然失败就报错。不要在这上面写复杂的启发式样本格式千变万化保留手动指定位移的参数比自动猜测更实用。6. 给解码脚本装上“安全气囊”步数计数与痕迹校验这一章不做新功能而是把前面所有模块收拢成一个可复用的分析习惯。我每次拿到一个新样本不会直接跑完整执行而是先跑一遍“计数模式”——执行器内部维护每个指令的执行次数遇到循环时记录循环进入的位置和次数。这个模式有两个实际用途第一确认样本不会死循环第二通过循环分布判断样本的复杂度。如果发现某个[被执行了数万次而这个循环对应的代码逻辑只有一行加法基本能猜到它是某种延迟混淆不用跑完就能跳过。python3 bf_decoder.py --count-only --max-steps 100000 evil.bin.bf输出里能看到每个括号指令的执行次数统计。次数分布异常集中的位置就是分析重点。之后再用完整执行模式跑配合--dump-mem把内存快照导出和计数模式的结果对照基本能把一个陌生样本拆干净。这个验证思路来自我早期的一次踩坑某次分析一个被混淆过的脚本内嵌的 Brainfuck 循环次数是天文数字当时没做计数限制挂机跑了一整夜第二天发现还在循环。现在我的习惯是任何解释器入口都要带--count-only和--max-steps两个参数没配这两个参数的解码脚本我不会拿它跑陌生样本。最后留一个有用的技巧分析完一个样本后把它的执行指令序列和内存快照存成一个归约谜面。下次遇到同类样本时先比对指令序列前缀而不是完整执行很多混淆变种只改了数据区指令流前缀完全一致比对能省大量时间。希望帮到你。本文还有配套的精品资源点击获取
