指南高级 11 分钟阅读

SafetyNet 与 Play Integrity API：Root 后如何通过检测（2026）

Name: Droid Rooter
Price range: $$

SafetyNet 已于 2024 年退役，由 Play Integrity API 取代。以下介绍 2026 年如何借助 Magisk 加 Shamiko 通过 MEETS_DEVICE_INTEGRITY 以及基础的银行类应用检测。

作者 Alex Dutrow | 发布于 2026年5月2日

Android Root 社区用了十年的 SafetyNet API，Google 已于 2024 年初正式停用，并由 Play Integrity API 取代。2024 年之前写的所有指南现在都已过时，老论坛帖子里还流传着大量错误信息。本指南是当前实用的 2026 年操作指南：发生了什么变化，Play Integrity 的三种判定结果实际意味着什么，2026 年哪些绕过工具有效，以及分步设置说明，包括具体的 Magisk 命令。面向已有 Root 设备、需要让银行和支付类应用正常运行的高级用户。

简史：从 SafetyNet 到 Play Integrity

SafetyNet（2014-2024）是 Google 的设备证明 API。它返回两个布尔值：ctsProfileMatch（这台设备是否符合已知的兼容性测试套件配置？）和 basicIntegrity（设备是否通过 Bootloader 已锁定等基础完整性检查？）。银行类应用通过 Google Play 服务调用它，拿到这两个布尔值，只要有一个为 false 就拒绝运行。十年间，绕过方法不断演变：最初是 MagiskHide，Magisk 24 移除 MagiskHide 后改用 Zygisk + DenyList，再在上面叠加 Shamiko 实现更强的隐藏。

Play Integrity API（2023 年至今）是官方的替代方案。弃用时间线如下：

2023 年 6 月：Play Integrity API 作为首选替代方案推出
2023 年中至 2024 年初：应用开始从 SafetyNet 迁移到 Play Integrity
2024 年 1 月：SafetyNet 正式弃用；不再保证新的 API 响应
到 2026 年中：几乎所有主流银行和支付类应用都只使用 Play Integrity

Play Integrity 返回三种判定结果，而不是两个布尔值，并在最严格的级别使用硬件密钥证明，因此仅靠软件方法绕过要难得多。

Play Integrity 的三种判定结果

每次 Play Integrity 检查都会返回三个布尔值：

MEETS_DEVICE_INTEGRITY

基础级别。表示设备运行未经修改的 Android，已安装 Google Play 服务，并通过基础兼容性检查。使用当前工具（Magisk + Zygisk + DenyList + Shamiko + Play Integrity Fix 模块），在已 Root 设备上可以绕过。约 60% 的应用需要此判定结果才能正常运行。

MEETS_BASIC_INTEGRITY

更严格的检查，包含一些额外的环境验证：系统文件完整性、Google Play 服务的预期状态、某些调试状态检查。在已 Root 设备上大多可以绕过，但对模块配置更敏感。约 30% 的应用除 DEVICE_INTEGRITY 外还要求此判定结果。大多数银行类应用两者都要求。

MEETS_STRONG_INTEGRITY

最难的级别。使用硬件支持的密钥证明：设备的 TEE（可信执行环境）对响应签名，该签名可以一路验证到设备制造商的根证书。即使 Bootloader 处于锁定状态也能照常工作，因为密钥受安全元件保护。在已解锁 Bootloader 的设备上，当前的软件方法无法绕过它，因为解锁会破坏 TEE 密钥所依赖的验证启动链。

约 10% 到 20% 的应用要求 STRONG_INTEGRITY：

部分地区的 Google Wallet NFC 感应支付
若干数字银行（Revolut、Wise，部分地区的 N26）
某些政府身份类应用（数字护照、选民证）
合规要求严格的医疗类应用
部分雇主下发、受 MDM 保护的办公应用

如果你必不可少的应用要求 STRONG_INTEGRITY，那么 Root 与它们不兼容，目前没有任何变通办法能改变这一点。

