Fosvcat's Blog

详解 Play Integrity 完整性认证

Properties1
tagsandroid

29分钟阅读

基础知识

一句话概括：Play Integrity 是 Android 系统的 Google 服务框架提供的在线认证机制，用于证明系统是“正版”和“可信”的。

关于

Play Integrity 的中文常被称作“设备完整性”，是SafetyNet（已弃用）的继任者。大概运作原理：操作系统传递一个随机数 (nonce)，TEE会配合密钥签名并返回判决。Google Play Services和Play Store通过判决以及机型信息、指纹、安全更新补丁日期等信息在线验证。未解锁且及时进行系统更新的原厂设备会完全通过并证明：

1.系统经Play保护机制认证且得到过近期安全更新

[INFO] Play Integrity API - replacement for SafetyNet

2.系统运行在正规厂商制造的设备上

3.设备没有解BL锁且未经修改

这样 Google 就提供了一个统一且强大的“合法环境检查”机制，任何游戏、银行等应用只需通过 Play Integrity API ****请求一下检测，即可快速得知设备状态。

三种等级

  • Basic 设备未被批准运行 Google Play 服务，不满足 Android 兼容性要求
  • Device 一般性正常状态，通过了系统完整性检查，满足 Android 兼容性要求
  • Strong 具有强有力（如硬件级）的系统完整性保证，满足 Android 兼容性要求

通过每一级完整性前都要求先通过上一级

应用开发者可以自行决定他们的应用正常运行所要求的判决（目前如此），多数请求检测的应用都只要求到 Device 完整性，如 Google Wallet，和 Google 信息的“RCS消息”功能。也有一些应用要求达到 Strong 完整性，如 Netflix、Google VPN、Octopus。

这个帖子记录了一些应用对完整性等级需求和设备环境检查的情况

Apps&Games need PI (List)

新旧判定

在 Android12(SDK32)及更低版本上，设备完整性使用旧判定，亦称传统判定

在 Android13(SDK33)及更高版本上，设备完整性使用新判定，亦称A13+判定

新旧判定都分同样的 Basic Device Strong 三等级，但新判定每一级都相比旧判定更加严格。

~~Play Integrity Fix 模块提供了可选的SDK欺骗，使 Android13+ 用户能仍然使用旧判定。~~

检查方法

Play store

登录 Google 账号并打开Play商店，点按头像进入设置。
展开「关于」，连续点按「Play 商店版本」打开开发者模式。
展开「常规」，进入「开发者选项」。
点按「检查完整性」即可显示检测结果。

第三方检测器应用

第三方检测器可以在不登录Google账号的情况下使用。最常用的是Play Integrity API Checker。注意，第三方检测器可能遇到检测次数限制，此时就只能使用 Play store。

Play Integrity API Checker - Apps on Google Play

在Play商店下载后打开，直接点击「检查」即可

不要对完整性检测器隐藏 GMS 应用，没必要且可能会干扰其正常工作。

Play 保护机制认证

如果你既不想登录 Google 账号，也不能正常使用三方检测器应用，可以点击 Play store 右上角的「关于」，查看 Play 保护机制认证状态，它取决于 DEVICE_INTEGRITY 结果。第一次查看需等待几秒钟，若显示未通过认证，说明未达到 Device 完整性；若显示已经过认证，说明达到了 Device 完整性。Play 保护认证状态滞后于 Integrity 判定约几小时，如果想要立即靠它进行判定，需要清空 Play Store 数据（这不会移除 Google 账号）。

Key 和 TEE

  • 如果你牛逼，可以研究通过漏洞或别的什么途径提取有效Keybox
  • 如果你有钱，自己想办法去买一个私有Keybox（USD200？），当然风险自负
  • 都没有就找几个专门公开 Strong Keybox 的地方，每天检查几下，失效了就找新的用

KEY/密钥

Keybox 就是一串 SHA-256 签名的密钥数据

所有 keybox 均由且只能由 Google 创建（因为只有 Google 拥有生成 keybox 的私钥），并分发给各个经认证的 Android 原始设备制造商 (OEM)。制造商在生产设备时每个设备都会包含一个唯一的有效Key，存储在TEE中。

分区上，大部分设备密钥通常存储在 persist 分区，动它就可能导致Key丢失。

每个出厂设备的 Key 都是唯一的，因此 Google 一旦检测到同一个有效 Key 被过多设备请求验证，即可简单的判定 Key 被泄露，并将其吊销。能网上流传的一些强密钥，其本质就是泄露的密钥，被吊销和失效只是时间问题。

