PlayIntegrityFix：深入解析 Play Integrity（及 SafetyNet）判定修复原理与 Android 13+ 兼容性对策-平芜编程栈

应用安全
系统编程

【免费下载链接】PlayIntegrityFix

Fix Play Integrity (and SafetyNet) verdicts.

项目地址：https://gitcode.com/GitHub_Trending/pl/PlayIntegrityFix

导读

PlayIntegrityFix（PIF）是一个通过 Zygisk 在系统属性读取层与 GMS 进程内部实现"双层伪装"的通用模块，目标是在解锁 Bootloader、安装 Magisk / KernelSU / APatch 的设备上，让 Play Integrity API 与 SafetyNet 校验尽可能返回符合预期的判定。本文以仓库 README.md 为骨架，结合 module/ 目录下的安装脚本与 app/src/main/cpp/main.cpp 的原生实现，讲清楚三件事：Android 13+ 之后 Play Integrity 判定逻辑发生了怎样的根本性变化，为什么现在需要 keybox 与 TrickyStore 才能通过 Device 判定，以及该项目提供了哪些可用的过渡方案与官方建议。

一、核心警告：Android 13+ 的判定规则已经彻底改变

README 的开篇即给出本模块当前面临的最关键事实：

Google 已移除 Android 13 及以上版本的 legacy（旧版）检查；如今 Device 判定与过去的 Strong 判定完全等价。

这意味着在 Android 13 及以上的设备上，即使你伪装了指纹（fingerprint）并修复了系统属性，Play Integrity 也会把 "Device" 判定当作原来的 "Strong" 级别来审查——对硬件级证明（keybox / hardware-backed attestation）的要求显著提高，单靠软件层面的属性伪造已经不足以通过。

由此可以推出两个直接结论：

若想至少通过 Device 判定，你需要一个有效的 keybox，并配合 TrickyStore 模块使用。项目源码中同样可以看到对 TrickyStore 的原生支持：在 app/src/main/cpp/main.cpp 定义了TS_PATH（/data/adb/modules/tricky_store），并在进程内检测到 TrickyStore 存在时自动关闭自身的spoofProvider与spoofProps（见 main.cpp），把硬件证明层面的伪装交给 TrickyStore 处理，避免双方互相干扰。
Android 12 及更低版本目前仍然是"安全"的。这些系统仍在使用 legacy 检查路径，PIF 的传统属性伪装方案依然有效，这是当前项目明确标注的适用边界。

判定级别的历史背景

Play Integrity 的判定通常分为三个等级（由低到高）：Basic、Device、Strong。在 Android 13 之前的 legacy 体系里，通过指纹与属性伪装通常足以拿到 Device 判定；而 Strong 需要 Google 硬件密钥（keybox）背书。如今 Google 将 Android 13+ 的 Device 判定直接升级为旧 Strong 的标准，实际上就是把"软件伪造通过 Device"这条路基本堵死——这正是 README 发出警告的原因，也是该模块后续版本转向与 TrickyStore 协作、引入 keybox 支持的根本动因。

二、过渡方案：PlayIntegrityFork 与 spoofVendingSdk

README 明确指出，存在一个"不太稳定"的过渡方案：

可以使用 PlayIntegrityFork 并启用 spoofVendingSdk，这会强制现代设备走 legacy 检查路径；但副作用是 Play Store 有时会异常，甚至直接崩溃。

该方案的核心思路是：让 GMS（com.google.android.gms）认为自己运行在"较旧"的 SDK 环境中，从而触发旧的校验代码路径。需要注意的是：

这是强制手段，与现代设备真实的运行时环境不一致，因此属于"不稳定"方案；
副作用集中在 Play Store 及其关联进程（崩溃、功能异常）；
适合愿意折腾、能接受副作用的进阶用户，不适合追求稳定日常使用的普通用户。