绕过工具：Magisk Hide、Shamiko 与 TrickyStore

目前在已 Root 设备上绕过 Play Integrity，2026 年主要靠三种工具配合：

2026 年 Android Root 环境下常用的 Play Integrity 绕过工具。Magisk + Zygisk + DenyList + Shamiko + PIF 是标准组合；TrickyStore 只在特定应用失败时才添加。
工具	作用	绕过范围	设置难度	被检测风险
Magisk DenyList（内置）	通过 Zygisk Hook 对列表中的应用隐藏 Root 状态	单独使用时仅限 MEETS_DEVICE_INTEGRITY	简单：Magisk 内置	基础应用风险低；面对严格的银行检测则不够
Shamiko（LSPosed 模块）	在 DenyList 之上增加更强的隐藏：隐藏 Zygisk 本身，对系统查询隐藏应用进程	与 PIF 搭配时，约 80% 的银行类应用可达到 MEETS_DEVICE + BASIC	简单：通过 Magisk 模块安装	低；与 DenyList 配合时不易察觉
Play Integrity Fix（PIF）	把发送给 Google 证明服务器的设备指纹，伪装成当前已知可通过的指纹	2026 年任何判定绕过都离不开它	简单：安装模块并运行自动更新命令	中等；取决于指纹是否够新
TrickyStore	在密钥库层面伪造硬件密钥证明响应；可通过检查密钥库一致性的应用	把可绕过的应用范围再增加 5% 到 10% 的较严格应用	难：需要为每台设备手动配置密钥列表	较高；部分应用能检测到 TrickyStore 伪造的响应
Magisk Hide（旧版）	已从 Magisk 24+ 移除，由 DenyList + Zygisk 取代	不适用：别在当前的 Magisk 里找它	N/A	N/A

分步操作：让基础银行类应用通过 Play Integrity

假设你已经具备：

已解锁 Bootloader
已通过打过补丁的 boot.img 安装 Magisk
已在 Magisk Manager 中验证 Root 正常工作

如果还没有，请先看我们的Bootloader 解锁指南和 Magisk、KernelSU 与 APatch 对比。

第 1 步：在 Magisk 中启用 Zygisk

打开 Magisk 应用 → Settings（齿轮图标）→ 启用 Zygisk 开关。重启。

重启后，回到 Magisk Settings，启用 Enforce DenyList。

第 2 步：安装 Shamiko

从 GitHub 上 LSPosed/LSPosed 的官方发布页下载最新的 Shamiko zip。在 Magisk 应用 → Modules 标签页 → 点按 + 图标 → 选择 Shamiko zip → 安装。重启。

重启后，确认 Shamiko 已加载：Magisk 应用 → Modules 标签页 → 列表中应有 Shamiko，且处于启用状态。

第 3 步：安装 Play Integrity Fix 模块

从 chiteroman/PlayIntegrityFork 的 GitHub 发布页下载最新的 PIF zip（或其他当前仍在维护的分支，请在 XDA 认证开发者的帖子里查看最新推荐）。

Magisk 应用 → Modules → + → 安装 PIF zip → 重启。

第 4 步：把 PIF 指纹更新为当前可通过的指纹

PIF 里的指纹需要匹配一台目前能通过 Play Integrity 的已知设备。PIF 模块自带自动更新脚本。打开终端应用（Termux 即可）并运行：

bash

su -c sh /data/adb/modules/playintegrityfix/action.sh

这会拉取社区维护的最新可通过指纹并应用。重启。

第 5 步：为你的应用配置 DenyList

Magisk 应用 → Configure DenyList → 搜索每个你需要使用的银行、支付或检查 Play Integrity 的应用。点按每个应用旁的开关以启用隐藏。子进程条目通常会自动勾选。

常见需要添加的应用：