Key Attestation 可用于检验密钥，可直接检测本地设备，也可以加载其它密钥。

GitHub - vvb2060/KeyAttestation

使用密钥认证功能来验证由硬件支持的密钥对  |  App quality  |  Android Developers

  • 蓝色-有效的强 Keybox
  • 黄色-默认的 AOSP Keybox
  • 红色-Keybox 被禁止/吊销

TEE/可信执行环境

TEE（Trusted Execution Environment）是设备上的硬件安全区 (ARM TrustZone)

当发出 fastboot unlock 命令时，Bootloader会查询 TEE 的 OEM-unlock 开关（在开发者选项中的），如果已启用，则会命令 TEE 设置 VerifiedBootState = UNLOCKED，清除或屏蔽密钥，并清除data。

  • 设计合理的设备（如Pixel）在解锁后，会主动屏蔽TEE中的认证密钥，导致TEE失效。只要不乱动存储密钥的敏感分区，回锁后即可恢复。
  • 还有一些设备解锁后密钥直接丢失，俗称炸TEE。密钥即使回锁也不会恢复。
  • 全地球只有小米设备解锁BL后仍保留TEE功能。但修改敏感分区还是可能导致TEE损坏。

解BL锁不会对 TEE 硬件造成物理损坏，而是从软件逻辑上破坏认证机制。

由于TEE的硬件级安全设计，即便解锁前已获得系统root权限，也几乎不可能从中提取密钥。即便有漏洞或厂商疏忽导致密钥泄露，Google 也可以从上层封禁，使从漏洞泄露的密钥全部失效。即使是未经修改的原厂设备，证书也可能被定期轮换吊销，要及时通过系统更新确保 Key 有效。

以上种种原因叠加，使得真正私有的有效 key 较为罕见和昂贵，也出现了很多买卖骗局。

Play Integrity Fix

关于

本模块试图修复 Play Integrity 判定，以获得有效的认证

~~Play Integrity Fix （简称pif）是一个 Zygisk 模块，它使用 Play Integrity API 修复 Android <13 “deviceRecognitionVerdict” 的“MEETS_DEVICE_INTEGRITY”。其目标是实现 Basic 和 Device 判定（<A13）~~

模块/项目

需要使用PIF模块时，根据个人喜好和需求情况选一个装上用

Play Integrity Fix Fork

PIF Fork 以更具前瞻性并更有条不紊地开发。笔者没用过，好像功能上和原版区别不大

https://github.com/osm0sis/PlayIntegrityFork

该项目的README有很多有用的信息

Play Integrity Fix-inject

PIF注入版，vending版自动启用欺骗，manual版可手动控制各欺骗选项

https://github.com/KOWX712/PlayIntegrityFix

欺骗指纹

Play Integrity Fix 的主要功能

Fingerprint/指纹 是一个 Android 系统构建属性，由你的 ROM 信息组成，仅与设备 ROM 的构建有关，用于识别 ROM 的特定构建/编译。

指纹信息也参与在 Play Integrity 认证中，有很多指纹被 Google 封禁使得特定 Rom 无法过完整性认证。而 PIF 可以联网为 Rom 更新有效指纹并欺骗 GMS。

额外欺骗选项

PIF-inject 提供了额外的欺骗选项。很适合用于自定义 Rom，或用于更离谱的无 Google 认证的 Android 环境（智能音箱、VR设备之类的）。

Spoof Props：伪装系统 Props，未使用 TrickyStore 时启用。

Spoof Provider：伪装 keystore 提供程序，未使用 TrickyStore 时启用。但会导致 Google Wallet 不可用。

Spoof Signature：伪装系统签名，用于使用 testkey 的自定义Rom等。

修复 RCS 消息

Google 信息的 RCS 消息功能需要 Device 完整性使用。实测在一个仅安装 Tricky Store 的 Strong 完整性设备上 RCS 消息并不能正常发送，而在另一个使用 PIF 的 Device 完整性设备上， RCS 消息功能正常。也就是说 PIF 对 Google 信息的 RCS 消息有某种修复作用，具体细节笔者暂时未知。

更多信息

作为开源项目，使用 PIF 过程中有很多可选的灵活的的操作，我觉得没有必要把一些他人总结好的知识复制过来，如果你想深入了解，请根据给出的链接自行学习。

PIF常见问题，以及关于指纹和 DroidGuard 的更多知识，请参考这篇帖子：

PIF FAQ

