今年以来越来越多的印度 UPI 应用开始接入Google Play Integrity 完整性校验体系其中Paytm 就是典型代表之一。因此在实际逆向与安全研究中核心问题已经不再只是“协议如何构造”而是“如何对抗 Google Integrity 检测体系”。一、Google Play Integrity 校验原理Play Integrity 本质上是Google 基于 GMSGoogle 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 组件来源部分研究环境中会使用BiTGAppsNikGApps等模块化谷歌套件。通常通过MagiskKernelSU进行安装与管理。二、设备环境检测维度当前 UPI APP 对设备环境的检测已经非常全面。1. 系统与 Root 环境检测常见检测项包括Bootloader 是否解锁是否 RootMagisk 环境调试状态USB 调试开关开发者模式Frida / Hook 环境2. 网络与地区环境检测通常会检测VPN代理TLS 指纹IP 地址IP 地区Wi-Fi ProxyDNS 环境3. 设备与身份信息检测包括Android IDDRM IDDevice FingerprintSIM 卡状态地区语言ROM 版本系统版本安装应用列表4. 静态与动态检测静态检测软件环境硬件环境网络环境文件系统动态检测Runtime 环境内存扫描进程空间扫描动态代码检测Hook 检测注入检测三、Paytm 典型检测机制以 Paytm 为例目前最核心的两个检测方向包括A. 硬件 TEE 层检测主要依赖Google 硬件级 Key Attestation部分研究环境中会通过TrickyStore模拟旧设备环境。其核心思路是使用旧设备指纹 让 Google 认为 “当前设备属于不支持硬件 TEE 的旧机型”从而降低硬件级校验强度。B. 软件层完整性检测软件层通常涉及FingerprintBuild 信息系统属性ROM 环境部分研究环境会结合Play Integrity Fix修改设备指纹相关属性。四、历史版本中的典型案例在部分历史版本中曾出现服务端未严格校验 Integrity Token 的情况。例如在某些早期版本中请求 OTP 时即使缺失 Integrity Token服务端仍可能继续处理请求。其本质原因是服务端没有强制校验 Token 字段存在性。而在后续版本中相关校验逻辑已经逐步加强。五、常见研究工具链与组件在 Android 安全研究中通常会使用如下组件组合构建测试环境。1. KernelSU作用内核级 Root模块加载init_boot 镜像制作2. Magisk作用Android Root 框架Boot 镜像修改模块管理3. Zygisk作用注入 ZygoteRuntime HookMagisk 模块依赖环境4. Shamiko作用隐藏 Root 环境隐藏 Magisk隐藏 Zygisk 痕迹通常配合Zygisk 配置列表使用。5. LSPosed作用Android Hook 框架模块管理与启用Java 层 Hook6. HMAHide My Applist作用隐藏安装应用列表对指定 APP 隐藏 Root 工具例如对 Paytm 隐藏MT 管理器MagiskFrida 工具7. TrickyStore作用模拟旧设备环境影响硬件级完整性校验通常会配合keybox.xmlpif.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
Paytm 开始全面接入 Google Integrity：UPI 自动化行业正式进入“设备风控时代”
今年以来越来越多的印度 UPI 应用开始接入Google Play Integrity 完整性校验体系其中Paytm 就是典型代表之一。因此在实际逆向与安全研究中核心问题已经不再只是“协议如何构造”而是“如何对抗 Google Integrity 检测体系”。一、Google Play Integrity 校验原理Play Integrity 本质上是Google 基于 GMSGoogle 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 组件来源部分研究环境中会使用BiTGAppsNikGApps等模块化谷歌套件。通常通过MagiskKernelSU进行安装与管理。二、设备环境检测维度当前 UPI APP 对设备环境的检测已经非常全面。1. 系统与 Root 环境检测常见检测项包括Bootloader 是否解锁是否 RootMagisk 环境调试状态USB 调试开关开发者模式Frida / Hook 环境2. 网络与地区环境检测通常会检测VPN代理TLS 指纹IP 地址IP 地区Wi-Fi ProxyDNS 环境3. 设备与身份信息检测包括Android IDDRM IDDevice FingerprintSIM 卡状态地区语言ROM 版本系统版本安装应用列表4. 静态与动态检测静态检测软件环境硬件环境网络环境文件系统动态检测Runtime 环境内存扫描进程空间扫描动态代码检测Hook 检测注入检测三、Paytm 典型检测机制以 Paytm 为例目前最核心的两个检测方向包括A. 硬件 TEE 层检测主要依赖Google 硬件级 Key Attestation部分研究环境中会通过TrickyStore模拟旧设备环境。其核心思路是使用旧设备指纹 让 Google 认为 “当前设备属于不支持硬件 TEE 的旧机型”从而降低硬件级校验强度。B. 软件层完整性检测软件层通常涉及FingerprintBuild 信息系统属性ROM 环境部分研究环境会结合Play Integrity Fix修改设备指纹相关属性。四、历史版本中的典型案例在部分历史版本中曾出现服务端未严格校验 Integrity Token 的情况。例如在某些早期版本中请求 OTP 时即使缺失 Integrity Token服务端仍可能继续处理请求。其本质原因是服务端没有强制校验 Token 字段存在性。而在后续版本中相关校验逻辑已经逐步加强。五、常见研究工具链与组件在 Android 安全研究中通常会使用如下组件组合构建测试环境。1. KernelSU作用内核级 Root模块加载init_boot 镜像制作2. Magisk作用Android Root 框架Boot 镜像修改模块管理3. Zygisk作用注入 ZygoteRuntime HookMagisk 模块依赖环境4. Shamiko作用隐藏 Root 环境隐藏 Magisk隐藏 Zygisk 痕迹通常配合Zygisk 配置列表使用。5. LSPosed作用Android Hook 框架模块管理与启用Java 层 Hook6. HMAHide My Applist作用隐藏安装应用列表对指定 APP 隐藏 Root 工具例如对 Paytm 隐藏MT 管理器MagiskFrida 工具7. TrickyStore作用模拟旧设备环境影响硬件级完整性校验通常会配合keybox.xmlpif.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