你的主要银行应用（HDFC、SBI、Bank of America、Lloyds 等）
移动钱包应用（bKash、GCash、M-Pesa、JazzCash）
支付应用（Google Pay、PayPal、Venmo、Cash App）
券商应用（Robinhood、Zerodha、Groww）
政务应用（DigiLocker、Aadhaar、NHS app）
带 DRM 的流媒体应用（Netflix、Disney+、Amazon Prime，它们会检查 Play Integrity 来决定是否提供 HD/4K）

第 6 步：用 Play Integrity API Checker 验证

从 Play 商店安装 Play Integrity API Checker（有多个版本；可以试试 gkkang 的版本，或 LSPosed 团队维护的版本）。

打开它，点按 Check。查看：

MEETS_DEVICE_INTEGRITY：应为 true
MEETS_BASIC_INTEGRITY：应为 true
MEETS_STRONG_INTEGRITY：在已解锁 Bootloader 的设备上为 false，属于正常现象

如果 DEVICE 和 BASIC 都返回 true，说明绕过在判定层面已经生效。大多数银行和支付类应用现在应该能正常运行。

第 7 步：逐个测试每个银行类应用

逐个打开每个应用。确认它能越过启动画面并让你登录。如果有应用失败：

确认该应用已在 DenyList 中启用
重新运行 PIF 自动更新命令，刷新指纹
重启
如果仍然失败，说明该应用可能使用了 Play Integrity 之外的额外检测：可以试试加上 TrickyStore 作为额外一层，或者接受该应用与你当前的 Root 方案不兼容

判定已通过，应用仍然失败时

部分应用会使用官方 Play Integrity API 之外的其他检测手段：

直接扫描文件：查找 /system/bin/su、Magisk 二进制文件路径或已知的模块安装路径。变通办法：启用 Magisk 中相当于 MagiskHide 的文件隐藏功能（较新版本的 Magisk 已内置）。
检查进程命名空间：检查 /proc/self/status 及类似位置中的 Zygisk Hook 特征。变通办法：Shamiko 能处理大多数情况。
独立于 Play Integrity 的 TEE 证明质询。变通办法：部分应用可用 TrickyStore，其他应用则无解。
应用自带的黑名单：由应用开发者维护，包含已知与 Root 相关的包名。变通办法：在Settings中使用Hide the Magisk app，把它改成一个看起来不像 Magisk 的名字。

各地区银行类应用现状：已 Root 的 Android 上目前哪些能用

不同地区的银行类应用表现差异很大，因为每家银行自行决定完整性检查的严格程度。以下依据 2026 年孟加拉国、印度、巴基斯坦和英国市场的客户反馈：

孟加拉国

bKash：大多数用户用 Magisk + Shamiko + PIF 即可；Google 更新后偶尔需要更新指纹
Nagad：同一组合可用；对指纹是否够新稍微更敏感
Rocket (DBBL)：标准组合可用
City Bank、BRAC Bank、EBL、Dutch-Bangla Bank 的应用：大多数用标准组合可用；每次 Play Integrity 更新后请再检查
各银行自己的 NFC 感应支付：通常要求 STRONG_INTEGRITY；在已 Root 设备上无法绕过

印度

Google Pay (Tez)：UPI 用标准组合可用；NFC 感应支付（在支持的地区）要求 STRONG_INTEGRITY
PhonePe、Paytm：UPI 用标准组合可用
HDFC、ICICI、SBI YONO、Axis Mobile：大多数可用；HDFC 和 Axis 稍严格，某些功能可能需要 TrickyStore
券商应用（Zerodha Kite、Groww、Upstox）：标准组合可用
Aadhaar mAadhaar 应用：大多数功能可用；生物识别功能可能需要额外的隐藏配置

巴基斯坦

JazzCash、Easypaisa：对大多数用户来说，两者用标准组合都可用
HBL Mobile、UBL Digital、Meezan Bank Mobile：大多数可用；三者中 Meezan 最严格
NayaPay、SadaPay（数字银行）：不确定；在依赖 Root 使用之前请先检查

英国和欧盟

