这是一个创建于 155 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 文件无法被任何工具反编译）
6 条回复 • 2024-07-31 21:08:35 +08:00
 |
1
medivh 155 天前
提个建议吧，这种混淆力度太小了，反编译之后一眼就能看出这个方法是做什么的。 是否考虑增加“控制流”混淆？把 if else for where 等改成 goto ？
|
 |
2
4ra1n OP 嗯，控制流混淆会麻烦一些，我之后研究下怎么做
|
 |
3
eleganceoo 155 天前
支持
|
 |
4
ninjaJ 155 天前
混淆只能提高反编译阅读的成本，并不能完全断绝，这是一个前提。
实际上大部分混淆工作做到 OP 这一步就已经足够了，大部分有心反编译的人看到这一堆东西就会望而却步了。如果需要让安全更上一层，一般的做法是定制虚拟机，在虚拟机内存中再做 goto 。 |
|
5
4ra1n OP 嗯，我最后支持的一种 JVMTI 字节码加密是这样的，提供一个 NATIVE 库，启动时候输入密码，进行解密
|
 |
6
96368a 120 天前
大佬，你害苦我了，
hvv 一天被人打穿了 3 次，传的马全是用你这个工具混淆过的，我都认不出来是不是马子了😭， （开个玩笑，无恶意，其实被穿的是群友🤣 |
Select Language