申请御盾 VMP 前需要准备哪些资料

先提供一个能够被唯一识别的候选包

候选包是后续配置、测试和结论的共同对象。至少需要包名或 Bundle ID、版本、构建来源、文件 SHA-256、当前签名状态、目标签名计划和计划发布渠道。如果暂时不能交付文件，也应明确项目处于架构、开发、联调还是发布准备阶段。

同名文件不代表同一产物。重新构建、重新签名、修改渠道资源或替换依赖都会产生新身份。每次变化要说明哪些验证需要重跑，不能把旧候选的通过结论直接贴到新文件。

涉及商业代码和用户数据时，应通过中央御盾平台的受控项目流程提交。公开专题站只提供方法与入口，不接收账号、安装包、证书或项目秘密。

把需要保护的代码写成业务损失

最高强度、全部保护和防破解都不是可执行需求。请列出核心算法、授权判断、协议处理、内容权益、模型或关键本地决策，并说明它被读懂、复制、修改或跳过后会造成什么损失。

同时说明这些逻辑为什么必须留在客户端。可以由服务端完成的高风险授权，应优先由服务端决定；需要离线、低时延或平台本地能力的路径，再评估客户端保护。这样才能把 VMP 留给真正需要改变执行表示的代码。

每项资产还要有负责人、调用入口、执行频率、线程、输入输出、依赖和失败回退。没有独立验收路径的资产，即使价值很高，也要先补测试条件。

技术栈清单决定兼容性测试边界

Android 项目应说明 Java、Kotlin、NDK、Gradle 和 Android Gradle Plugin 版本，minSdk、targetSdk、发布 ABI、是否使用反射、序列化、动态类加载、热修复、插件化、WebView、Native 和多进程。iOS 项目应说明 Swift、Objective-C、最低系统、扩展、动态库、运行时特性和签名能力。

Flutter、React Native、Unity、Cocos 或其他跨平台框架还要记录框架版本、桥接方式、引擎与业务 Native 库。不能只写跨平台，因为不同版本的产物结构、启动和第三方集成差异很大。

第三方登录、支付、推送、地图、音视频、统计、风控、热修复和厂商服务可能依赖反射、签名、Manifest、URL Scheme、JNI、资源或自身完整性检查。首次评估时完整列出，比发生闪退后逐个猜测更节省时间。

• 语言、构建系统和主要插件版本
• 最低与目标系统、设备和 ABI
• Native、JNI、动态加载和跨平台框架
• 多进程、WebView、热修复与插件化
• 登录、支付、推送、音视频等关键 SDK

签名、渠道和升级计划要在 PoC 前说清楚

PoC 产物使用什么签名、正式发布由谁签名、渠道资源在签名前还是签名后处理、是否使用 Play App Signing、iOS 使用哪种分发方式，这些都会影响安装、升级、完整性信号和最终文件身份。

Android 官方说明应用签名密钥用于确认更新来自同一密钥持有者。PoC 如果使用临时证书，只能验证对应环境，不能自动证明能覆盖线上版本。正式验收要在授权和安全流程允许的前提下使用与发布链一致的签名计划。

渠道处理必须固定顺序。最终签名后再修改包体会破坏签名，验收后重新构建或重签则产生新候选。回滚版本也要提前验证签名、版本号、数据迁移和覆盖升级。

在开始前定义 PoC 的成功、失败和停止条件

PoC 不是生成一个能安装的加固包。应提前确定要观察的保护范围、静态暴露面、启动、关键业务、性能预算、目标系统、ABI、第三方 SDK、安装升级和异常回退。每个项目都可以有不同权重，但不能没有定义。

成功条件要可测，例如关键输入输出一致、目标系统逐项通过、启动变化在项目预算内、异常路径安全、保护配置能够回溯。失败条件包括启动阻断、关键业务错误、不可接受性能变化、目标范围兼容失败或无法归因。

停止条件防止盲目扩大范围。若候选身份不一致、缺少基线、关键日志无法取得、签名流程未确认或测试环境与发布范围不匹配，应先补条件再继续。

project_stage: release-candidate
artifacts:
  baseline: identified
  protected_candidate: pending
assets:
  - entitlement-decision
  - protocol-core
stack:
  platform: Android
  min_os: project-defined
  abis: [arm64-v8a]
critical_journeys:
  - cold-launch
  - sign-in
  - protected-operation
acceptance:
  functional_parity: required
  performance_budget: project-defined
  compatibility_matrix: required
  rollback_rehearsal: required
boundaries:
  - no_unverified_attack_resistance_claim
  - uncovered_devices_remain_open

资料完整后，御盾评估会形成什么交付

完整输入能够支持三个连续阶段。第一阶段确认资产、技术栈和发布链，形成初始保护范围与风险清单；第二阶段生成可追溯 PoC，并在同一候选身份上执行静态和运行检查；第三阶段根据结果调整范围，完成目标矩阵、发布边界和回滚条件。

具体保护能力、平台支持、性能预算和交付周期需要根据真实项目确认。本页没有使用客户案例、通过率或通用性能数字，也不承诺没有候选包就能给出最终效果。

登录、注册、申请、价格和项目资料统一进入御盾中央平台。专题站不会建立第二套账号或申请系统。提交前可以先按本文清单整理材料，避免在项目开始后反复补候选身份和发布范围。

• 候选包、基线和发布链可追溯
• 保护资产和业务损失说清楚
• 技术栈、第三方和目标矩阵完整
• 成功、失败、未覆盖和回滚已定义
• 敏感资料只通过中央平台提交