了解了上一篇后，可以查看如何获取指纹并创建自己的 pif.json ：

🔧 [MODULE] Pray Integrity Fix 🙏

How to search & find your own fingerprints [noob friendly]: A…

Play Integrity Fix

原版PIF，作者 chiteroman 在2025年6月6日声明因个人原因停止开发，并删除了Github账户

chiteroman

欺骗SDK

*（可能）已被 Google 修补？

Play Integrity Fix 的另一项功能就是欺骗SDK为旧版，使得 GMS 执行旧判定

意味着如果你在 Android 13+ 上启用欺骗 SDK ，接下来的流程按照旧判定（A12）即可。

由于新判定的 Device 必须要求使用有效密钥，所以在没有有效密钥的情况下，该功能是 A13+ 用户过 Device 的唯一选择。

但很可惜，该欺骗有代价，目前主要问题是这两个：

  • Play 商店崩溃（如点击“搜索”、“开发者选项”时）
  • Play Store 检测不到 Google 帐户（但不影响已登录账户的功能使用）

或许 PIF 开发者能在之后能够修复它们。在那之前，建议使用平替软件 Aurora Store

https://github.com/whyorean/AuroraStore

Tricky store

https://github.com/5ec1cff/TrickyStore

Tricky store（简称TS）目前是闭源模块，用于修改为 Android 密钥鉴证生成的证书链。此外还可以欺骗特定应用，并隐藏已解锁的 BootLoader 和 TEE 损坏。

data/adb/tricky_store/ 是其存放keybox等文件的目录。

安装后其自带的keybox.xml为AOSP默认密钥，意味着足以通过BL锁检查和旧判定的 Device 。

你可以将其替换为自己的 Keybox ，但建议重命名留一份AOSP.xml备用。

替换 keybox 后可即时进行检测，无需重启。

（A13+）安装后，你还需要在 data/adb/tricky_store/target.txt 内添加目标应用包名：

com.google.android.gms 
com.google.android.gsf 
com.android.vending

io.github.vvb2060.keyattestation
io.github.vvb2060.mahoshojo
icu.nullptr.nativetest
com.henrikherzig.playintegritychecker
com.google.android.apps.walletnfcrel

必须添加 GMS 三件套（Google服务、服务框架、Play商店），也可以添加上密钥认证和完整性检测器应用。不要添加太多应用进去，没必要且可能造成卡顿。

推荐的另一个模块：Tricky Addon ，与 Tricky store 配合工作，通过 WebUI 界面提供一些便捷功能。如管理目标应用，提供 AOSP key，配置安全补丁日期，导入 keybox 等。

https://github.com/KOWX712/Tricky-Addon-Update-Target-List

BASIC 基础完整性

必要条件

  • 不存在修改 GMS 进程的任何模块
  • 系统运行在实体设备上（品牌和型号）
  • 启用设备加密（Android10+ 已默认启用）
  • SELinux Enforcing

问题处理

如果你连 BASIC 都没有过，应该：

  • 通过 PlayIntegrityFix 尝试不同的指纹 （pif.json）
  • 禁用/卸载 除 PlayIntegrityFix、ZygiskNext、Shamiko 以外的所有模块，包括 Tricky Store 和任何与 Zygisk 、integrity 有关的模块或修改器应用。

注意：一些修改系统的模块（包括 Xposed）也可以触发 DroidGuard 检测，任何 hook GMS 进程的模块（例如自定义字体）都可以触发。

旧判定（A12）

（没有额外要求）

新判定（A13+）

首先，隐藏本地的Root与Zygisk

无论用什么管理器和模块，这是最基本的。例如在 Magisk 安装 Shamiko 并在排除列表中勾选所有GMS应用，你可以使用momo等检测器来检查。

如果你怀疑隐藏不起作用，那就先卸载Zygisk Next模块/关闭Zygisk，重启检查，再尝试重装。

其次，在 密钥认证 内检查：

TEE/Keymaster 安全等级：可信环境

TEE/Keymaster SecurityLevel: TrustedEnvironment

如果 TEE 已经炸了或别的原因导致无法认证，就需要 Tricky Store + Keybox

DEVICE 设备完整性

必要条件

1 - Fingerprint/指纹 有效

官方原厂系统通常不用担心指纹问题。

部分类原生 Rom 内置了欺骗指纹的功能，优先使用它们。

如果确定了 Rom 指纹有问题，并且 Rom 没有提供相关的修复选项，那么就安装 Play Integrity Fix 来提供有效指纹。

