简介flaming-shame 是一款面向 Java 逆向工程与安全分析场景的开源反混淆工具适合需要阅读、调试被混淆字节码的开发者与安全研究人员。它通过静态分析手段比较 Java 程序的结构图尝试自动还原被混淆的类名、方法名与变量名降低人工逆向成本受字节码优化、多态与动态绑定影响其映射结果属于最佳猜测而非精确还原使用者需结合人工判断。资源包共 23 个文件以 18 个 Java 源码文件为核心另含 README 说明文档、LICENSE 授权文件、.gitignore 配置及 asm 相关 jar 与源码压缩包整体约 550KB便于直接阅读实现或二次开发。目前已有 455 人学习下载读者可从中了解基于 ASM 字节码操作与结构图比对的反混淆思路并借助源码与文档快速上手实践。1. 反混淆这件事为什么值得单独拎出来聊接手过一个二手的 Java Web 项目war 包解压出来class 文件里的方法名全是a、b、c字符串常量被拆成\u0068\u0065\u006c\u006c\u006f这种形式控制流里塞满了永远走不到的分支。想改一个业务逻辑得先花两天把混淆后的代码还原成人能读的样子。这就是 Java 反混淆工具存在的意义——它不是给逆向工程炫技用的而是给那些需要维护、审计、二次开发遗留系统的工程师用的。flaming-shame 就是这样一个 Java 反混淆工具名字起得挺有意思功能上走的是静态分析加字节码重写的路子。它适合谁适合手里有混淆过的 jar/war 包、需要快速恢复可读性的后端开发也适合做代码审计的安全工程师。下面把我拆这个工具的过程和踩过的坑摊开讲。2. flaming-shame 的字节码处理链路从 class 文件到可读源码2.1 它到底在字节码层面做了什么Java 混淆器常见的有 ProGuard、Allatori、ZKM 这类干的事无非几类标识符重命名、字符串加密、控制流平坦化、无用代码注入、反射调用替换直接调用。flaming-shame 的反混淆策略不是去“解密”某一种特定混淆器的输出而是从字节码本身的结构特征出发做几件事第一恢复标识符的可读性。它不会凭空猜出原始方法名但会基于方法签名、调用关系、字段访问模式给混淆后的a()、b()生成带语义的占位名比如getUserById_restored。这一步靠的是对常量池和方法描述符的交叉分析。第二字符串常量还原。很多混淆器把字符串拆成字符数组或者用 XOR 加密后存进静态字段在clinit里解密。flaming-shame 会模拟执行clinit中的解密逻辑把结果回写到常量池。这一步是它比较核心的能力也是容易翻车的地方。第三控制流简化。对于插入的永假分支和冗余跳转它用简单的可达性分析做剪枝。注意它不做完整的符号执行所以遇到复杂的控制流平坦化比如 switch-case 状态机效果有限。第四去除无效的 try-catch 和合成方法。混淆器经常生成access$000这类合成方法flaming-shame 会识别并内联它们。这套链路决定了它的适用边界对 ProGuard 默认配置的混淆效果最好对商业级混淆器比如带虚拟机保护的只能恢复一部分。2.2 环境准备与基础运行flaming-shame 本身是 Java 写的运行需要 JDK 8 以上。我一般用 JDK 11兼容性比较稳。它依赖 ASM 库做字节码操作所以如果你是从源码构建Maven 里会拉org.ow2.asm:asm和asm-tree。先看构建和基础运行# 克隆源码后进入项目根目录 cd flaming-shame # 用 Maven 打包跳过测试加快速度 mvn clean package -DskipTests # 打包完成后target 目录下会有可执行的 jar # 基础用法指定输入 jar 和输出目录 java -jar target/flaming-shame-*.jar \ --input ./obfuscated-app.jar \ --output ./deobfuscated-app \ --mode full这里--mode有三个可选值rename只做标识符恢复string只做字符串还原full全量处理。我建议第一次跑先用string模式因为字符串还原的副作用最小万一出问题也好定位。参数说明--input支持 jar 和单个 class 文件--output如果是目录会保持原有的包结构输出如果指定.jar后缀会直接打包成新 jar。还有一个--threads参数控制并发线程数默认是 CPU 核心数处理大包时可以调到 8 或 16但注意内存占用会上去。2.3 字符串还原的配置细节字符串还原是 flaming-shame 最实用的功能但它的配置项需要根据目标混淆器调整。默认配置针对的是“静态字段 clinit解密”的模式。如果你的目标 jar 用的是“方法内联解密”每次调用字符串时现场解密需要改配置。配置文件在conf/deobfuscate.yaml关键项如下string: # 解密入口static_field 表示从静态字段读取inline 表示方法内联 decrypt_mode: static_field # 最大模拟执行指令数防止死循环 max_instructions: 5000 # 是否保留原始加密字符串作为注释 keep_original: true # 遇到无法解析的字符串时的策略skip 跳过abort 终止 on_failure: skipmax_instructions这个参数很关键。有些混淆器会在clinit里放一个巨大的循环来消耗分析时间设太小会漏掉解密逻辑设太大又可能卡死。我一般从 5000 开始试如果日志里出现decrypt timeout再往上调到 20000。keep_original: true建议打开这样反编译后能看到原始加密串和还原后的明文对照方便验证还原是否正确。3. 反编译配合与结果验证怎么确认还原到位了3.1 用 CFR 或 Procyon 做反编译flaming-shame 输出的是 class 文件要变成可读的 Java 源码还得配一个反编译器。我常用 CFR它对 Java 8 之后的语法支持比较好而且命令行简单。# 下载 CFR这里假设已经放在 tools 目录下 # 对 flaming-shame 输出的目录做反编译 java -jar tools/cfr.jar ./deobfuscated-app \ --outputdir ./decompiled-src \ --comments false # 如果输出是 jar直接反编译 jar java -jar tools/cfr.jar ./deobfuscated-app.jar \ --outputdir ./decompiled-src--comments false是为了去掉 CFR 自己加的注释避免和 flaming-shame 保留的原始字符串注释混在一起。反编译完成后重点看几个地方类名和方法名是否可读、字符串常量是否还原、控制流是否还有明显的while(true)加switch结构。3.2 验证还原效果的三个检查点第一个检查点字符串常量。在反编译源码里搜\u或者new String(new char[]{如果还有大量这种形式说明字符串还原没覆盖到。这时候要回去看decrypt_mode是不是设错了。第二个检查点方法调用链。找一个入口方法比如main或者 Controller 的doPost顺着调用往下跟三层。如果中间出现a.a(b.c(d))这种完全无法理解的调用说明标识符恢复没生效。检查--mode是不是只跑了string。第三个检查点异常表。混淆器经常把正常的业务逻辑包在try-catch(Throwable)里反混淆后如果这些异常块还在说明控制流简化没做干净。flaming-shame 对异常表的处理比较保守遇到嵌套 try-catch 会跳过这是已知限制。3.3 一个完整的处理流程示例假设手里有一个legacy-service.jar先用string模式跑一遍java -jar flaming-shame.jar \ --input legacy-service.jar \ --output legacy-service-string \ --mode string \ --threads 4跑完后看日志如果有[WARN] decrypt failed for field: xxx记下这些字段名。然后换full模式再跑一遍对比两次输出的差异。如果full模式下某些类反编译报错很可能是标识符重命名时和 Java 关键字冲突了比如把方法名改成了class这时候需要在配置里加rename.reserved_words列表。4. 避坑指南反混淆过程中最容易翻车的五个点4.1 现象跑完 flaming-shame 后反编译报VerifyError原因字节码重写时栈帧StackMapTable没有同步更新。Java 7 以后 class 文件要求栈帧信息ASM 在修改指令后如果没调用COMPUTE_FRAMES就会导致验证失败。解决在配置里确认bytecode.recompute_frames: true。如果已经开了还报错大概率是目标 class 用了JSR/RET指令Java 6 之前的 finally 实现ASM 的COMPUTE_FRAMES不支持这种老指令。这时候只能对单个类降级处理用--mode rename跳过控制流修改。4.2 现象字符串还原后出现乱码原因原始字符串是 UTF-8 编码但解密逻辑按 ISO-8859-1 读取。混淆器在加密时可能做了编码转换而 flaming-shame 默认按平台编码处理。解决在deobfuscate.yaml里显式指定string.charset: UTF-8。如果还是乱码试试GBK。我遇到过一个小众混淆器用的是UTF-16LE这种只能手动在配置里加charset: UTF-16LE。4.3 现象处理大 jar 时 OOM原因flaming-shame 默认把整个 jar 的所有 class 加载到内存做交叉分析一个 200MB 的 fat jar 很容易撑爆默认堆。解决启动时加 JVM 参数-Xmx4g同时把--threads降到 2。如果还是不够用--batch-size 500分批处理每 500 个 class 输出一次中间结果。注意分批模式下跨批次的调用关系分析会丢失标识符恢复质量会下降。4.4 现象某些类被跳过日志显示unsupported constant pool entry原因目标 class 用了 Java 11 之后的CONSTANT_Dynamic或者CONSTANT_Module常量池项而 flaming-shame 依赖的 ASM 版本太老不认识这些项。解决升级 ASM 到 9.0 以上。如果是 Maven 项目在pom.xml里把asm版本改成9.4。改完后重新打包再跑一遍。如果还是不行说明这个类用了更冷门的特性只能单独用javap -v手工分析。4.5 现象反混淆后的代码逻辑和预期不一致原因控制流简化时误删了有副作用的指令。flaming-shame 的可达性分析只考虑跳转指令不考虑方法调用的副作用。如果混淆器把关键逻辑藏在一个“看起来不可达”的分支里剪枝时就会丢掉。解决把--mode改成rename只做标识符恢复不动控制流。然后人工阅读反编译源码手动判断哪些分支是混淆器加的。这是最保险的做法代价是工作量大。我一般对核心业务类用这个策略对工具类用full模式。5. 进阶技巧用脚本批量处理多个 jar 并做差异对比5.1 批量处理脚本实际项目里往往有多个模块 jar一个个跑太慢。我写了一个 bash 脚本做批量处理同时记录每个 jar 的处理耗时和警告数#!/bin/bash # batch-deobfuscate.sh # 用法./batch-deobfuscate.sh ./input-jars ./output-dir INPUT_DIR$1 OUTPUT_DIR$2 TOOL_JARflaming-shame.jar LOG_FILEdeobfuscate-batch.log mkdir -p $OUTPUT_DIR $LOG_FILE for jar in $INPUT_DIR/*.jar; do name$(basename $jar .jar) echo [$(date %H:%M:%S)] Processing: $name | tee -a $LOG_FILE # 记录开始时间 start$(date %s) java -Xmx4g -jar $TOOL_JAR \ --input $jar \ --output $OUTPUT_DIR/$name \ --mode full \ --threads 4 21 | tee -a $LOG_FILE end$(date %s) echo [$(date %H:%M:%S)] Done: $name, elapsed: $((end-start))s | tee -a $LOG_FILE echo --- $LOG_FILE done # 统计警告数 echo Total warnings: $(grep -c WARN $LOG_FILE)这个脚本的关键点是-Xmx4g和--threads 4的搭配。内存给够但线程别开太多否则 GC 压力大反而慢。日志里WARN的数量能反映处理质量如果某个 jar 的警告数突然飙升说明它用了不常见的混淆策略需要单独分析。5.2 用 diff 对比反混淆前后的字符串常量验证字符串还原效果最直接的办法是把原始 jar 和反混淆后的 jar 都反编译然后 diff 字符串常量。我一般用grep提取所有双引号字符串排序后对比# 提取原始 jar 反编译后的字符串 grep -rhoP [^]* ./decompiled-original | sort -u original-strings.txt # 提取反混淆后的字符串 grep -rhoP [^]* ./decompiled-deobfuscated | sort -u deobfuscated-strings.txt # 对比只在原始中出现的是加密串只在反混淆后出现的是还原出的明文 comm -23 original-strings.txt deobfuscated-strings.txt only-in-original.txt comm -13 original-strings.txt deobfuscated-strings.txt only-in-deobfuscated.txt # 查看还原出的明文数量 wc -l only-in-deobfuscated.txt如果only-in-deobfuscated.txt里有大量可读的 URL、SQL 语句、错误提示说明字符串还原成功了。如果这个文件几乎是空的说明decrypt_mode配错了或者目标混淆器用了非标准加密。5.3 一个容易忽略的细节内部类命名Java 混淆器经常把内部类重命名为a$b、a$c这种形式。flaming-shame 在恢复标识符时对内部类的处理依赖外部类的名称恢复结果。如果外部类名没恢复好内部类名也会跟着乱。我的做法是先用--mode rename单独跑一遍确认外部类名恢复到位后再用full模式跑第二遍。两遍之间清空输出目录避免残留文件干扰。从那以后我每次处理新的混淆 jar都强制先跑一遍string模式看日志再跑rename模式验证标识符最后才上full模式。这个顺序能帮我快速定位问题出在哪个环节而不是一上来就全量处理然后对着报错发呆。希望帮到你。本文还有配套的精品资源点击获取
