Android 设备完整性、Play Integrity 和 APP 加固应该怎样组合？
不是。设备通过某一个完整性信号，并不等于当前运行环境绝对安全。更稳妥的做法是把 Bootloader 与 Verified Boot、Play Integrity、硬件密钥证明、APP 自身完整性和运行时证据、设备与会话历史放在同一条分层链路中，最后由服务端根据业务动作做风险裁决。御盾负责客户端代码、DEX/SO、完整性和运行时保护，不修复 OEM 内核漏洞，也不把单一 Root 检测结果包装成安全结论。
摘要
2026 年 8 月底公开的 OEMpocalypse 研究再次提醒行业：在部分 OEM 设备上，研究者演示了普通 untrusted_app 到达 root 的情形，同时设备仍显示 Bootloader locked 与 Verified Boot green。Calif OEMpocalypse 研究 说明了启动链状态与运行时全部状态不是同一个问题，但公开资料没有证明这条研究链能够绕过所有 Play Integrity verdict，因此不能据此宣布 Play Integrity 已经失效。
Google 对 Play Integrity 的设计本身也是分层的，包含 App Integrity、Device Integrity、许可状态、Play Protect、App Access Risk、Recent Device Activity 和 deviceRecall 等信号，并建议服务端采用 tiered enforcement，而不是用单一布尔值决定所有登录、支付和交易。Play Integrity API 概览 Android 13 及以上的 MEETS_STRONG_INTEGRITY 还要求系统和 vendor 分区处在近期安全更新范围内；这提高了可信度，却仍不是整台设备永远不会被攻击的证明。Play Integrity 设置说明
本文是面向企业团队的安全架构与发布验收指南。本文没有使用真实客户账号、设备标识、完整证书或私钥执行 Play Integrity、Key Attestation 或 Root 环境测试；所有项目矩阵和候选结果写为 NOT_TESTED，不能被解释为御盾已经阻断某个 OEM 漏洞。
读者对象
本文适合金融、支付、钱包、游戏、会员、数字内容以及企业内部 App 的 Android 研发、安全、风控和发布负责人。若需要先了解御盾的代码与运行时保护范围，可阅读御盾 APP 加固产品说明；需要建立实测流程时，可参考APP 加固 PoC 验收指南和性能与兼容性中心。设备、安装与环境证据的责任边界，可参阅守界设备证据产品说明。
核心结论
- Bootloader locked 和 Verified Boot green 主要说明启动配置与镜像验证链的状态，不是运行时所有代码和 OEM 服务均无漏洞。
- Play Integrity 是平台提供的 App、设备、许可和风险信号集合，
MEETS_STRONG_INTEGRITY是高等级条件，不是“绝对安全”标签。 - Key Attestation 可以让服务端验证密钥是否由受硬件支持的 Keystore、TEE 或 StrongBox 保护，但它不等于整个 App 或账号会话没有风险。Android Key Attestation
- Root 检测、Hook 迹象、版本信息和安装环境都只能作为风险输入；客户端不应单独返回最终 allow 或 reject。
- 御盾保护的是 App 自身的 DEX、SO、资源、签名关联、完整性和运行时关键路径；Android/OEM 补丁负责平台漏洞，客户后端负责账号、交易和权益裁决。
- 公开资料没有证明 OEMpocalypse 成功后仍能通过所有 Play Integrity verdict，因此文章只讨论分层防守和验证边界，不提供绕过方法。
- 每份兼容或风控 PoC 至少记录 OEM、型号、Android 版本、Security Patch Level、Bootloader 状态、Play Integrity 标签、候选摘要、业务路径和测试日期。
事实依据与脱敏证据
| 编号 | 来源与可核验事实 | 对工程的意义 | 不能推出的结论 |
|---|---|---|---|
| 1 | Calif OEMpocalypse：公开研究描述多个 OEM 设备上的 root 演示，并记录 locked Bootloader 与 Verified Boot green | 需要把启动链与运行时证据拆开记录 | 所有 Android 设备都能按同一方式被攻破 |
| 2 | Play Integrity 概览：Google 提供 App、Device、Licensing、Play Protect、访问风险和活动信号 | 服务端可按业务动作使用不同信号 | 某一个 verdict 代表整台设备绝对安全 |
| 3 | Play Integrity 设置：MEETS_STRONG_INTEGRITY 在 Android 13+ 还涉及近期系统与 vendor 更新 |
把补丁日期纳入环境记录 | Strong verdict 可以替代所有客户端保护 |
| 4 | Key Attestation：服务端可验证硬件支持的密钥和安全级别 | 关键会话可以绑定设备生成的密钥 | 硬件密钥能证明业务操作一定合法 |
| 5 | Android 2026 年 9 月安全公告：平台按 Security Patch Level 发布 Framework、System、Kernel 等修复 | 兼容测试需要记录补丁基线 | APP 加固可以修复系统 CVE |
| 6 | 御盾 APP 加固产品说明：产品范围包含客户端代码、Native 与运行时保护 | 定义候选包的保护责任 | 御盾是 Android 平台补丁服务 |
| 7 | 守界设备证据说明：设备和安装信号需要交给后端解释 | 避免把本地检测结果直接当裁决 | 一个设备字段可以替代账号风控 |
| 8 | APP 加固 PoC 验收指南：原始包、保护候选和关键业务路径应分开验收 | 便于归因与回滚 | 单次启动成功代表全部路径通过 |
| 9 | Android 安全公告：补丁基线与 OEM 交付可能存在差异 | 测试报告需要 OEM 与补丁字段 | Android 版本号相同就代表环境相同 |
原始报告事实映射（公开安全摘要）
以下内容把 2026 年 9 月 16 日推进报告中的公开观察转换为工程问题。报告是选题依据，不是设备实验记录；没有把事件报道改写成御盾测试结论。
| 报告观察 | 可公开结论 | 需要的工程动作 | 当前状态 |
|---|---|---|---|
| OEMpocalypse 展示锁定 Bootloader 与 Verified Boot green 下的 root 情形 | 启动链信号与运行时状态需要分层 | 把 Bootloader、Verified Boot 和运行时证据分列 | NOT_TESTED |
| 公开资料没有证明绕过全部 Play Integrity verdict | 不声称平台完整性已被绕过 | 等待授权设备与服务端 verdict 再验证 | NOT_TESTED |
| Google 建议 Play Integrity 使用分层策略 | 风险处置应按业务动作分级 | 建立 observe、challenge、restrict、block 状态 | NOT_TESTED |
| Strong Integrity 与近期补丁条件有关 | Security Patch Level 是重要上下文 | 在兼容矩阵中增加补丁与 vendor build | NOT_TESTED |
| Key Attestation 能验证硬件密钥安全级别 | 密钥证明与 App 完整性是两种证据 | 记录 attestation 结论而不公开证书材料 | NOT_TESTED |
| 9 月 Android 安全公告覆盖多平台组件 | OEM 补丁应单独进入回归 | 用原包和候选包拆分系统归因 | NOT_TESTED |
| 客户端信号不能决定最终交易 | 账号、会话、设备和行为需要后端合并 | 在服务端建立策略版本和审计记录 | NOT_TESTED |
| 御盾负责 App 代码与运行时保护 | App 层和平台层责任不同 | 输出候选身份、完整性和运行证据 | NOT_TESTED |
report_evidence:
report_date: 2026-09-16
research_context: oempocalypse_public_defensive_summary
device_id: REDACTED_OR_CONTROLLED
oem: NOT_TESTED
model: NOT_TESTED
android_version: NOT_TESTED
security_patch_level: NOT_TESTED
bootloader_state: NOT_TESTED
verified_boot: NOT_TESTED
play_integrity_labels: NOT_TESTED
key_attestation: NOT_TESTED
yudun_candidate: NOT_TESTED
business_path: NOT_TESTED
server_policy: NOT_TESTED
exploit_or_bypass_reproduction: NOT_PERFORMED
production_private_material: CUSTOMER_CONTROLLED_NOT_SHARED
动态时间线与字段时间线
设备可信问题会随补丁、Play 服务、应用版本和账号状态变化。建议每次回归都保留一条动态时间线，而不是只在报告首页写“支持 Android 17”。
| 阶段 | 字段 | 责任主体 | 当前状态 |
|---|---|---|---|
| 公开研究复核 | 来源、发布日、研究边界、不可推断事项 | 安全团队 | 已有公开来源，非项目测试 |
| 设备基线 | OEM、型号、Android、Security Patch Level、vendor build | 测试团队 | NOT_TESTED |
| 启动链状态 | Bootloader、Verified Boot、加密状态 | 设备管理员 | NOT_TESTED |
| 平台 verdict | Play Integrity App/Device/Play Protect 等标签 | 客户后端 | NOT_TESTED |
| 硬件密钥 | Key Attestation 安全级别、证书链校验结果 | 客户后端 | NOT_TESTED |
| 原始 Release | Package、证书摘要、版本、原始摘要 | 发布团队 | NOT_TESTED |
| 御盾候选 | 保护策略版本、候选摘要、完整性事件 | 御盾与客户 | NOT_TESTED |
| 业务会话 | 账号状态、会话年龄、动作类型、历史风险 | 客户后端 | NOT_TESTED |
| 最终策略 | observe、challenge、restrict、block 与策略版本 | 客户风控 | NOT_TESTED |
每次策略变更都要保存“变更前信号、变更后动作、回滚策略”，并将设备唯一标识、证书原文和服务端密钥放在受控系统，不放入公开报告。
技术拆解：Verified Boot、Play Integrity 与 Key Attestation 各自回答什么
Verified Boot 是启动链证据
Verified Boot 关注启动镜像和分区的验证链，Bootloader locked 表示设备处在受锁定策略约束的启动状态。它们能帮助判断启动阶段的配置和镜像完整性，却不能替代对运行中 OEM 服务、应用进程、账号会话和业务接口的判断。系统补丁也必须由 Android 或 OEM 交付，APP 加固无法将未修复的 Framework、Kernel 或 OEM 服务漏洞变成已修复状态。Android 2026 年 9 月安全公告可作为补丁基线来源。
Play Integrity 是平台信号集合
Play Integrity 的价值在于把应用身份、安装来源、设备完整性、许可、Play Protect 和部分滥用风险以可验证响应交给服务端。它适合参与登录升级、提现、支付、兑换、匹配和高价值内容访问等策略，但不同业务的容忍度不同。普通浏览可以观察，敏感动作可以挑战或限制，只有在证据充分且误伤代价可接受时才考虑阻断。Google 的分层建议意味着，研发不应把 MEETS_STRONG_INTEGRITY 简化成“永远放行”，也不应把较低 verdict 直接等价成恶意。
Key Attestation 是密钥所在安全级别证据
Android Key Attestation 可以让后端检查密钥证明链和安全级别，例如硬件支持的 TEE 或 StrongBox。适合将短期会话、设备生成密钥和高价值动作绑定，防止客户端仅凭一个可变字段声称自己拥有某种密钥。它回答的是“这把密钥在哪里生成和保护”，并不回答“这次交易是否符合账号行为”或“App 内所有代码均未被干预”。
Root 检测只能作为风险输入
Root、Hook、调试、异常进程、系统属性和加载环境的检测各有可见范围，也可能受到 Profile、OEM 差异和隐私隔离影响。客户端报告“未发现”时，含义只是当前检查点没有发现该类迹象；它不等于设备没有隐藏空间、没有平台漏洞或没有被操控。建议把检测结果与安装身份、版本、会话历史、账号风险和动作价值一起送到服务端，由策略版本决定下一步。
御盾 APP 加固负责什么
御盾的边界在 App 层：保护 DEX、SO、关键资源、完整性校验、二次打包后的候选身份和运行时关键路径，提升修改、复制、调试和干预的成本。加固候选必须先与原始 Release 建立可复核关联，最终生产签名仍由客户或受控签名系统负责。需要区分的是，御盾可以协助发现候选包与登记发布身份是否连续，却不能代替 Android 平台补丁、Play Integrity 服务、硬件证明或服务端业务授权。
对高价值路径，推荐最小证据组合：
合法 Package 与签名关系
+ 原始 Release / 加固候选摘要
+ App 完整性与运行时事件
+ Play Integrity 结果
+ Key Attestation（适用时）
+ 设备补丁与环境上下文
+ 账号、会话、动作和历史
↓
服务端策略版本
↓
允许、二次验证、限制或人工复核
这套组合不是要求每个普通页面都收集所有字段，而是让业务团队按风险动作选择证据深度。设备证据的具体采集和解释，可与守界设备证据产品分工；客户端代码与运行时保护则回到御盾的产品能力页。
攻防视角：只讨论防守，不提供绕过路径
从防守角度，OEMpocalypse 这类公开研究有三点启示。第一，启动状态、系统版本与运行时状态必须拆开；第二，平台信号与 App 自身完整性要有独立字段；第三，高价值动作要结合服务端历史，而不是在客户端写一个不可解释的开关。对开发团队而言，最重要的不是复制研究中的利用链，而是审查发布流程、补丁节奏、候选包身份和策略回滚是否可追踪。
安全审查可以提出这些问题：当前设备的补丁日期是什么？平台 verdict 是否与包身份匹配？候选包是否来自受控构建？服务端是否能识别旧版本、异常签名和重复会话？一条证据失效时，是否有降级、挑战和人工复核路径？这些问题不会泄露攻击方法，却能帮助团队把边界落实到工程流程。
工程落地：Device Trust Evidence Matrix 企业项目应该记录什么
| 字段 | 示例要求 | 公开状态 |
|---|---|---|
| OEM / Model | 设备厂商与型号，不公开序列号 | NOT_TESTED |
| Android / Patch | Android 版本、Security Patch Level、vendor build | NOT_TESTED |
| Boot chain | Bootloader、Verified Boot 等状态 | NOT_TESTED |
| Platform verdict | App、Device、Play Protect 等标签 | NOT_TESTED |
| Key evidence | Attestation 安全级别与校验时间 | NOT_TESTED |
| App identity | Package、证书摘要、versionCode | NOT_TESTED |
| Yudun evidence | 候选摘要、完整性事件、策略版本 | NOT_TESTED |
| Context | Profile、安装来源、会话和动作类型 | NOT_TESTED |
| Backend action | observe、challenge、restrict、block | NOT_TESTED |
| Recheck | 复核时间、回滚对象、未覆盖范围 | NOT_TESTED |
矩阵不是“打分器”。同一个设备在普通浏览、登录、支付、提现等动作上的策略可以不同；同一个 verdict 也可能因为账号冻结、会话异常或版本过旧而触发更严格动作。结果必须有策略版本、时间和责任主体，避免事后只剩一个没有上下文的 PASS。
企业发布与兼容验收
系统安全公告、Play 服务、OEM 更新和 APP 保护策略都可能变化。建议采用四组变量拆分归因：
旧补丁 + 原始 Release
新补丁 + 原始 Release
新补丁 + 御盾基础候选
新补丁 + 御盾目标候选
先确认原始 Release 在新环境中的启动、登录、关键接口和会话恢复，再比较保护候选。如果原始包已失败，应优先排查系统、WebView、SDK、服务端或网络环境；只有在相同设备、相同补丁和相同业务路径下原始包通过而候选首次失败，才进入保护模块的定位。任何真实 PoC 都应记录 Android 版本、Security Patch Level、Play System Update、OEM、ABI、候选摘要和测试日期；本页没有执行这些项目，统一保留 NOT_TESTED。
风险边界
- 御盾不修复 Android Framework、Kernel、OEM 服务或供应链漏洞。
- 御盾不替代 Play Integrity、Play Protect、Verified Boot 或 Key Attestation。
MEETS_STRONG_INTEGRITY、Bootloader locked、Verified Boot green 和 Root 未检出都不是绝对安全证明。- 御盾不把客户端信号直接升级为账号、支付、交易或反欺诈最终结论。
- 设备、Profile、安装和环境证据需要客户后端按业务上下文解释。
- 任何机型、补丁或策略未测试时都写
NOT_TESTED，不从一台设备外推到全部设备。 - OEMpocalypse 的公开事实不等于御盾完成了漏洞复现、阻断或验证。
常见误区
通过 Strong Integrity 就可以关闭所有风控吗？
不可以。它是高价值平台信号，仍需结合 App 身份、账号、会话、动作和服务端历史。
Bootloader locked 是否等于没有 Root？
不等于。它主要描述启动配置，不能覆盖所有运行时和 OEM 代码状态。
Key Attestation 能替代 APP 加固吗？
不能。它保护和证明密钥，APP 加固保护代码、资源、完整性与运行时路径，两者互补。
Root 检测未发现异常是否就能放行提现吗？
不应直接放行。提现等高价值动作应使用多源证据和服务端策略。
APP 加固后能否修复九月 Android CVE？
不能。平台漏洞需要 Android/OEM 安全补丁；加固用于降低 App 自身代码和运行时攻击面。
是否应该看到 Work Profile 就禁止登录？
不应该。Profile 是环境事实，不是风险结论，应结合企业场景、账号和动作判断。可参考企业私有 App 与 Work Profile 指南。
测评目标与非目标
| 测评目标 | 本页处理方式 | 状态 |
|---|---|---|
| 定义 Play Integrity、Key Attestation 与 APP 加固边界 | 使用官方资料与公开产品事实 | 已完成内容说明 |
| 建立设备可信字段矩阵 | 给出字段、责任和结果状态 | NOT_TESTED |
| 比较不同补丁或 OEM 环境 | 仅定义变量和归因顺序 | NOT_TESTED |
| 验证某个 OEM 漏洞是否可复现 | 不执行、不发布利用链 | NOT_PERFORMED |
| 证明御盾通过全部 Play Integrity verdict | 不作此声明 | NOT_APPLICABLE |
| 给出客户端最终交易结论 | 明确交给客户服务端 | NOT_APPLICABLE |
| 评估真实账号、设备或客户 APK | 不使用、不接收 | NOT_TESTED |
| 规划下一轮合法 PoC | 只保留防守字段与回滚要求 | NOT_TESTED |
FAQ
Play Integrity 和 APP 加固是什么关系？
Play Integrity提供平台侧的 App、设备和风险信号；APP 加固保护客户端代码、二进制、完整性和运行时关键路径。两者处在不同层，应该由服务端统一解释，而不是互相替代。
MEETS_STRONG_INTEGRITY 能证明设备绝对安全吗？
不能。它是更高等级的设备完整性信号，并包含近期安全更新条件，但不能证明所有 OEM 服务、运行时进程、账号和业务行为均无风险。
OEMpocalypse 是否证明 Play Integrity 已被绕过？
公开研究证明的是特定 OEM 代码面存在从普通应用到 root 的演示，并记录了 locked Bootloader 与 Verified Boot green；目前不能据此推断成功绕过所有 Play Integrity verdict。
企业为什么要记录 Security Patch Level？
同一 Android 大版本可能有不同的 Framework、Kernel、vendor 和 Mainline 状态。补丁日期帮助团队解释 verdict、兼容性和事件发生时的真实环境。
御盾可以做 Root 检测吗？
御盾可以在客户端保护和运行时证据层协助采集或校验部分风险信号，但不声称识别全部 Root 或证明整台设备绝对安全。具体放行与限制由客户服务端决定。
出现异常时应该先找谁？
如果原始包在同一环境也失败，先检查系统补丁、OEM、SDK、WebView、网络和服务端；如果原始包通过而保护候选首次失败，再进入御盾候选的保护模块归因。设备与安装证据由相应设备证据系统提供。
下一步建议
企业可以先选择一个无敏感数据的内部 Demo，建立 Package、签名摘要、原始 Release、御盾候选、设备补丁、Play Integrity 响应和服务端动作的脱敏记录。第一轮只做基线，不尝试复现公开漏洞；第二轮比较补丁变化和候选变化；第三轮将登录、支付或兑换等高价值动作接入分层策略。提交评估时只需提供脱敏字段和业务路径，生产私钥、账号凭据、设备唯一标识和完整攻击材料均应留在客户受控环境。
如需把客户端保护、设备证据和发布验收连成同一流程，可从御盾 APP 加固产品页、守界设备证据产品页和兼容性中心开始，申请一份范围明确、结果可回滚的企业 PoC。