2 - 私钥签名的 Rom

仅适用于第三方Rom，使用该命令检查Rom的签名密钥：

unzip -l /system/etc/security/otacerts.zip

如果输出显示 “testkey”，则是使用测试密钥签名的，先告知 Rom 的开发者开始使用私钥对他们的构建进行签名，以便下次构建，理想情况下，还要提供 ROM 签名迁移构建，以允许用户在不擦除数据的情况下更新。使用测试密钥签名的Rom即使有有效的指纹，不依赖欺骗也不会通过设备判定。

带有丰富的欺骗选项类原生 Rom 可能内置了 Play Integrity 的欺骗功能，先尝试启用它们试试看。如果系统不自带或不起作用，查看上文的 PIF-inject ，额外欺骗选项提供了签名欺骗，安装后在 WebUI 中打开对应开关即可。

如果输出显示 “releasekey”，但是是第三方Rom，那它仍可能使用 AOSP testkey 进行签名。根据具体情况选择是否启用签名欺骗。如果是 releasekey+官方Rom，那通常就没有问题。

3 - 未被标记的内核名

Google列了个黑名单，把一些知名类原生Rom和自定义内核名称列了进去，如Lineage、CrDroid、ElementalX。去链接查看这个内核名称黑名单，并使用该命令检查你设备的内核名称。

🔧 [MODULE] Pray Integrity Fix 🙏

uname -r

如果命令输出的内核名不与黑名单上的匹配，就不用担心内核名的问题，放心进行下一步。

如果在，先告知 Rom 的开发者移除关键字。接下来能做的可以是替换别的内核，自己编译个内核，也可以使用16进制编辑器给现有内核改个名字：

首先尝试直接编辑 boot.img，使用十六进制编辑器的查找文本功能。如果内核没有压缩，那么能直接搜索到关键字。如果它被压缩，需要先解压 boot.img（如左图中使用Magiskboot.exe），再编辑Kernel文件，再重新压缩打包回 boot.img。无论如何，编辑完保存刷入即可

右图中已经使用 WinHex 找到了内核名，可以直接修改，但是不要动别的任何东西。
图中的内核名 Nethunter 目前实测不在黑名单中。

Google 的内核黑名单随时可能会更新。如果你后续怀疑这个问题，可以使用此改名法排查一下。
也可以使用 SuSFS 进行隐藏。

GitHub - sidex15/susfs4ksu-module: An addon root hiding service for KernelSU

旧判定（A12）

~~对于旧判定，AOSP key 能直接过 Basic 和 Device~~

~~安装 Play Integrity Fix 后，设备能轻松得到BASIC，DEVICE两种等级~~

如果涉及到三方Rom、内核，优先尝试自带的欺骗功能，不起作用再使用上文的 PIF-inject 并根据情况启用对应的开关。

无论PIF安装与否，都建议安装 Tricky store 并使用有效 key。它能隐藏已解锁的 BootLoader 和 TEE 损坏。

新判定（A13+）

对于使用新判定的 Android 13+ ，必须使用 TrickyStore + 有效Keybox ，才能通过Device判定。

~~否则只能启用spoof sdk，走旧判定过Device~~

如果涉及到三方Rom、内核，优先尝试自带的欺骗功能，不起作用再使用上文的 PIF-inject 并根据情况启用对应的开关。

要求：

  • 有效的强 Keybox 且未被吊销
  • 引导加载程序已锁定（ TrickyStore 可欺骗）
  • 且 TEE VerifiedBootState 为 Locked（ TrickyStore 可欺骗）

按照上文 TrickyStore 模块介绍，正确安装后放入强 Keybox 即可

STRONG 强完整性

一定要求达到强完整性才运行的应用并不多。如果你恰好对这种应用有很大使用需求，那么准备一个不解锁不修改的备用机，不然就回锁。

旧判定（A12）

要求：

  • 有效的强 Keybox 且未被吊销
  • 引导加载程序已锁定（ TrickyStore 可欺骗）
  • 且 TEE VerifiedBootState 为 Locked（ TrickyStore 可欺骗）

按照上文 TrickyStore 模块介绍，正确安装后放入强 Keybox 即可

新判定（A13+）

要求：

  • 有效的强 Keybox 且未被吊销
  • 引导加载程序已锁定（ TrickyStore 可欺骗）
  • 且 TEE VerifiedBootState 为 Locked（ TrickyStore 可欺骗）

按照上文 TrickyStore 模块介绍，正确安装后放入强 Keybox 即可

