Android APK加固方案
Android APK 加固方案
APK 加固不是把 APK 变成“不可破解”。它的目标只有一个：提高反编译、篡改、重打包、Hook、接口滥用的成本。
一句话：客户端负责增加攻击成本，服务端负责最终可信判断。
1. 加固要防什么
| 风险 | 常见手段 | 加固目标 |
|---|---|---|
| 反编译 | jadx、apktool 查看 Dex 和资源 | 降低代码可读性 |
| 二次打包 | 改代码、插广告、换签名 | 发现篡改，阻断关键逻辑 |
| 动态调试 | Android Studio、IDA、Frida、Xposed | 增加调试和 Hook 成本 |
| 接口滥用 | 模拟请求、刷接口、绕过客户端校验 | 服务端识别风险请求 |
| 本地数据泄露 | 读取数据库、SP、文件 | 减少敏感数据落地 |
加固不能替代服务端安全。核心密钥、金额、权益、风控结论放在 APK 里，再强的加固也只是延迟被拿到。
2. 总体分层方案
2.1 构建层：Release 包先做好
所有正式包都应该做这部分，不依赖第三方工具。
| 措施 | 建议 |
|---|---|
| R8 混淆 | 开启代码压缩、优化、混淆 |
| 资源压缩 | 删除无用资源，减少可分析信息 |
| 关闭调试 | Release 禁止 debuggable=true |
| 去日志 | 删除 Token、接口返回、用户信息等敏感日志 |
| 正式签名 | 使用正式 keystore，启用 v2/v3 签名 |
| 网络安全 | 禁用明文 HTTP，必要时做证书锁定 |
R8 是 Android 官方构建链路里的代码压缩、优化和混淆工具。它是 APK 加固前的基础动作，不应该被第三方加固替代。
2.2 包体层：第三方加固重点处理这里
| 能力 | 作用 | 注意点 |
|---|---|---|
| Dex 加密 | 避免 classes.dex 被直接静态阅读 | 可能影响启动速度 |
| 字符串加密 | 隐藏 URL、类名、配置字段 | 不要把真正密钥放客户端 |
| so 加固 | 保护 native 层逻辑 | 注意 ABI 和机型兼容 |
| 资源混淆 | 降低资源可读性 | 小心影响资源反射读取 |
| 完整性校验 | 检测 APK 是否被改包 | 校验逻辑也可能被逆向 |
| 签名校验 | 检查当前 APK 是否官方签名 | 不能只靠客户端判断 |
| 反调试/反 Hook | 增加 Frida、Xposed 调试成本 | 容易误伤，必须灰度 |
适合重点加固的模块：
- 支付、会员、优惠券、积分、提现逻辑。
- License 校验、设备绑定、反作弊逻辑。
- 自研算法、协议封装、核心 SDK。
- 不适合完全放服务端、但又不希望裸露的代码。
不建议重度加固的模块：
- 普通 UI 页面。
- 冷启动关键链路里的非敏感代码。
- 强依赖反射、热修复、插件化的模块。
- 对兼容性要求极高的基础模块。
3. 第三方加固方案
第三方加固适合大多数商业 App。优点是接入快，能力全；缺点是黑盒多，兼容性和合规要自己验。
3.1 常见厂商
| 厂商/方案 | 适合场景 | 常见能力 | 注意点 |
|---|---|---|---|
| 360 加固保 | 个人、中小团队、企业项目 | 在线加固、本地部署、代码保护、漏洞扫描等 | 免费能力适合入门，高级能力看收费和兼容性 |
| 梆梆安全 | 金融、电商、政企、强安全业务 | 防反编译、防调试、防篡改、防二次打包 | 策略较重时要重点测启动耗时和 ROM 兼容 |
| 爱加密 | 常规商业 App，快速接入 | 防反编译、防二次打包、防代码注入 | 配置项多，先小流量验证 |
| 阿里云 mPaaS MSA | 已使用阿里云/mPaaS 的企业项目 | 支持 APK/AAB 上传，可选择类、so、assets 防护 | 注意计费、包名绑定、平台依赖 |
| 腾讯云移动应用安全/乐固 | 应用宝、腾讯云生态项目 | 在线加固、本地工具、命令行工具等 | 需要确认当前控制台入口、服务状态和重签名流程 |
3.2 推荐选型
| 项目类型 | 推荐方案 |
|---|---|
| 普通工具类、内容类 App | R8 + 基础在线加固 + 签名校验 |
| 有登录、会员、优惠券、支付 | R8 + 商业加固 + 完整性校验 + 服务端风控 |
| 金融、游戏、反作弊 | 企业版/私有化加固 + so 加固 + 反 Hook + 服务端风险决策 |
| 公司代码不能上传外部平台 | 本地工具或私有化部署，不走云端 SaaS |
| Google Play / AAB 发布 | 先确认厂商是否支持 AAB；不支持时不要强行套 APK 加固流程 |
3.3 第三方加固接入流程
推荐顺序：
- Gradle 构建 Release 原始包。
- 开启 R8 混淆和资源压缩。
- 上传加固平台，或在 CI 中调用本地/命令行加固工具。
- 下载或产出加固后的 APK。
- 执行
zipalign。 - 使用正式 keystore 执行
apksigner签名。 - 执行
apksigner verify验签。 - 真机安装测试。
- 核心链路回归。
- 小流量灰度发布。
关键规则：最终签名之后，不要再改 APK。
如果加固、渠道写入、二次压缩、资源替换发生在签名之后，很容易导致签名失效。
4. 运行时安全
运行时检测主要用于发现异常环境，不要直接当作封号依据。
| 检测项 | 目的 |
|---|---|
| 反调试 | 识别调试器附加 |
| 反 Hook | 识别 Frida、Xposed、LSPosed 等注入环境 |
| Root 检测 | 判断设备是否存在高风险改动 |
| 模拟器检测 | 识别批量运行、自动化脚本环境 |
| 多开/虚拟 App 检测 | 识别沙箱、分身、重打包运行环境 |
| so 完整性检测 | 检查 native 库是否被替换 |
处理策略：
| 风险等级 | 建议处理 |
|---|---|
| 低风险 | 记录埋点，降低信任分 |
| 中风险 | 限制提现、领券、改密等敏感功能 |
| 高风险 | 要求二次验证，必要时阻断交易 |
| 明确攻击 | 阻断请求，服务端拉黑设备或账号 |
不要一检测到 Root 就闪退。Root、模拟器、Hook 检测都可能误伤正常用户。
5. 服务端安全
客户端能被逆向，也能被修改。真正的安全边界必须在服务端。
| 能力 | 说明 |
|---|---|
| Play Integrity API | 判断请求是否来自真实设备、正版应用和可信安装来源 |
| 请求签名 | 参数加时间戳、nonce，防止重放 |
| 设备风险分 | 结合 Root、Hook、模拟器、IP、账号行为判断风险 |
| 权益服务端计算 | 金额、优惠券、积分、会员状态不要由客户端决定 |
| 灰度风控 | 高风险设备先限权、观察、降级，不要一刀切 |
Play Integrity API 不是本地防破解工具。它更适合让服务端判断请求来源是否可信。
6. 发布流水线
推荐流程：
- Release 构建。
- R8 混淆、优化、压缩。
- 第三方加固或自研加固。
- zipalign 对齐 APK。
- apksigner 正式签名。
- apksigner verify 验签。
- 真机安装测试。
- 核心链路回归。
- 小流量灰度。
- 上传应用市场。
7. 分级落地方案
7.1 普通应用
适合：工具类、资讯类、内容类 App。
建议：
- R8 混淆和资源压缩。
- Release 关闭调试和敏感日志。
- 禁止明文 HTTP。
- 关键接口加请求签名。
- 可接入基础在线加固。
不建议：
- 上来就做重型 Dex 加壳。
- 大量反调试导致兼容性问题。
- 把所有异常环境都直接闪退。
7.2 电商 / 会员 / 支付应用
建议：
- R8 混淆。
- 关键模块 Dex 加固。
- 签名校验和完整性校验。
- Hook、Root、模拟器检测。
- 服务端请求签名、nonce、防重放。
- 优惠、金额、权益全部由服务端计算。
- 风险设备限制领券、提现、改密等敏感操作。
核心原则：客户端只展示结果，不决定结果。
7.3 金融 / 游戏 / 反作弊应用
建议：
- Java/Kotlin 层强混淆。
- 核心逻辑迁移到 native 层。
- native 符号剥离和 so 加固。
- 运行时反调试、反注入、反 Hook。
- Play Integrity API 或同类设备完整性校验。
- 服务端设备指纹、行为风控、异常请求限流。
- 高风险动作强制二次验证。
不要把反作弊完全放客户端。客户端检测适合做信号采集，最终处罚必须由服务端综合判断。
8. 验收标准
| 检查项 | 验收方式 |
|---|---|
| 签名有效 | apksigner verify 通过 |
| 可安装 | Android 主要版本真机安装成功 |
| 可启动 | 冷启动、热启动无明显异常 |
| 核心流程 | 登录、支付、分享、推送、WebView、扫码正常 |
| 兼容性 | 主流 ROM、Root/非 Root、32/64 位设备测试 |
| 崩溃率 | 加固前后 crash-free 指标无明显劣化 |
| 性能 | 启动耗时、包体积、内存占用可接受 |
| 逆向难度 | jadx、apktool、Frida 基础验证 |
| 灰度监控 | 分渠道、分版本监控异常 |
9. 常见坑
9.1 加固后签名顺序错了
错误流程：先签名，再加固，然后直接上传。
正确流程：构建 Release 包，再加固，再 zipalign，再正式签名，最后验签和安装测试。
9.2 混淆规则写得太粗
大量 -keep class ** { *; } 会让 R8 基本失效。
建议只 keep 反射、序列化、JNI、路由框架必须保留的类。第三方 SDK 使用官方 keep 规则。
9.3 把密钥藏在 APK 里
字符串加密只能增加提取成本，不能保证密钥安全。
不建议放客户端：
- 服务端私钥。
- 支付密钥。
- 全局 AES 密钥。
- 长期有效后台 Token。
- 可直接调用核心服务的固定凭证。
9.4 加固影响反射和热修复
重点回归这些模块：
- Gson、Moshi、kotlinx.serialization。
- ARouter、DRouter、TheRouter。
- WebView JSBridge。
- 热修复、插件化、动态加载。
- JNI 方法映射。
9.5 云端加固的合规问题
如果公司代码、算法、业务包不能上传外部平台，就不要使用云端 SaaS 加固。
可选方案：
- 本地加固工具。
- 企业版离线加固。
- 私有化部署。
- 自研轻量加固能力。
10. 最终建议
推荐组合：
| 场景 | 建议组合 |
|---|---|
| 所有正式包 | R8 + 资源压缩 + 正式签名 + 关闭调试 + 禁止敏感日志 |
| 有登录和交易 | 请求签名 + Token 短有效期 + 服务端风控 |
| 有权益和支付 | 第三方加固 + 签名校验 + 完整性校验 + Hook 检测 |
| 强安全业务 | native 化核心逻辑 + so 加固 + Play Integrity + 服务端风险决策 |
最终结论：
APK 加固不是安全体系的终点，而是发布阶段的一层防护。
可靠方案应该是：
- 构建期混淆。
- 第三方或自研包体加固。
- 运行时检测。
- 服务端校验。
- 风控灰度处理。
- 持续监控和版本迭代。
只做加固，不做服务端安全，本质上还是裸奔。
参考资料
- Android Developers：Improve your app’s security
https://developer.android.com/privacy-and-security/security-best-practices - Android Developers：Enable app optimization with R8
https://developer.android.com/topic/performance/app-optimization/enable-app-optimization - Android Developers：Play Integrity API
https://developer.android.com/google/play/integrity - Android Developers：Network Security Configuration
https://developer.android.com/privacy-and-security/security-config - Android Developers：Android Keystore system
https://developer.android.com/privacy-and-security/keystore - Android Developers：zipalign
https://developer.android.com/tools/zipalign - Android Developers：apksigner
https://developer.android.com/tools/apksigner - OWASP MASTG：Reverse Engineering Android Apps
https://mas.owasp.org/MASTG/techniques/android/MASTG-TECH-0013/ - OWASP MASTG：Obfuscation
https://mas.owasp.org/MASTG-KNOW-0033/ - 360 加固保：移动应用加固平台
https://360.net/product-center/360-mobile-security/android - 梆梆安全：应用加固介绍
https://dev.bangcle.com/home/help?id=1 - 爱加密：Android 移动应用安全加固
https://ijiami.cn/android - 阿里云 mPaaS：移动应用安全加固
https://www.aliyun.com/product/mobilepaas/mpaas_ppm_public_cn - 阿里云帮助文档：Android 安全加固快速加固
https://help.aliyun.com/zh/document_detail/2365791.html - 腾讯云：移动应用安全 FAQ
https://cloud.tencent.com/product/ms/faqs
Android APK加固方案
https://lautung.com/archives/iEhOo0z1
评论