御盾 APP加固

先回答：APP加固到底应该交付什么

一个可用的 APP加固项目不应只交付“已加固包”。团队至少需要知道：本次候选包从哪个原始版本生成；哪些关键模块进入了保护范围；哪些系统、设备、业务路径和第三方依赖已验证；运行时异常会产生什么证据；服务端如何处置；未覆盖项是什么；一旦出现性能、兼容或发布问题，能回到哪个候选版本。

因此，御盾把代码与资源保护、运行时风险观察、完整性与二次打包治理、兼容性验证、发布门禁和服务端证据作为可组合能力。不同业务不必使用同一策略：高价值授权、协议、结算、风控或算法可获得更严格的保护与回归；普通界面和低风险逻辑则应控制性能和维护成本。

四层能力与四条边界

Android 与 iOS 应该分别验证什么

Android 的重点通常包括 APK/AAB、DEX 与 Native 模块、ABI、系统版本、渠道差异、签名、动态加载和目标 API 兼容。涉及 Native 库时，还应关注页面大小、第三方 SDK 与安装启动路径。iOS 的重点通常包括 IPA、Mach-O、Bundle ID、签名身份、entitlements、运行时注入风险、越狱环境、系统兼容和 App Store 或其他分发路径。

双端项目可以统一使用同一份候选包身份表和发布门禁框架，但不应假设两端的保护策略完全相同。每端都有自己的二进制格式、签名规则、系统约束和测试矩阵。采购或 PoC 阶段应分别写清覆盖范围，而不是把“支持双端”误读为“任何包、任何系统、任何业务路径都会自动通过”。

从候选包到上线：建议使用七步门禁

第一步，冻结原始候选包并记录版本、摘要和构建身份。第二步，按业务价值选择保护策略，明确哪些模块使用何种保护。第三步，生成加固候选包并记录策略版本。第四步，确认签名、渠道、配置和分发身份。第五步，对原始包与候选包执行安装、启动、升级和关键路径对照。第六步，核对性能、Crash、ANR、内存、包体和系统兼容范围。第七步，记录未覆盖项、批准例外和回滚对象，再决定灰度或正式发布。

这七步不会替代团队已有 CI/CD、测试平台或商店审核流程；它的作用是把安全保护纳入已有交付流程，让每次发布都能追溯“什么版本、什么策略、验证到什么范围、为什么允许上线”。需要自动化时，关键是保证候选包、策略版本和验证结果一一对应，而不是只把加固接口放进流水线。

攻防视角：提高成本，但不伪造绝对结论

客户端始终运行在用户可控制的环境中，不能被当作业务的唯一信任根。代码保护、环境检测、完整性校验和运行时观察可以提高分析、篡改和批量复用的成本，也可以为服务端积累风险证据；但对登录、支付、授权、内容解锁和高价值接口，最终允许、挑战、延迟、人工复核或拒绝应由服务端依据账户、会话、设备、业务行为和风险规则决定。

同样，任何公开页面都不应把一次有限的测试说成所有环境下的永久结论。系统版本、机型、第三方依赖、商店规则和业务路径都会变化。可靠交付应包括测试日期、对象、覆盖范围、通过标准、未覆盖项和复测计划，而不是“绝对防破解”一类无法验证的表述。

公开依据与适用边界

以下资料用于核验移动应用签名、完整性、平台能力与测试方法边界。它们不构成对某个具体应用已通过测试的证明，实际项目仍需以候选包和业务路径的验证结果为准。

下一步：按项目范围做 APP加固评估

如果团队已经有候选包、明确的平台、核心业务路径、兼容性担忧或发布节点，可以先提交项目范围。评估应先确认目标平台、业务价值、保护范围、测试矩阵、服务端联动和回滚边界，再决定适合的交付方式。