深入剖析 Play Integrity API：能否用纯协议搞定安卓风控？
最近在搞安卓底层风控相关的研究时，发现了一个挺有意思的方向：能不能在不依赖真实 Google 移动服务（GMS）环境的情况下，通过纯协议层面的手段去搞定设备 integrity 检测？
简单来说，就是能不能“伪造”一个让服务端满意的 Play Integrity Token。今天就来跟大家聊聊这背后的技术原理、实现难点以及这东西到底有多少实际价值（或者说危险程度）。
背景：为什么盯着 Play Integrity？
Play Integrity 的信任基础依赖于硬件密钥和 GMS 的评估机制。
众所周知，现在很多主流 App（尤其是像 WhatsApp 这种国际巨头）在 Android 端的风控防线中，都高度依赖 Google 的 Play Integrity API（前身是 SafetyNet）。
你的设备有没有 Root？是不是模拟器？系统有没有被篡改？这些状态不再完全由 App 自己在本地瞎猜，而是由 Google 服务器的一套机制来评定，并给出一个“信任分”。很多 App 只要拿到“未通过”或“低分”的判定，直接就把功能阉割或者禁止登录了。
所以，只要能搞定这个 Token，理论上就能绕过一大片基于 Google 生态的高墙。
核心原理：从“硬件”到“协议”的降维打击
要让 Play Integrity API 判定通过，正规流程需要你的设备符合硬件级的安全标准（比如 TEE 环境和硬件密钥）。但如果你是在虚拟机、模拟器或者已经 Root 的手机上玩，这条路是堵死的。
这次的思路核心在于：协议逆向 + 密钥复用。
核心原理在于剥离对 TEE 硬件环境的强依赖，转而在用户态模拟加密运算。
1. 那个神秘的 keybox.xml
这就像是你身份的身份证。Play Integrity 的信任基础很大程度上依赖于硬件私钥的签名。正常情况下，这个密钥是烧录在芯片里的，极难提取。但一旦有了泄露的 keybox.xml 文件（这东西在某些特定机型或固件中其实是可以流出的），我们就拥有了申请 Token 的“资格”。
2. GMS 逆向工程
有了钥匙，还得知道怎么开门。通过逆向分析 GMS（Google Play Services）中负责生成 Integrity 请求和校验响应的底层逻辑，我们可以剥离掉对硬件环境的强依赖。
简单来说，就是把原本必须在 TEE 环境执行的加密运算，在用户态（比如 App 沙箱内）模拟执行一遍。只要算法逻辑是对的，并且拿着偷来的合法 Key 做签名，Google 的服务器只要验签通过，大概率就会给你发一个合法的 Token。
这套方案能干啥？（实际价值调研）
目前代码层面已经走通了，可以产出可用的 Token，甚至可以模拟任意 Android 硬件型号来过检。但为什么没开源？因为价值太大，风险也太大。我们来盘盘这东西能用在哪些场景：
1. 自动化与脚本测试（白帽视角）
对于一些需要在非标准环境（如 CI/CD 服务器、各种云手机）进行自动化测试的公司，物理设备成本太高。如果能用纯协议伪造检测通过的环境，能极大降低测试成本，提高效率。
2. 灰产对抗与模拟器隐藏（黑/灰视角）
这是最容易想到的用例。很多工作室需要在模拟器上批量跑业务，但现在的 App 一检测到模拟器就封号。如果能把模拟器伪装成“完美”的 Pixel 原生机并通过 integrity 检测，那对于群控、薅羊毛来说，简直是神技。
3. 安全研究
n作为安全研究者，能够生成各种极端情况下的 Token（比如伪造 Bootloader 解锁状态），可以用来服务端风控系统的健壮性进行测试（当然，前提是你有授权）。
需要注意的风险与难点
虽然原理听起来简单，但实际落地并不容易：
- Keybox 的有效期与绑定：Google 可不是傻子。每个 Keybox 可能都和特定设备型号甚至序列号绑定。如果网络请求层的设备指纹和你伪造 Token 里的硬件信息对不上，服务端可能会触发风控。
- GMS 版本差异：GMS 更新极快，逆向出来的协议可能在下一个版本就变了。这意味着维护成本极高，得时刻跟进最新版的加密逻辑。
- 账号关联风险：如果大规模滥用同一个 Keybox 生成 Token，Google 很容易识别出异常，导致该 Keybox 及其关联的设备指纹直接拉黑。
总结
Play Integrity API 的纯协议实现，本质上是一次对“信任链”的挑战。它证明了只要掌握核心凭证和加密逻辑，软件层面的伪造是可行的。
对于技术人员来说，这不仅是绕过限制的工具，更是研究现代移动安全架构的一个绝佳切入点。至于它最终会被用来提升测试效率，还是在黑灰产里掀起波浪，就看它掌握在谁手里了。
出于防滥用和合规考虑，具体代码细节就不公开了，大家当个技术参考聊聊就好。
评论已关闭