移动加固推荐方案

1. 支持现状

移动端的产物形态、签名机制与运行时差异很大，先确认你面对的是哪一类：

具体支持范围以当前客户端版本和授权类型为准。iOS 的交付方式与 Android 不同，落地前请与技术支持确认。

2. 移动端威胁模型

移动应用面临的主要风险：

• 反编译与二次打包：拆包、修改 Dex 字节码、重签名分发。
• 动态调试与注入：Frida、Xposed、Magisk 模块、调试器附加。
• 运行时篡改：修改内存、Hook 关键函数、替换资源。
• 环境风险：Root / 越狱、模拟器、多开、云手机。
• 协议与密钥泄露：硬编码密钥、明文接口签名。

加固只能提高成本，不能替代服务端校验。授权、支付、风控的最终判断必须放在服务端。

3. 分层加固模型

4. 推荐发布流程

Release 构建
   ↓
原始包自测（真机）
   ↓
加固 / 混淆 / 保护
   ↓
重签名（原证书）
   ↓
真机回归 + 兼容性测试
   ↓
内测分发 / 灰度
   ↓
应用商店发布

关键点：

1. 先自测再加固。原始包必须能正常安装、启动和跑通核心流程。
2. 加固后必须重签名。证书、签名方案（APK v2 / v3、IPA 重签名）要与发布渠道一致。
3. 多 ABI 覆盖。arm64-v8a 必测，armeabi-v7a、x86_64 按发布范围覆盖。
4. 保留 mapping / 符号。崩溃分析需要原始符号，按版本归档。
5. 分渠道验证。应用商店、企业分发、内测平台的签名和审核要求不同。

5. 合规与商店审核

• 隐私政策需要说明收集的设备信息与用途，Root / 越狱检测、设备指纹属于敏感能力。
• 不要用加固隐藏违规内容、规避审核或动态下发违规代码。
• Google Play 对动态代码加载、权限和隐私有明确限制；AAB 是推荐上传格式。
• App Store 对动态代码、热更新和加密有审核要求；加固方案不能改变审核可见的功能。

6. 选型速查

7. 子文档

• Android 应用加固推荐方案（APK / AAB）
• iOS 加固推荐方案

8. 相关文档

• Native 加固推荐方案
• .NET 加固推荐方案
• GUI 完整使用文档