简介：flaming-shame 是一款面向 Java 逆向工程与安全分析场景的开源反混淆工具，适合需要阅读、调试被混淆字节码的开发者与安全研究人员。它通过静态分析手段对 Java 程序的结构图进行建模与比对，尝试自动还原被混淆的类名、方法名与变量名，从而提升 .class 或 .jar 文件的可读性。需要说明的是，受字节码优化、多态与动态绑定等因素影响，该工具给出的是最佳猜测映射，而非完全精确的还原结果。资源包共 23 个文件，以 18 个 Java 源码文件为主体，另含 README 说明文档、LICENSE 授权文件、.gitignore 配置以及 asm 相关 jar 与源码压缩包，整体约 550KB，便于直接阅读实现或二次开发。目前已有 455 人学习下载，读者可借此理解反混淆的算法思路、结构图分析流程与工程组织方式，并在此基础上开展自己的字节码分析实践。
1. 反混淆工具选型：为什么我最后留下了 flaming-shame
去年做移动端逆向时，我手里同时开着三款 Java 反混淆工具，其中两款是商业版试用，一款是开源项目。结果最让我意外的，是那个名字看起来最不正经的 flaming-shame——它没有花哨的界面，没有云服务，甚至文档都写得像随手记的笔记，但它在处理控制流平坦化和字符串加密这两类混淆时，稳定得让我把另外两个试用版都卸载了。
这篇文章不打算写成工具说明书，而是想把我这段时间用 flaming-shame 做 Java 反混淆的选型判断、实际效果对比、以及踩过的坑，完整摊开讲一遍。如果你正在被 ProGuard 或者 Allatori 处理过的 jar 包折磨，或者你手头有一堆需要批量还原的 class 文件，那这篇内容应该能帮你省下不少试错时间。我会从它到底能解什么、解不了什么、怎么配、怎么调、什么时候该换工具这几个角度，给出一个可以直接抄作业的结论。
2. flaming-shame 能解什么：四类混淆的还原效果实测
2.1 控制流平坦化的还原逻辑与参数调整
控制流平坦化是 Java 混淆里最烦人的一种，它把原本线性的执行逻辑打散成一个巨大的 switch 分发器，每个基本块只负责一小段计算，然后通过一个状态变量决定下一步跳哪里。人眼读这种代码基本等于看天书，因为真正的执行顺序被藏在状态变量的赋值里。
flaming-shame 处理这类混淆的思路是：先做支配树分析，找出分发器的入口块和所有 case 块，然后根据状态变量的常量传播结果，重建基本块之间的真实跳转关系。我一般会先跑默认配置，看它能不能把主分发器拆掉，如果拆不干净，再手动调两个参数。
# 基础用法：直接对单个 class 文件做反混淆 java -jar flaming-shame.jar --input ./obfuscated/ --output ./deobf/ --mode cff # 关键参数说明： # --mode cff 指定处理控制流平坦化 # --max-iter 5 状态变量传播的最大迭代次数，默认3，复杂混淆可以加到5 # --keep-line 保留原始行号信息，方便后续调试 # --log-level debug 输出详细日志，排查还原失败时用这里--max-iter是我调得最多的参数。有些混淆器会把状态变量做多层嵌套，比如先算一个中间值，再用中间值去查表得到下一个状态。默认 3 次迭代只能还原两层，遇到三层嵌套就会漏掉部分跳转。我一般先跑默认值，如果反编译出来的代码里还有大量switch嵌套，就加到 5 再跑一次。但注意别加太大，超过 8 之后收益基本为零，反而会拖慢处理速度。
另一个容易忽略的是--keep-line。默认情况下 flaming-shame 会重写行号，让反编译结果更紧凑，但如果你后续要跟原始堆栈做对比，或者需要定位某个方法在源码里的位置，这个参数就很有用。我一般在第一轮分析时开着，确认还原效果后再关掉重新生成一份干净的。
2.2 字符串加密的识别与批量解密
字符串加密在商业混淆里几乎是标配，常见做法是把所有字符串常量加密后存到一个静态数组里，运行时通过一个解密函数还原。手动还原的话，你得先找到解密函数，理解它的算法，然后写脚本批量跑。flaming-shame 内置了几种常见的解密模式识别，包括 XOR 变种、AES 固定密钥、以及基于字符数组的查表法。
实测下来，它对 XOR 和查表法的识别率最高，基本能到九成以上。AES 固定密钥的识别要看混淆器有没有把密钥拆散，如果密钥是硬编码在一个静态字段里，它能直接提取出来解密；如果密钥是通过多个字段拼接生成的，就需要手动补一个密钥提取脚本。
// 典型的字符串解密函数结构（混淆后） public static String a(int i) { char[] c = b[i]; // 从静态数组取密文 for (int j = 0; j < c.length; j++) { c[j] = (char) (c[j] ^ key[j % key.length]); // XOR 解密 } return new String(c); }flaming-shame 遇到这种结构时，会先做模式匹配，识别出b数组和key字段，然后模拟执行解密逻辑，把所有调用点替换成明文。如果它没识别出来，通常是因为key字段被拆成了多个变量，或者解密函数里混入了无关的计算。这时候我会用--string-mode manual让它只做标记不做替换，然后自己写个小脚本处理。
2.3 类名与方法名混淆的映射重建
名称混淆是最基础的一种，把UserService改成a，把getUserName改成b。单独用这种混淆的工具不多，因为效果有限，但很多商业混淆器会把它和其他手段叠加使用。flaming-shame 处理名称混淆的方式是建立映射表，但它不会自动重命名成有意义的名字——那需要人工介入或者额外的语义分析。
它做的是：把所有被混淆的类、方法、字段整理成一张表，标注出哪些是外部调用的入口（比如实现了特定接口、被反射调用、或者出现在配置文件里），哪些是内部使用的。这样你在分析时就能优先看那些入口点，而不是在一堆a.b.c()里迷路。
# 生成名称映射表 java -jar flaming-shame.jar --input ./obfuscated/ --output ./deobf/ --mode rename --export-map map.txt # map.txt 格式示例： # CLASS a -> com.example.UserService (根据继承关系推断) # METHOD a.b -> getUserName (根据字符串常量推断) # FIELD a.c -> userName (根据 getter/setter 推断)这个映射表不是百分百准确，但能帮你快速定位关键代码。我一般会结合反编译器的交叉引用功能，把映射表里的入口点逐个过一遍，确认核心业务逻辑的位置。
2.4 反射与动态调用的处理边界
反射是反混淆工具的天敌。如果混淆器把方法调用改成了Class.forName("a").getMethod("b").invoke(...)这种形式，静态分析基本就断了。flaming-shame 对反射的处理比较保守，它会尝试追踪字符串常量的来源，如果Class.forName的参数是一个已经解密出来的明文字符串，它就能还原出目标类；如果参数是运行时拼接的，它就无能为力了。
我遇到过最棘手的情况是混淆器把类名拆成多个片段，运行时用StringBuilder拼起来再加载。这种 flaming-shame 只能标记出可疑的反射调用点，需要手动跟进。好在大多数商业混淆器不会把反射用得太复杂，因为那会影响运行性能，所以实际遇到的概率不算高。
3. 横向对比：flaming-shame 和另外两款工具怎么选
3.1 对比维度与权重分配
选反混淆工具不能只看“能不能解”，还要看解出来的代码可读性、处理速度、对批量任务的支持、以及出问题时的排查难度。我一般从五个维度打分：还原完整度、代码可读性、处理速度、批量能力、调试友好度。权重上，还原完整度和代码可读性各占三成，剩下三个维度分四成。
| 维度 | 权重 | 说明 |
|---|---|---|
| 还原完整度 | 30% | 控制流、字符串、名称三类混淆的还原比例 |
| 代码可读性 | 30% | 还原后代码的结构清晰度、变量命名合理性 |
| 处理速度 | 15% | 单个 class 平均处理时间，批量任务总耗时 |
| 批量能力 | 15% | 是否支持目录递归、并行处理、断点续跑 |
| 调试友好度 | 10% | 日志详细程度、失败原因提示、参数可调性 |
3.2 三款工具的实际表现对比
我拿同一个混淆过的 jar 包（大约 2000 个 class，包含控制流平坦化和字符串加密）分别跑了三款工具，结果如下：
| 工具 | 还原完整度 | 代码可读性 | 处理速度 | 批量能力 | 调试友好度 |
|---|---|---|---|---|---|
| flaming-shame | 85% | 中高 | 快 | 强 | 强 |
| 工具B（商业试用） | 90% | 高 | 中 | 中 | 弱 |
| 工具C（开源） | 70% | 中 | 慢 | 弱 | 中 |
工具B的还原完整度确实最高，它有一个基于机器学习的名称推断模块，能把a.b.c()还原成类似userService.getUserName()的形式。但它的批量处理需要手动分批，而且日志基本只报成功失败，不告诉你为什么失败。工具C是纯开源项目，处理速度慢，遇到复杂控制流容易卡死，但它的插件机制比较灵活，可以自己写扩展。
flaming-shame 的优势在于平衡。它的还原完整度不是最高，但代码可读性够用，批量处理直接支持目录递归和并行，日志会明确告诉你哪个 class 的哪个方法还原失败、失败原因是什么。对我来说，能快速定位问题比多还原几个百分点更重要。
3.3 什么场景选 flaming-shame
如果你手头的任务是批量处理大量 class 文件，而且需要反复调试还原参数，flaming-shame 是最省心的选择。它的命令行参数设计得很直接，日志也够详细，遇到问题能快速定位。如果你只处理少量文件，而且对代码可读性要求极高，愿意花时间手动调整，那工具B可能更适合。工具C适合喜欢自己写扩展、不介意折腾的人。
我自己的习惯是：第一轮用 flaming-shame 做批量粗还原，把明显能解的部分处理掉；剩下那些它标记为失败的 class，再用工具B逐个精修。这样既保证了速度，又不会在个别硬骨头上浪费太多时间。
4. 避坑指南：反混淆过程中最容易翻车的五个点
4.1 现象：还原后的代码编译不通过
原因：flaming-shame 在替换字符串常量时，如果遇到转义字符处理不当，会把\n变成实际的换行符，导致字符串字面量跨行。另外，控制流还原后可能产生不可达代码，某些编译器会直接报错。
解决：加--escape-string参数让工具保留转义序列，不要直接输出原始字符。对于不可达代码，用--remove-dead让工具在还原后做一次死代码消除。如果还是编译不过，就只还原控制流不还原字符串，分两步走。
4.2 现象：处理到一半卡死，CPU 占满但没输出
原因：控制流平坦化的支配树分析在遇到某些循环结构时会进入死循环，尤其是当状态变量的取值范围没有正确收敛时。这是静态分析类工具的常见问题，不是 flaming-shame 独有的。
解决：加--timeout 30给每个 class 设置处理超时，超时后跳过并记录到失败列表。同时把--max-iter降到 2，减少迭代次数。如果某个 class 反复卡死，就单独把它拎出来，用--mode string只做字符串还原，控制流部分手动处理。
4.3 现象：字符串解密后出现乱码
原因：混淆器在加密字符串时可能用了非 UTF-8 编码，比如 GBK 或者 ISO-8859-1。flaming-shame 默认按 UTF-8 解码，遇到其他编码就会乱码。
解决：加--charset gbk指定正确的字符集。如果不确定原始编码，可以先用--string-mode detect让工具自动检测，它会尝试几种常见编码并输出置信度最高的结果。我一般会先用 detect 跑一遍，确认编码后再用 manual 模式批量处理。
4.4 现象：名称映射表里大量条目是空的
原因：混淆器把名称信息完全抹掉了，没有留下任何可推断的线索。比如它把所有类都命名为a、b、c，方法都叫a()、b()，字段也没有 getter/setter。这种情况下任何工具都无能为力，因为信息已经丢失了。
解决：接受现实，把精力放在理解代码逻辑上，而不是纠结名字。我一般会手动给核心类和方法打上注释，用反编译器的重命名功能逐步建立可读的命名体系。这个过程很耗时，但比对着a.b.c()硬猜要靠谱。
4.5 现象：批量处理时内存溢出
原因：flaming-shame 默认会把所有 class 加载到内存里做全局分析，如果 jar 包特别大（比如超过 500MB），JVM 堆内存不够就会 OOM。
解决：加-Xmx4g给 JVM 分配更多内存，同时用--batch-size 500让工具分批处理，每批处理完就释放内存。如果还是不够，就用--no-global关闭全局分析，只做单个 class 的局部还原。局部还原的完整度会低一些，但至少不会崩。
5. 从手动到自动：我的 flaming-shame 工作流收尾
用 flaming-shame 这段时间，我最大的体会是：反混淆没有银弹，工具能帮你省掉八成体力活，但剩下两成需要你对字节码和混淆原理有足够的理解。我现在的标准流程是：先用--mode all跑一遍全量还原，拿到一份粗加工的结果；然后根据日志里的失败列表，逐个分析失败原因，调整参数重跑；最后把还原后的代码导入 IDE，结合映射表做人工梳理。
有一个技巧我一直在用：把 flaming-shame 的输出目录直接挂到反编译器的监控路径下，这样每次重新还原后，反编译器会自动刷新，不用手动重新加载。另外，我会把每次运行的参数和结果记录在一个文本文件里，方便回溯——因为不同批次的混淆可能用了不同的混淆器版本，参数需要微调。
回过头看，最开始我总想找一个能一键解决所有问题的工具，结果浪费了很多时间在工具切换上。后来想明白了，反混淆本质上是一个“信息恢复”的过程，工具只是帮你把还能恢复的信息提取出来，真正丢失的信息需要靠人工推理补全。flaming-shame 的价值在于它把能自动化的部分做得足够稳定，而且失败时能告诉你为什么失败，这就够了。
从那以后我每次拿到新的混淆样本，都强制走一遍“全量还原 → 日志分析 → 参数调优 → 人工梳理”的流程，不再指望一步到位。希望这套思路和 flaming-shame 这个工具，能帮你在反混淆的路上少踩几个坑。
本文还有配套的精品资源，点击获取
