成品 APK 的混淆加固：一次完整对比

发布 APK 时，真正交付出去的不只是安装包，也是其中的代码、资源和文件结构。DEX 保留的符号信息越多，静态分析的起点就越低。

反编译一份未加固 APK

将 APK 直接拖进 jadx-gui：

包名层级、类名、方法名和字符串常量仍然存在。进一步沿调用链，可以分析接口地址与请求参数、本地加密和校验算法、授权校验及风控分支。

res 目录中的布局 XML、图片素材，以及 assets 中的 H5 和 JS，同样可能暴露。由此带来的二次打包、资源复用和广告 SDK 植入风险，往往不是代码本身损失这么简单。

加固前后的结果

对同一个 APK 做完整处理：DEX 加壳、字符串加密、指令乱序、类/方法/域重命名、资源名称混淆，以及 Assets/JS 加密。

再次使用相同工具时，通常可以看到：

• DEX 解析失败，或只能进入壳入口
• 类名、方法名失去语义，指令顺序改变并出现垃圾分支
• URL、密钥和接口参数不再明文保留，而在运行时解密
• res 目录、文件名和 ARSC 被处理，难以通过资源名还原业务

如果再启用防调试、防重签名、包名防修改、ROOT 检测和 VPN 检测，包被修改、被附加调试器，或运行于 ROOT / 系统代理环境时可触发闪退。

这些措施的定位是提高逆向门槛，并不能把 APK 变成绝对不可破解的对象。

处理能力与工程细节

处理对象为打包完成的 APK，不涉及源码工程和 Gradle 构建脚本。本文使用：安卓APK资源混淆加密重签名工具

具体能力包括：

• DEX 代码层：DEX 加壳与魔改、字符串加密、指令乱序、垃圾指令/分支注入、调用隐藏、DEX 拆分、类/方法/域重命名
• 资源层：资源名称混淆（含增强模式）、图片/XML/文本资源混淆、ARSC 魔改、资源防解压、Assets 加密、JS 混淆加密
• 文件结构层：APK 文件魔改、伪加密、垃圾注解、文件时间混淆、APK 文件高级保护
• 运行时层：反调试、防重签名、包名防修改、ROOT 检测、VPN 检测，以及日志与无用代码清理

忽略列表用于跳过推送、支付、统计等第三方 SDK；随机种子保证相同输入产出一致结果；诊断日志用于失败定位。程序为 64 位，支持 2G 以上的大型 APK。每项选项说明见这个文档

签名阶段支持内置独立证书和自定义 keystore，处理后自动重签名。

操作与排查

1. 选择单个 APK，或通过「批量打开文件夹」导入多个包。
2. 保持默认组合，必要时启用 DEX 加壳、DEX 魔改、字符串加密、资源名称混淆、So 文件加密、防调试等。
3. 选择保存位置，等待混淆、加固和重签名完成。

DEX 加壳、APK 文件魔改、APK 伪加密，可能使部分国外小众杀毒软件报壳或误报。

运行异常时，先关闭类重命名、DEX 加壳、DEX 魔改等侵入性选项，再将第三方 SDK 包名加入忽略列表。

总结

未加固 APK 的工程信息暴露程度很高。对成品 APK 做混淆加固，可以在无需修改源码、无需配置 Android SDK 或 JDK 环境的前提下，增加静态逆向和二次打包的成本。