简介：flaming-shame 是一款面向 Java 逆向工程与安全分析方向的轻量级反混淆工具，适合需要阅读、调试被混淆字节码的开发者与安全研究人员。它通过静态分析手段比较 Java 程序的结构图，尝试自动还原被混淆的类名、方法名与变量名，降低人工逆向成本；受字节码优化与动态绑定影响，其映射结果为最佳猜测而非精确还原，使用时需结合人工判断。资源包共 23 个文件，以 18 个 Java 源码文件为核心，另含 README 说明文档、LICENSE 授权文件、.gitignore 配置及 asm 相关 jar 与源码压缩包，整体约 550KB，便于直接阅读实现或二次开发。目前已有 455 人学习下载，读者可借此理解反混淆的算法思路、结构图比对流程与 ASM 字节码操作实践，并基于源码搭建自己的分析实验环境。
1. 反混淆这件事，为什么值得单独造一个轮子
线上事故排查时拿到一份堆栈，类名是a.b.c，方法名是llllll，字符串全被拆成"\x41\x42"拼接，控制流被拆成一堆while(true)加switch的跳转表——这种代码你盯着看三天也看不出业务逻辑。Java 反混淆工具要解决的就是这个场景：把被 ProGuard、Allatori、Zelix KlassMaster 这类混淆器处理过的字节码，还原成人类能读、能断点、能搜索的形态。flaming-shame就是冲着这个目标做的一个 Java 反混淆工具，它不依赖源码，直接吃.class和.jar，输出可读性更高的字节码或反编译结果。
它适合三类人：做安全审计、需要还原第三方 SDK 真实行为的工程师；做逆向分析、要定位恶意逻辑或漏洞点的同学；以及维护老系统、源码丢失只剩混淆包的倒霉蛋。核心思路不是"猜名字"，而是基于字节码层面的结构信息做还原——常量池、局部变量表、异常表、控制流图，这些在混淆后往往还残留着可用的线索。下面按"能干什么 → 怎么跑 → 参数怎么调 → 坑在哪 → 怎么验证"的顺序讲透。
2. flaming-shame 的还原链路：从字节码到可读逻辑
2.1 它到底改了字节码的哪些部分
反混淆不是单一操作，而是一条流水线。flaming-shame的处理链路大致分四层，每层针对一类混淆手法：
第一层是名称还原。混淆器把getUserInfo改成a，但方法体里对字符串常量、系统属性、反射调用的引用往往还留着语义痕迹。工具会扫描常量池里的字符串、类引用、方法描述符，结合调用图做启发式推断，给方法名和类名打候选标签。
第二层是字符串解密。很多混淆器把明文字符串加密后存进常量池，运行时用一段解密方法还原。flaming-shame的做法是定位解密方法（特征是：入参和返回值都是 String，方法体只做异或/移位/查表），然后模拟执行它，把调用点直接替换成解密后的常量。
第三层是控制流平坦化还原。这是最硬的一层。混淆器把顺序执行的代码拆成基本块，塞进一个switch分发器，用状态变量控制跳转。还原的关键是重建基本块之间的真实前后关系——通过分析状态变量的赋值和 switch 的 case 映射，把分发器"压平"回顺序结构。
第四层是无效代码清理。混淆器会插入大量nop、恒真/恒假分支、无用局部变量赋值。这层做的是死代码消除和常量传播，让输出干净。
2.2 最小可跑通流程：拿一个 class 文件试手
假设你手上有一个混淆过的demo.jar，先解压出单个 class 做实验，避免一上来就处理整个包。
# 解压 jar，取出一个 class 文件 mkdir -p work/classes cd work/classes unzip -o ../demo.jar 'com/example/*' -d . # 用 javap 先看原始字节码，确认混淆程度 javap -p -c com/example/a.class > before.txt wc -l before.txt这一步的目的是建立基线。javap -p会连私有方法一起反汇编，-c输出字节码指令。如果before.txt里全是a、b、c这种单字母名，说明名称混淆很重；如果看到大量lookupswitch或tableswitch，说明控制流被平坦化了。
接下来跑flaming-shame的核心处理。工具通常提供 CLI 入口，参数设计上一般会有输入路径、输出路径、处理阶段开关：
# 对单个 class 做全流程反混淆 java -jar flaming-shame.jar \ --input com/example/a.class \ --output out/ \ --passes rename,string,controlflow,deadcode \ --verbose # 处理完再用 javap 看结果，对比行数和结构 javap -p -c out/com/example/a.class > after.txt diff <(grep -c 'invoke' before.txt) <(grep -c 'invoke' after.txt)--passes是关键参数。四个阶段可以单独开，也可以组合。调试阶段建议一个一个开，比如先只跑string，确认字符串解密正确，再加controlflow。全开容易在某一层出错时难以定位是哪一层的锅。
2.3 处理整个 jar 包时的批量策略
单 class 跑通后，处理整个 jar 要注意类之间的依赖。名称还原如果只看单个类，推断会不准——一个方法被谁调用、调用了谁，这些跨类信息对还原至关重要。
# 全量处理，工具内部会先建调用图再逐类还原 java -jar flaming-shame.jar \ --input demo.jar \ --output demo-deobf.jar \ --passes rename,string,controlflow,deadcode \ --classpath "libs/*:demo.jar" \ --threads 4 \ --log-level info # 输出后重新打包验证 jar tf demo-deobf.jar | head -20--classpath要指向所有依赖 jar，否则工具解析不到外部类引用，调用图会断。--threads控制并行度，类多的时候能明显加速，但注意如果开了rename阶段，并行处理时名称推断需要全局锁，线程数开太大反而会因锁竞争变慢，一般 4 到 8 比较稳。
3. 四个必调参数：字符串解密、控制流、名称推断、超时
3.1 字符串解密：怎么定位解密方法
字符串解密是反混淆里性价比最高的一步，因为解密后的字符串直接暴露业务语义。flaming-shame定位解密方法靠三个特征组合：
- 方法返回类型是
String - 方法体里存在对入参的算术/位运算（异或、加减、移位）
- 方法被大量调用，且调用点传入的是常量
工具内部会先做一次"解密方法候选扫描"，把满足条件的方法列出来，然后逐个模拟执行。这里有个参数控制模拟的深度：
java -jar flaming-shame.jar \ --input demo.jar \ --output out.jar \ --passes string \ --string-max-depth 8 \ --string-max-iter 10000--string-max-depth限制解密方法内部调用链的深度。有些混淆器把解密逻辑拆成多层方法调用，深度设太小会解不出来，设太大又可能陷入递归。8 层覆盖绝大多数情况。--string-max-iter限制模拟执行的指令数上限，防止遇到死循环解密方法时卡死。10000 条指令对正常解密逻辑绰绰有余。
如果解密失败，先看日志里有没有"candidate rejected"字样。常见原因是解密方法用了反射或者依赖外部状态（比如读系统时间做密钥），这种纯静态模拟搞不定，需要手动介入。
3.2 控制流还原：状态变量追踪的边界
控制流平坦化的还原，核心是追踪那个"状态变量"。混淆后的代码结构通常是：
int state = 100; while (true) { switch (state) { case 100: /* block A */ state = 200; break; case 200: /* block B */ state = 300; break; case 300: return; } }还原的目标是把它变回A; B; return;。flaming-shame的做法是：找到 switch 的分发变量，分析每个 case 里对该变量的赋值，建立"块 → 后继块"的映射，然后按映射重建顺序。
java -jar flaming-shame.jar \ --input demo.jar \ --output out.jar \ --passes controlflow \ --cf-max-blocks 500 \ --cf-strict false--cf-max-blocks限制单个方法内参与还原的基本块数量。超过这个数的方法，控制流图会非常复杂，还原容易出错，工具会选择跳过并打警告。500 是个经验值，一般业务方法不会超过。--cf-strict设为true时，只有完全确定后继关系才还原，宁可少还原也不还原错；设为false时会做更多推测，还原率高但可能引入错误跳转。生产环境建议先用true跑一遍看覆盖率，再决定要不要放宽。
3.3 名称推断：启发式规则的权重怎么调
名称还原没有标准答案，全靠启发式。flaming-shame的推断依据包括：字符串常量内容、调用的 JDK 方法、字段类型、继承关系。比如一个方法里反复出现"password"字符串，且调用了MessageDigest.getInstance，那它大概率是密码相关方法，可以命名为encryptPassword之类。
java -jar flaming-shame.jar \ --input demo.jar \ --output out.jar \ --passes rename \ --rename-strategy aggressive \ --rename-prefix "deobf_"--rename-strategy有conservative和aggressive两档。保守档只还原有强证据的名称，比如直接引用了"getUserName"字符串的方法；激进档会做更多联想，还原率高但可能起错名。--rename-prefix给无法推断的方法加统一前缀，方便你区分"工具还原的"和"工具没把握的"。
3.4 超时与内存：大 jar 包的现实约束
处理几百 MB 的 jar 时，内存和超时是绕不开的。JVM 堆要开够，模拟执行和调用图分析都是内存大户。
java -Xmx8g -jar flaming-shame.jar \ --input big.jar \ --output big-out.jar \ --passes rename,string,controlflow,deadcode \ --timeout-per-class 30000 \ --skip-on-error true--timeout-per-class单位是毫秒，单个类处理超过 30 秒就跳过。有些混淆器会故意构造超大方法（几万条指令）来拖垮分析工具，这个参数是保命的。--skip-on-error让工具遇到解析不了的类时跳过而不是整个任务失败，处理大包时必开。
4. 避坑指南：反混淆翻车的五种典型场景
4.1 还原后类加载失败：VerifyError 排查
现象：反混淆后的 jar 一跑就抛java.lang.VerifyError，提示某方法栈不平衡或局部变量类型不匹配。
原因：控制流还原时改动了字节码结构，但没同步更新异常表或局部变量表。JVM 校验器对栈帧要求很严，少一条astore或多一条pop都会挂。
解决：先只开string和rename两个阶段，确认基础还原没问题；再单独开controlflow，用--cf-strict true跑。如果还挂，用javap -v对比还原前后的StackMapTable，看是哪一帧对不上。实在修不了就对该方法跳过控制流还原，保留原始结构。
4.2 字符串解出来是乱码：编码与密钥问题
现象：解密后的字符串显示为????或一堆不可打印字符。
原因：两种可能。一是解密方法用的字符集不是 UTF-8，工具默认按 UTF-8 解码；二是解密依赖的密钥来自运行时环境（比如某个静态字段在<clinit>里才初始化），静态模拟时该字段还是默认值。
解决：检查解密方法的new String(byte[], Charset)调用，确认字符集参数。如果是密钥问题，看<clinit>里有没有对密钥字段的赋值，手动把值填进工具的配置里。flaming-shame一般支持--string-key-override这类参数，允许你指定静态字段的初始值。
4.3 控制流还原后逻辑变了：状态变量被复用
现象：还原后的代码能跑，但行为跟原来不一样，某个分支永远进不去。
原因：混淆器复用了同一个局部变量做状态变量和业务变量。工具追踪状态变量时，把业务赋值也当成了状态跳转，导致后继关系建错。
解决：用--cf-strict true让工具只在证据充分时还原。同时检查还原后的方法里有没有goto指向了错误位置。如果问题集中在某几个方法，把它们加入--cf-skip-methods列表，保留原始控制流。
4.4 处理到一半 OOM：调用图内存爆炸
现象：处理大 jar 时 JVM 抛OutOfMemoryError，堆 dump 显示大量MethodNode对象。
原因：工具默认会把所有类的调用图全量加载进内存。类一多，光方法节点就占几个 G。
解决：加-Xmx是一方面，更有效的是开--lazy-callgraph（如果工具支持），按需加载调用图。另外把--threads降到 2，减少并发时的内存峰值。实在不行就分批处理，按包名切分 jar，处理完再合并。
4.5 反编译工具读不了输出：字节码版本不兼容
现象：flaming-shame输出的 class 用 JD-GUI 或 CFR 打开报错，提示不支持的 class 版本。
原因：工具在写回字节码时，可能把 class 文件版本号改了，或者用了某些反编译器不支持的指令组合。
解决：用javap -v看输出 class 的major version，确认跟输入一致。如果反编译器读不了，先用javap -c看字节码本身是否合法。合法的话就是反编译器的问题，换一个工具（比如用 Procyon 或 Fernflower）再试。flaming-shame一般有--keep-version参数，强制保持原始版本号。
5. 验证还原质量：三个可量化的检查手段
反混淆做完，怎么知道还原得好不好？不能靠"看着像"，得有可量化的指标。
第一个手段是字符串命中率。统计还原后代码里可读字符串（长度大于 3、包含字母）的数量，跟还原前对比。如果还原前常量池里全是加密字节数组，还原后出现了大量"user"、"login"、"token"这类词，说明字符串解密生效了。我一般会写个小脚本扫一遍：
import re def count_readable_strings(javap_output): # 匹配 javap 输出里的 String 常量 pattern = r'// String (.+)' matches = re.findall(pattern, javap_output) readable = [m for m in matches if len(m) > 3 and re.search(r'[a-zA-Z]{3,}', m)] return len(readable), len(matches) with open('after.txt') as f: readable, total = count_readable_strings(f.read()) print(f"可读字符串: {readable}/{total} = {readable/total:.1%}")这个比例能到 60% 以上，说明字符串还原基本到位。低于 30% 就要回去查解密方法定位是不是漏了。
第二个手段是控制流还原覆盖率。工具日志里一般会打"flattened methods detected"和"successfully unflattened"两个数。覆盖率 = 成功数 / 检测数。80% 以上算合格，剩下的 20% 通常是超大方法或状态变量被复用的硬骨头，手动处理。
第三个手段是行为一致性验证。如果原始 jar 能跑（哪怕逻辑被混淆），把还原后的 jar 和原始 jar 在相同输入下跑一遍，对比输出。这需要你有办法触发原始 jar 的逻辑——比如它是个 SDK，写个测试用例调它的公开 API。输出一致，说明还原没有改变语义。这一步最费事但最可靠，关键业务场景建议必做。
最后一个习惯：每次反混淆前，先把原始 jar 和所有中间产物（before.txt、after.txt、工具日志）归档到一个带时间戳的目录。反混淆是个反复试参数的过程，没有后悔药，只有归档能让你随时回退到上一个能用的版本。希望帮到你。
本文还有配套的精品资源，点击获取
