Paytm 开始全面接入 Google Integrity：UPI 自动化行业正式进入“设备风控时代”

今年以来，越来越多的印度 UPI 应用开始接入：

Google Play Integrity 完整性校验体系

其中：

Paytm 就是典型代表之一。

因此，在实际逆向与安全研究中，

核心问题已经不再只是：

“协议如何构造”

而是：

“如何对抗 Google Integrity 检测体系”。

一、Google Play Integrity 校验原理

Play Integrity 本质上是：

Google 基于 GMS（Google Mobile Services）构建的一套设备可信度验证机制。

1. 基本工作流程

APP 通常会：

APP ↓ 通过 Binder 与 GMS 服务通信 ↓ 发送 nonce（随机挑战值） ↓ GMS 返回 Integrity Token ↓ APP 上传 Token 至业务服务器 ↓ 业务服务器再向 Google 服务器校验 Token

最终判断：

当前设备环境是否可信。

2. 核心通信特点

Play Integrity 机制通常涉及：

• GMS 跨进程通信
• Binder IPC
• 与 Google 服务端联网校验
• Token 签名与加密
• Runtime 环境检测
• 设备完整性验证

3. 当前研究重点

在实际研究中，重点通常包括：

• Binder 通信过程
• nonce 构造方式
• Token 返回结构
• GMS 与 Google 的交互
• 加密与签名逻辑
• 如何影响 GMS 获取到的设备环境信息

4. 常见 GMS 组件来源

部分研究环境中会使用：

• BiTGApps
• NikGApps

等模块化谷歌套件。

通常通过：

• Magisk
• KernelSU

进行安装与管理。

二、设备环境检测维度

当前 UPI APP 对设备环境的检测已经非常全面。

1. 系统与 Root 环境检测

常见检测项包括：

• Bootloader 是否解锁
• 是否 Root
• Magisk 环境
• 调试状态
• USB 调试开关
• 开发者模式
• Frida / Hook 环境

2. 网络与地区环境检测

通常会检测：

• VPN
• 代理
• TLS 指纹
• IP 地址
• IP 地区
• Wi-Fi Proxy
• DNS 环境

3. 设备与身份信息检测

包括：

• Android ID
• DRM ID
• Device Fingerprint
• SIM 卡状态
• 地区语言
• ROM 版本
• 系统版本
• 安装应用列表

4. 静态与动态检测

静态检测：

• 软件环境
• 硬件环境
• 网络环境
• 文件系统

动态检测：

• Runtime 环境
• 内存扫描
• 进程空间扫描
• 动态代码检测
• Hook 检测
• 注入检测

三、Paytm 典型检测机制

以 Paytm 为例，

目前最核心的两个检测方向包括：

A. 硬件 TEE 层检测

主要依赖：

Google 硬件级 Key Attestation

部分研究环境中，会通过：

TrickyStore

模拟旧设备环境。

其核心思路是：

使用旧设备指纹， 让 Google 认为： “当前设备属于不支持硬件 TEE 的旧机型”

从而降低硬件级校验强度。

B. 软件层完整性检测

软件层通常涉及：

• Fingerprint
• Build 信息
• 系统属性
• ROM 环境

部分研究环境会结合：

Play Integrity Fix

修改设备指纹相关属性。

四、历史版本中的典型案例

在部分历史版本中，

曾出现：

服务端未严格校验 Integrity Token 的情况。

例如：

在某些早期版本中，

请求 OTP 时即使缺失 Integrity Token，

服务端仍可能继续处理请求。

其本质原因是：

服务端没有强制校验 Token 字段存在性。

而在后续版本中：

相关校验逻辑已经逐步加强。

五、常见研究工具链与组件

在 Android 安全研究中，

通常会使用如下组件组合构建测试环境。

1. KernelSU

作用：

• 内核级 Root
• 模块加载
• init_boot 镜像制作

2. Magisk

作用：

• Android Root 框架
• Boot 镜像修改
• 模块管理

3. Zygisk

作用：

• 注入 Zygote
• Runtime Hook
• Magisk 模块依赖环境

4. Shamiko

作用：

• 隐藏 Root 环境
• 隐藏 Magisk
• 隐藏 Zygisk 痕迹

通常配合：

Zygisk 配置列表

使用。

5. LSPosed

作用：

• Android Hook 框架
• 模块管理与启用
• Java 层 Hook

6. HMA（Hide My Applist）

作用：

• 隐藏安装应用列表
• 对指定 APP 隐藏 Root 工具

例如：

对 Paytm 隐藏：

• MT 管理器
• Magisk
• Frida 工具

7. TrickyStore

作用：

• 模拟旧设备环境
• 影响硬件级完整性校验

通常会配合：

• keybox.xml
• pif.json

等配置文件使用。

8. Play Integrity Fix

作用：

• 修改 Fingerprint
• 修改系统属性
• 影响软件层完整性判断

9. BiTGApps / NikGApps

作用：

• 模块化安装 GMS 套件
• 提供 Google 服务环境

10. Applist Detector

作用：

用于验证：

应用隐藏是否成功。

通常作为：

HMA / Shamiko 配置效果检测工具。

11. Momo

作用：

• Root 检测
• Magisk 环境检测
• Hook 环境检测

12. Riru

作用：

早期 Hook 框架。

目前大多已被：

Zygisk

替代。

13. Play Integrity API Checker

作用：

检查：

设备 Integrity 状态是否通过。

14. Key Attestation 工具

作用：

验证：

• 设备 Bootloader 状态
• 硬件级完整性状态

15. MagiskFrida

作用：

系统级加载 Frida。

可配合：

Shamiko

降低检测概率。

16. Enable Screenshot / DisableFlagSecure

作用：

允许：

禁止截图的 APP 被投屏或截图。

方便：

• 调试
• 研究

17. TrustMeAlready

作用：

强制 APP 信任用户证书。

常用于：

HTTPS 抓包研究。

18. Move Certificates

作用：

将用户安装证书移动为：

“系统证书”

降低被 APP 检测的概率。

19. KsuWebUI

作用：

KernelSU 管理界面。

六、当前行业变化趋势

目前 UPI APP 的安全策略已经从：

“简单 Root 检测”

升级为：

“设备级 + 行为级 + Runtime 级”
联合风控。

因此：

现在真正困难的，

已经不是：

“是否能抓到数据”

而是：

“研究环境能稳定存活多久”。

这也是为什么：

越来越多研究开始关注：

• Runtime 环境隔离
• 设备行为模拟
• Integrity 绕过
• Hook 隐藏
• 真机环境控制

等方向。

因为：

UPI 自动化行业，已经正式进入“设备可信度时代”。

欢迎技术交流 :https://github.com/upi-research-lab/india-payment-upi