提交包应让评估人员能够独立复现

一份可评估的资料不只是 APK 或 IPA。研发应提供基线候选、构建与签名说明、目标平台、主要技术栈、第三方 SDK、Native ABI、最低系统、关键业务入口和测试账号边界；发布团队补充渠道处理、升级来源、最终签名与回滚方式。材料之间用同一候选标识关联，文件一旦重建或重签就产生新记录，避免把旧报告套用到新产物。

关键业务说明应足够具体，让不了解源码的人也能判断结果是否正确。例如支付或授权场景需要写明入口、前置状态、正常输出、拒绝分支、网络异常和恢复动作，而不是只写测试核心功能。涉及反射、序列化、热修复、插件、WebView、JNI、动态下发或自校验的路径要主动标记，因为这些机制经常依赖名称、装载顺序、资源或异常语义。

敏感材料按最小必要原则提供。生产密钥、长期令牌、真实用户数据和完整内部拓扑不进入普通评估包；可以使用专用测试账号、脱敏配置和受控上传通道。若某个问题必须依赖生产环境才能复现，应先说明需要的观测点和授权范围，由项目负责人决定如何取证，而不是把生产凭据附在文档或聊天记录里。

依赖清单应来自实际构建，而不是过时的项目文档。Gradle、CocoaPods、Swift Package Manager、内部二进制和手工放入的 Native 库都可能改变启动、反射和签名行为；最好同时提供锁文件、最终包扫描结果和已知特殊初始化说明。无法提供源码的商业 SDK 也要记录供应商版本、支持系统、所含 ABI 和升级限制，便于把兼容风险放进 PoC 矩阵。

测试账号要覆盖权限差异和恢复路径。普通账号、付费账号、企业角色或地区策略可能触发不同模块，只提供一个能登录的账号会漏掉高价值逻辑。账号说明应列出允许操作、禁止操作、有效时间和重置办法；涉及资金或真实外部通知时使用沙箱或明确停止点，确保评估不会产生业务副作用。

• 基线候选与签名来源可独立核对
• 关键业务具有输入、输出和异常路径
• 反射、热修复、JNI 等敏感机制已标记
• 渠道加工和升级链写入发布说明
• 测试账号与生产凭据严格分离
• 任何重建或重签都建立新候选记录

在申请前回答十个会改变方案的问题

第一组问题决定保护重点：攻击者最想复制、修改或绕过的三项业务资产是什么，资产位于 Java、Kotlin、Objective-C、Swift、Native 还是服务端，失败后造成的商业损失是什么。只有把对象和损失说清楚，评估人员才能区分需要强保护的决策逻辑、只需常规混淆的胶水代码以及应该迁移到服务端的高风险授权。

第二组问题决定兼容边界：应用如何启动和恢复，哪些 SDK 在启动期初始化，是否使用反射、动态加载、热修复、插件、JNI 或自校验，最低与最高目标系统是什么，主要设备、ABI 和渠道各占什么范围。这里不要求在申请前完成全部测试，但必须如实列出未知项；隐藏复杂依赖只会让 PoC 在错误假设上开始。

第三组问题决定发布与验收：哪个文件是唯一候选，谁完成最终签名和渠道处理，成功与失败如何判断，允许的性能和包体预算是什么，出现问题时如何停止、回滚和复核。答案可以是尚未确定，但必须指定负责人和补齐时间。没有这些决策，团队即使收到一个能运行的保护包，也无法判断它是否适合商业发布。

如果同时存在 Android 和 iOS，不要把一个平台的保护对象、指标和测试结果复制到另一个平台。两边的代码形态、签名分发、运行时、第三方依赖和设备覆盖不同，应共享业务资产定义，却分别建立候选、配置和证据。这样可以保持采购与项目目标统一，又不会把 Android 的 DEX、JNI 结论误写成 iOS 已经覆盖。

评估入口还应指定日常沟通和最终批准人。技术联系人负责复现与配置，业务负责人确认关键输出，发布负责人确认签名、渠道与回滚，安全负责人确认剩余风险。任何关键角色缺席时，对应结论只能保持待确认；用一个人代替全部角色签字，会把技术通过、业务正确和允许上线混成同一个含糊判断。

时间计划应围绕候选冻结和证据补齐，而不是只写一个交付日期。需求变更、SDK 升级或签名调整会让已完成测试失效，项目要预留重新构建和回归窗口。若业务必须赶固定渠道节点，应提前缩小有证据的保护范围并声明未覆盖项，不能在最后一天临时扩大配置又省略回归。

申请资料最后由不参与编写的人走读一次。走读者应能从文件身份找到源码版本，从业务入口找到预期结果，从失败条件找到负责人和回滚动作；任何需要口头补充才能理解的关键项都应写回台账。这样的资料既减少沟通轮次，也使后续版本能够复用结构而不复用过期结论。

后续版本可以继承资产分类、测试脚本和责任分工，但不能继承候选身份与通过状态。每次发布重新记录文件、签名、依赖和保护配置，先判断变化影响哪些证据，再选择完整回归或有依据的增量回归。若无法证明某项旧证据仍适用，就把它列为未验证，而不是为了保持进度直接沿用。

• 资产、兼容和发布问题分别有负责人
• 未知项明确写出而不是默认通过
• 验收预算来自可测基线
• 最终候选和签名顺序无歧义
• 回滚在正式发布前完成演练
• 旧证据不继承新候选通过状态
• 增量回归必须说明证据仍适用的原因
• 依赖清单同时核对锁文件与最终包扫描
• 评估结论分别由技术、业务和发布角色确认