结合仓库原生层的实现来看，项目本身就维护了对api_level一类系统属性的动态改写：在 main.cpp 的modify_callback中，所有以api_level结尾的属性都会被改写成DEVICE_INITIAL_SDK_INT（该值来自 pif.json 中的DEVICE_INITIAL_SDK_INT字段，见 main.cpp）。你可以把DEVICE_INITIAL_SDK_INT理解为"伪装设备最初发布的 SDK 版本"，它参与了 GMS 对设备年龄与校验路径的推断——这与 spoofVendingSdk 背后的"诱导走旧路径"思路属于同一方向，只是作用层不同。

最稳妥的官方建议

README 最后给出的建议非常直接，值得所有用户认真对待：

如果你不是资深用户，且绝对需要设备通过认证，请安装官方固件（stock ROM）并重新锁定 Bootloader。

换言之，在 Android 13+ 的强校验环境下，最可靠、零副作用的"认证方案"是放弃解锁与修改，回归出厂状态。PIF 及其配套方案更适合：不需要高强度认证、能接受偶尔失败、且具备排查能力的高级用户。

三、仓库配套实现：指纹伪装（pif.json）与自动获取机制

要理解 PIF 的修复逻辑，先看它伪装了什么。模块自带一份出厂配置 module/pif.json，内容如下：

{ "FINGERPRINT": "google/oriole_beta/oriole:16/BP22.250325.012/13467521:user/release-keys", "MANUFACTURER": "Google", "MODEL": "Pixel 6", "SECURITY_PATCH": "2025-04-05" }

这份配置只包含四个字段：FINGERPRINT（完整的 Build.FINGERPRINT 字符串）、MANUFACTURER、MODEL与SECURITY_PATCH。在原生层，main.cpp 会把FINGERPRINT按/和:拆分为 8 段，分别映射到：

BRAND
PRODUCT
DEVICE
RELEASE
ID
INCREMENTAL
TYPE
TAGS

也就是说，只要配置一个合法指纹，Build系列字段就会被整套改写，这正是 GMS 校验"设备是否来自正规渠道"的关键输入。SECURITY_PATCH与ID则分别对应安全补丁级别与 build ID，同样在属性读取回调里被动态改写（main.cpp）。

action.sh：自动抓取最新 Pixel Beta 指纹

模块还附带了一个自动更新指纹的脚本 module/action.sh。它的工作流程是：

下载 Android 开发者官网的版本页，解析出最新 Beta / Developer Preview 的 URL（BETA_URL）；
进入对应版本页，提取 Pixel OTA 下载链接；
从 OTA 页解析出MODEL_LIST、PRODUCT_LIST、OTA_LIST；
若未预置PRODUCT，则随机选取一台 Pixel Beta 设备（set_random_beta，见 action.sh）；
从 OTA 元数据中提取post-build=（指纹）与security-patch-level=（安全补丁日期，见 action.sh）；
校验字段非空后写入/data/adb/pif.json（action.sh），并强制杀掉com.google.android.gms.unstable进程使配置生效（action.sh）。

这个脚本解决了手动维护指纹的痛点：每次 Google 发布新的 Pixel Beta，指纹都会更新，避免因指纹陈旧被判定为可疑。用户可以从 Magisk / KernelSU / APatch 的模块列表里直接触发它，无需进入终端。

配置文件加载优先级

原生层对 pif.json 的加载顺序定义在 main.cpp：

默认：/data/adb/modules/playintegrityfix/pif.json（模块内置配置）；
Fork 定制：/data/adb/modules/playintegrityfix/custom.pif.json；
用户自定义：/data/adb/pif.json（最高优先级，也是 action.sh 的输出位置）。

安装脚本 customize.sh 会在升级时把已存在的/data/adb/pif.json备份为pif.json.old，防止升级覆盖用户自定义指纹。

四、支持的附加开关（spoof 系列选项）

从 main.cpp 的成员变量可以看出，模块内置了三个布尔开关，均可在 pif.json 中显式配置：

字段	默认值	作用
`spoofProps`	`true`	是否 hook 系统属性读取（`__system_property_read_callback`），动态改写 api_level / security_patch / build.id 等敏感属性（main.cpp）
`spoofProvider`	`true`	是否向 GMS 进程注入 dex，替换系统 provider / 包信息以伪造 GMS 相关组件
`spoofSignature`	`false`	是否伪装 APK 签名；当检测到当前 ROM 使用测试密钥签名（test keys）时自动置为`true`（main.cpp）