大多数主流银行应用（Lloyds、Barclays、HSBC、Santander、NatWest）：截至 2026 年年中，用标准组合可用
数字银行（Revolut、Wise、N26、Monzo）：Revolut 和 Wise 出了名地严格，部分流程经常要求 STRONG_INTEGRITY；Monzo 和 Starling 通常宽松一些
Apple/Google 感应支付的同类功能：要求 STRONG_INTEGRITY；无法绕过

这份清单反映的是撰写时的情况，会经常变化。在把 Root 用于时间紧迫的金融场景之前，请务必测试你自己的具体应用。

STRONG_INTEGRITY 在 TEE 层面到底涉及什么

为高级用户提供的简要技术背景：为什么在已解锁 Bootloader 的设备上，STRONG_INTEGRITY 从根本上无法绕过。

现代 Android 设备包含可信执行环境（TEE）：一个独立的安全处理器，有自己的内存和操作系统，与主 Android 系统隔离。TEE 持有出厂时写入的设备唯一加密密钥，由制造商的根证书颁发机构签名。

当应用请求 STRONG_INTEGRITY 时，请求会经过 TEE，由 TEE 使用这些出厂写入的密钥对响应签名。响应中包含当前的验证启动状态，也就是一条哈希链，证明 Bootloader 已锁定，且 boot、system 和 vendor 分区与制造商签名的预期一致。

解锁 Bootloader 后，TEE 会把验证启动状态更新为“yellow”（用户安装的密钥）或“orange”（没有验证启动）。TEE 仍会对 STRONG_INTEGRITY 响应签名，但响应会明确包含已解锁的状态。要求 STRONG_INTEGRITY 的应用会检查这个字段，只要状态不是 green（Bootloader 已锁定，启动链由制造商签名），就拒绝运行。

软件无法伪造这一点，因为 TEE 签名所用的密钥，主系统无从访问。TrickyStore 可以在密钥库调用到达 TEE 之前拦截它，并用从类似设备预先录制的“正常”响应来替换。对没有严格校验响应硬件来源的应用，这种做法有效；但会验证的应用（严格的那些）会发现这种替换。

能通过 STRONG_INTEGRITY 的唯一可靠方式：

运行原厂固件的 boot.img并重新锁定 Bootloader。部分设备（Pixel、某些 OnePlus 机型）支持在刷入制造商签名的镜像后重新锁定 Bootloader。这能恢复 STRONG_INTEGRITY，但会失去 Root。
使用另一台未 Root 的备用设备，处理少数要求 STRONG_INTEGRITY 的应用。

没有隐藏的第三条路。TEE 的设计目的就是防止这一点。

无特殊原因同时运行多个 Play Integrity 绕过模块：它们经常冲突，弄坏的应用比修好的还多。
使用来源不明的随机 PIF 分支。请坚持使用维护中的主线分支，并查看 XDA 帖子获取当前推荐。
依赖绕过来处理高价值金融交易。对输不起的金额，请改用未 Root 的备用设备，并阅读银行服务条款中关于已 Root 设备欺诈责任的规定。
为 Play 商店本身启用 Root。Play 商店不必加入 DenyList，这样做可能破坏 Play 商店的功能，却没有任何好处。

何时该找专业人员

如果某个银行应用在你 Root 后无法使用，而你已经试过标准组合，请通过 WhatsApp 或 Telegram 联系我们。针对孟加拉国、印度、巴基斯坦、英国、美国和欧盟市场的大多数主流银行，我们都有经过验证、已知可用的配置，通常能在 30 到 60 分钟的远程会话里让应用恢复正常。服务内容请看我们的Android Root 服务。

关于 DenyList 和 Shamiko 背后的模块细节，我们的Magisk 模块指南介绍了当前的 Play Integrity 隐藏方案，以及哪些分支仍在维护。

常见问题

SafetyNet 与 Play Integrity API 有什么区别？

