Android APK 加固：反编译对比与处理流程
从一个 jadx 结果开始
安卓 DEX 格式会保留类名、方法名、字符串常量等符号信息。它们在开发阶段可能不起眼，但对静态分析非常关键：一个未加固 APK 的可读性，往往高于预期。
一、未加固 APK 暴露了哪些内容
将 APK 直接拖入 jadx-gui：
包名层级、类名、方法名和字符串常量通常完整保留。顺着调用链分析，可以还原接口地址与请求参数拼接规则、本地加密和校验算法、授权校验及风控策略分支。
代码之外，res 中的布局 XML、图片素材，以及 assets 中的 H5 和 JS 也可能被分析。换句话说，APK 在工程信息层面接近公开，二次打包、资源搬运和植入广告 SDK 的门槛会降低。
二、同一 APK 的加固结果
对同一个 APK 执行 DEX 加壳、字符串加密、指令乱序、类/方法/域重命名、资源名称混淆，以及 Assets/JS 加密，再使用同样的工具打开：
可以从四个角度观察差异：
- 静态解析受阻：DEX 加壳与魔改可能导致解析失败，或者只能看到壳入口
- 代码可读性下降：名称被替换，指令顺序被打乱，并加入不可达垃圾分支
- 敏感信息隐藏：URL、密钥和接口参数进入运行时解密流程
- 资源关联减弱：资源目录、文件名和 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
选择单个 APK，或使用「批量打开文件夹」一次导入多个包。
2. 选择策略
默认组合通常兼容性最高。需要提高强度时，可以启用 DEX 加壳、DEX 魔改、字符串加密、资源名称混淆、So 文件加密、防调试等选项。
3. 输出并验证
指定保存位置，等待混淆、加固与重签名完成。
注意：DEX 加壳、APK 文件魔改、APK 伪加密，可能导致部分国外小众杀毒软件报壳或误报。
如果处理后的 APK 运行异常，建议先关闭类重命名、DEX 加壳、DEX 魔改等侵入性较强的选项，再将第三方 SDK 包名加入忽略列表。
结语
通过 jadx 可以直观看到未加固 APK 的信息暴露程度。发布前对成品 APK 做一轮混淆加固，无需修改源码，也无需配置 Android SDK 或 JDK 环境，是一项适合纳入交付流程的基础防护措施。