分享下花了一段时间开发的 Java 字节码混淆加密工具

[4ra1n]

https://github.com/jar-analyzer/jar-obfuscator

Jar Obfuscator 是一个 JAR/CLASS 文件混淆工具

• 命令行模式，简单易用
• 仅单个 JAR 文件小于 1 MB 超轻量
• 简洁的配置文件快速上手
• 输入 JAR 直接输出混淆后的 JAR

支持的混淆内容

• 类名混淆（包含引用修改）
• 包名混淆（包含引用修改）
• 方法名混淆（包含引用修改）
• 字段名混淆（包含引用修改）
• 方法内参数名混淆（包含引用修改）
• 删除编译调试信息（删除行号信息）
• 字符串加密运行时解密（使用 AES 加密）
• 字符串提取数组混淆（访问数组方式得到字符串）
• 整型常数异或混淆（多重异或的加密）
• 垃圾代码花指令混淆（可指定多级别的混淆）
• 使用某些技巧可以在反编译时隐藏方法
• 使用某些技巧可以在反编译时隐藏字段
• 安全的随机（支持通过 CPU 指令获得随机数）
• 基于 JVMTI 的字节码加密（ beta ）

一些混淆后的例子

在混淆之外，提供了一种字节码加密的功能，在 JVM 启动时通过 -agentpath:decrypter.dll 参数指定解密密钥等信息，动态解密字节码运行（如果仅拿到 jar/class 文件无法被任何工具反编译）

[medivh]

提个建议吧，这种混淆力度太小了，反编译之后一眼就能看出这个方法是做什么的。 是否考虑增加“控制流”混淆？把 if else for where 等改成 goto ？

[4ra1n]

嗯，控制流混淆会麻烦一些，我之后研究下怎么做

[eleganceoo]

支持

[ninjaJ]

混淆只能提高反编译阅读的成本，并不能完全断绝，这是一个前提。
实际上大部分混淆工作做到 OP 这一步就已经足够了，大部分有心反编译的人看到这一堆东西就会望而却步了。如果需要让安全更上一层，一般的做法是定制虚拟机，在虚拟机内存中再做 goto 。

[4ra1n]

嗯，我最后支持的一种 JVMTI 字节码加密是这样的，提供一个 NATIVE 库，启动时候输入密码，进行解密

[96368a]

大佬，你害苦我了，
hvv 一天被人打穿了 3 次，传的马全是用你这个工具混淆过的，我都认不出来是不是马子了😭，

（开个玩笑，无恶意，其实被穿的是群友🤣