从 jadx 反编译看 Android APK 加固

问题从一个反编译结果开始

安卓 DEX 会保留类名、方法名和字符串常量。开发阶段不容易注意到这一点，但把成品 APK 放进 jadx-gui 后，问题就十分直观了：未加固 APK 的可读性可能远高于预期。

未加固状态：工程信息几乎裸露

将 APK 拖入 jadx-gui：

包名、类名、方法名和字符串常量通常可以直接看到。沿调用链继续追踪，还能还原接口地址和请求参数拼接规则、本地加密与校验算法、授权校验和风控分支。

另外，res 下的布局 XML、图片素材，以及 assets 中的 H5 与 JS，也可能成为分析对象。对二次打包、资源搬运和广告 SDK 植入而言，这会显著降低门槛。

加固之后：静态分析被分层阻断

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

变化主要集中在以下方面：

• DEX 加壳与魔改可能让工具解析失败，只留下壳入口

• 名称被替换，指令顺序被打乱，并混入不可达垃圾分支

• URL、密钥、接口参数改为运行时解密，静态搜索难以命中

• res 目录、文件名和 ARSC 被处理，资源名称不再容易表达业务含义

配合防调试、防重签名、包名防修改、ROOT 检测和 VPN 检测，可以在包被修改、附加调试器或处于 ROOT / 系统代理环境时触发闪退。

但边界仍然要明确：加固的价值在于提高成本，不是承诺绝对不可破解。

工具处理范围

处理对象是成品 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 包名加入忽略列表。

结语

jadx 让未加固 APK 的信息暴露一目了然。发布前直接处理成品 APK，不改源码、不配置 Android SDK 或 JDK 环境，也能增加逆向分析的工作量。