SafetyNet 是 Google 此前的设备证明 API，银行和支付类应用用它来检测已 Root、已修改或模拟器上的 Android 设备。Google 于 2024 年初正式停用 SafetyNet，并以 Play Integrity API 取而代之，后者提供三种完整性判定结果（DEVICE_INTEGRITY、BASIC_INTEGRITY、STRONG_INTEGRITY），而不是 SafetyNet 单一的 ctsProfileMatch + basicIntegrity 组合。Play Integrity 更难用 Root 绕过，因为 STRONG_INTEGRITY 判定使用的硬件密钥证明，无法用软件伪造。

2026 年已 Root 的 Android 能通过 Play Integrity API 吗？

MEETS_DEVICE_INTEGRITY 和 MEETS_BASIC_INTEGRITY：可以。只要 Magisk + Zygisk + DenyList + Shamiko + Play Integrity Fix 模块配置正确，已 Root 设备上约 80% 到 90% 的银行和支付类应用能正常运行。MEETS_STRONG_INTEGRITY：几乎不可能，因为它要求由硬件证明的启动状态，而解锁 Bootloader 会从根本上破坏这一状态。要求 STRONG_INTEGRITY 的那 10% 到 20% 的应用（部分数字银行、某些政府类应用、部分地区用于 NFC 感应支付的 Google Wallet），目前没有任何方法能在 Root 下让它们工作。

最好的 Play Integrity 绕过模块是哪个，Shamiko 还是 TrickyStore？

Shamiko 更容易设置，对大多数常见银行类应用有效。TrickyStore 更激进：它伪造由硬件证明的密钥响应，能通过某些 Shamiko 通不过的应用，但对会再次核对密钥库一致性的应用，被检测的风险更高。我们建议先从 Shamiko + Play Integrity Fix 开始，只对单靠 Shamiko 失败的特定应用再加上 TrickyStore。在配置不正确的情况下同时运行两者，失败的应用反而可能比只运行其中一个还多。

为什么 Play Integrity 绕过方法每隔几个月就会失效？

Google 大约每季度更新一次 Play Integrity 的检测逻辑，每次更新通常都会让至少一种绕过技术失效。社区会在几天到几周内给出更新的指纹和模块版本。周期是这样的：Google 发布检测更新 → 90% 到 99% 的绕过配置失效 → 社区在 1 到 4 周内发布修复 → 绕过恢复。请预留每季度 1 到 2 周，其间你的银行类应用可能暂时无法使用；并备好一台未 Root 的备用手机或原厂固件的 boot.img，以应对时间紧迫的交易。

即使启用了 Shamiko，银行类应用也会检测到 Magisk 吗？

有些会。Shamiko 的原理是对检查 Zygisk 的应用隐藏 Magisk 的进程名和 Zygisk Hook，但使用其他检测手段的应用（检查 SELinux 状态、查找 /system/bin/su、扫描磁盘上已知的 Root 二进制文件、比对 /proc 中的不一致）仍然可能通过这些渠道检测到 Root。Play Integrity Fix 模块解决的是判定响应这一侧；具体应用层面的检测是另一个问题，因应用而异。对 80% 的应用来说，Shamiko + PIF 就够了。对其余 20%，则需要针对具体应用的变通办法（或者接受该应用无法在已 Root 的设备上使用）。

配置了 Magisk DenyList 后，用银行应用安全吗？

从技术安全角度看，是安全的：DenyList 不会削弱银行应用的加密、证书固定或会话安全，它只是对应用的环境检查隐藏 Magisk 的 Root 状态。你的银行会话的加密和认证强度，与在原厂固件设备上完全一样。从合同角度看，银行的服务条款可能禁止在已 Root 的设备上运行其应用：在依赖它处理高价值交易之前，请先阅读条款，也请了解，如果发生欺诈交易，而银行发现设备已 Root，对方可能拒绝赔偿。对于低金额的日常银行业务，这样的取舍是合理的；对于高价值交易，请考虑使用未 Root 的备用设备。