解析逻辑见 main.cpp。当 TrickyStore 被检测到时，spoofProvider与spoofProps会被强制关闭，避免与 TrickyStore 的硬件证明伪装冲突（main.cpp）。

注意：这些开关属于仓库实现细节，README 并未逐一声明，属于"从源码结构可以推断"的能力。实际是否启用、如何搭配，应以你所在设备与 ROM 的实测为准。

五、属性清理：敏感属性修复脚本

除指纹伪装外，模块还会在系统启动阶段修复一批"泄露解锁状态"的属性。这些逻辑分布在两个脚本中：

module/service.sh：在 boot 完成前（sys.boot_completed轮询，见 service.sh）修复恢复模式、SELinux、bootloader 锁状态等属性，例如将ro.secureboot.lockstate改为locked、ro.boot.flash.locked改为1、ro.boot.verifiedbootstate改为green（service.sh），同时避免在部分小米/Realme/Oppo/OnePlus 机型上触发指纹失效或启动异常；
module/post-fs-data.sh：更早期阶段处理厂商专属敏感属性（三星的warranty_bit、Realme 的realmebootstate、OnePlus 的is_ever_orange等），并将ro.debuggable、ro.secure恢复为出厂值（post-fs-data.sh）。

两个脚本共用 module/common_func.sh 中的resetprop_if_diff（仅在当前值不同于目标值时写属性）与resetprop_if_match（匹配包含关系后改写），避免不必要的属性写入。

DenyList 与 Shamiko 协同

module/post-fs-data.sh 还处理了 Magisk DenyList 的联动：当 DenyList 开启强制模式时，会把 GMS 从 DenyList 中移除（因为 Zygisk 模块本身已在 GMS 进程中工作，无需 DenyList 再隐藏）；而当检测到 Shamiko 且未启用白名单模式时，则把 GMS 与 Play Store 加入 DenyList，交由 Shamiko 隐藏。

六、安装前提与兼容范围

模块的元信息在 module/module.prop 中声明：

id=playintegrityfix name=Play Integrity Fix version=v19.1 versionCode=19100 description=Universal modular fix for Play Integrity (and SafetyNet) on devices running Android 8-15

安装脚本 customize.sh 做了四件事：

拒绝 Recovery 安装：必须在 Magisk / KernelSU / APatch 应用内安装（customize.sh）；
版本下限检查：Android 8.0（API 26）以下直接中止安装（customize.sh）；
Zygisk 检查：必须启用 Zygisk（Magisk 设置）或安装 ZygiskNext / ReZygisk，否则中止（customize.sh）；
冲突模块处理：自动标记移除已过时的 safetynet-fix（customize.sh），并对 playcurl、MagiskHidePropsConf 等可能冲突的模块给出警告（customize.sh）。

升级信息由 update.json 提供（versionCode 19100），Magisk 等管理器可通过它检测并提示更新。

七、验证与排查要点

安装并配置完成后，可通过以下方式验证效果：

在 Play Store 设置 → 关于中查看"Play 保护机制认证"状态；
使用 Play Integrity API 测试应用（如 Play Integrity API Checker 类工具）分别查看 Basic / Device / Strong 判定；
若判定异常，查看 GMS 日志（com.google.android.gms.unstable）确认属性改写是否生效——原生层会通过PIF标签输出[prop]: old -> new形式的改写日志（main.cpp），便于定位哪些属性没被正确伪装。

最后再次强调 README 的核心结论：在 Android 13+ 上，PIF 单靠指纹与属性伪装已无法保证通过 Device 判定，需要 keybox + TrickyStore 组合；若必须稳定通过认证，最可靠的选择仍是回锁 Bootloader 使用官方固件。本项目适合愿意持续跟进方案、能接受不稳定的高级用户，而非追求"一键永久通过"的普通场景。