以及

设备必须获得过一年以内的安全更新，具体是 OSPatchLevel、VendorPatchLevel、BootPatchLevel 与现在的时间差均不超过一年。如果 Rom 保持活跃的开发和更新，那就不会有问题。如果系统约一年未更新，需要在tricky store目录里创建 security_patch.txt 来伪装补丁日期，也可以使用 Tricky Addon 提供的图形界面生成有效值。下面是一个例子：

system=202504
boot=2025-05-05
vendor=2025-05-05

Google Wallet

用户侧的 Google Pay 是集成在 Google Play Service(GMS)软件内部的功能，本质是模拟一张与原卡卡号不同的虚拟银行卡，因此这个核心功能不需要网络，只有添加卡片，同步会员卡、消费记录需要网络连接。

Google Pay 没有也不可能有任何开源的替代实现。“Wallet”应用也只是一个用户界面，支付功能、卡片信息均保存在GMS内，文章后续用户操作也只针对GMS。

任何 Rom 只要启用了 Spoof Provider ，无论密钥是否有效，Wallet 均不可用。

打开 Wallet 应用，点击头像，点击“付款设置”，即可查看钱包可用性。Pixel 设备上的 Wallet 应用可能没有这个按钮。

如果有 Flipper Zero 等设备，可以直接读取。如果钱包正常可用，手机会显示“终端有问题”或“请再次靠近终端”，并能读取出虚拟卡卡号等信息；如果不可用，手机会显示“不符合安全要求”，也无法读出卡信息。少数情况下“付款设置”里显示不符合安全要求却仍然能读出卡信息，但实际上最终无法成功进行支付。

不可用，无法添加卡或刷卡

正常可用状态

通过EMV读取到卡号等信息

一旦 指纹/Key 中的任意一个不再可用，影响到了完整性检查，Wallet就会立马罢工。即使后面修好完整性，Wallet 内也会显示“不符合安全要求”并拒绝刷卡，只有等待约两天，或完全清除GMS数据重新添加卡才能解决。非常麻烦。

由于刷卡支付不需要网络，所以直接给 GMS 断网是最简单粗暴的办法。但缺点也极大，其它 Google 应用也会受断网影响：GMS推送、Play商店、Google搜索、语音助理、圈画搜索 等功能都会大残。

另外，如果一台设备长期离线（90天），其钱包内的卡和支付功能也会被移除。即服务端不会再认该设备。因此该方法最多也只能保证 3个月的稳定使用。

其它

  • 不建议使用公开的修改版 Play Store，因为它可能会被 Google 标记并影响完整性判定。
  • 新判定下，Key 被吊销后，可能掉到 Basic ，也可能三红。取决于 Google ban 的程度
  • MicroG 信息待补充，因为笔者尚未尝试过在 MicroG 环境下过完整性。
  • 2025年7月，Google 为 Wallet 添加了更严格的检测手段。如果 Wallet 显示不符合安全性要求，修复环境后等待 48 小时或清除 play 服务数据（需要重新添加卡）后即可恢复。
  • ~~稳过 Device 的方法：使用 Android12 系统走旧判定，或在 Android13+ 上打开 Spoof SDK 走旧判定，通过 Tricky Store 使用 AOSP 密钥。也可以随时替换为 Strong key，并且即使 Key 被吊销，也只会掉到 Device 。~~ 【AOSP key 被 Google 停用，该法已失效】

PlaySpoofer

Xposed 模块，欺骗 Play Store 为最新版以阻止其自我更新。

PlayVersionSpoofer

PlaycurlNEXT

PIF辅助模块，能定时下载并更新设备指纹，与其它PIF模块兼容性以开发者说明为准

https://github.com/daboynb/playcurlNEXT

TEE 重编程

Play Integruty Fix开发者的另一个项目，尝试在解锁后修复TEE。（嗯，作者删号了…）

https://github.com/chiteroman/Reprogram-TEE-on-Qualcomm-devices

Pixel Props

挺多子项目，具体内容和作用自己看，笔者暂时没用到过。

Pixel Props

最后

从 2015 年的 SafetyNet Attestation 到现在，Google 的验证机制一直在改进和发展。可能不久后它就会发展到极致: 解锁后的系统连 Basic 都难以达到，同时大量的应用都要求 Strong 完整性；用户仍有解BL锁追求自由的权力，但过多的牺牲使这份权力形同虚设。或许这就是 Google 的终极目标呢。

关系图谱