小米澎湃 HyperOS3.0 内置反诈组件逆向分析 • ChrisLi-Tech

实验环境：红米K90至尊版 HyperOS Ver. 3.0.306

摘要：在手机管家明确拒绝隐私政策的前提下，基于手机管家实现的相关反诈组件仍然在积极收集用户的隐私信息，包含但不限于：屏幕截图、屏幕录制、软件安装列表、境外通话，并在用户不知情的情况下疑似将处理后的信息提供给第三方商业APP, 目前用户无法手动控制关闭。

本次测试分析了 APK 静态代码、Android 服务运行状态、以及反诈实现相关 SQLite 记录和截图文件时间一一对应。在测试时也能稳定复现与动作时间完全相符的数据库写入。

后续检查第三方 App 有没有接入 XSOF。发现：小红书 9.49.2 的运行进程确实成功绑定了小米的 MiSafetyDetectService。 以及百度系，阿里系部分与支付完全无关的app也在尝试申请这一权限

测试对象为国行设备，代号 warsaw，ro.mi.os.version.name = OS3.0。手机管家包名 com.miui.securitycenter，实测安装版本 12.7.9-260811.0.1。测试使用临时 KernelSU Root，id 返回 uid=0(root)，SELinux 仍为 Enforcing。所有对原系统的检查均为读取、查询或复制文件，没有手动修改原始数据库，也没有禁用手机管家。

开始通过 dumpsys package 找到了以下组件：

com.xiaomi.security.xsof.MiSafetyDetectService
com.xiaomi.security.xsof.frauddetection.service.MiFraudDetectionService

继续看 dumpsys activity services，发现 MiFraudDetectionService 不只写在 Manifest 里当摆设，已经真实启动了。它运行于 UID 1000 的 com.miui.securitycenter.remote 进程中，同时 FraudDetectionProvider 和 XSOFProvider 也已实例化。

/data/misc/user/0/securitycenter/fraud_detection_data.db

它是一个真实存在、最近更新过的 SQLite 数据库。用只读方式查看，能看到 screenshot、screen_share、install_app、fraud_phone、fraud_url、voip_record 等表。

对手机管家的 APK 做静态分析，发现以下内容：

CREATE TABLE screenshot(
  _id INTEGER PRIMARY KEY AUTOINCREMENT,
  screenshort_time INTEGER NOT NULL
);

相关代码会监听 miui.intent.TAKE_SCREENSHOT，收到截图事件后生成时间戳，并走进 screenshot 表的写入逻辑。至于是不是真的写了，直接查数据库就行。

执行：

SQL=/data/data/com.termux/files/usr/bin/sqlite3
DB=/data/misc/user/0/securitycenter/fraud_detection_data.db
"$SQL" -readonly "$DB" 'SELECT COUNT(*) FROM screenshot;'

第一次得到 94，正常截了一张图之后再查，是 95。

再取出最后几条记录：

SELECT datetime(screenshort_time/1000,'unixepoch','localtime')
FROM screenshot
ORDER BY screenshort_time DESC
LIMIT 10;

得到的时间包括：

2026-10-13 16:12:13
2026-10-13 16:53:39
2026-10-13 16:56:44
2026-10-13 16:57:05
2026-10-13 16:57:25
2026-10-13 16:58:12

16:12:13 是此前保存的一张 B 站截图，截图文件名就是 Screenshot_2026-10-13-16-12-13-504_...jpg；16:57:05 也与查询过程中的截图文件时间对应。这套服务不是只在打开手机管家页面时才记录截图，普通应用里的截图照样会进入数据库。

测试设备的所有者确认，手机管家的隐私政策同意在当天实验前已经撤回。17:50 再打开手机管家，仍然会弹出完整的同意页面，底部明确是“不同意 / 同意”。点“不同意”会退出页面。页面介绍里还明确把“系统安全组件、安全服务、系统服务组件、Joyose、垃圾清理”归入手机管家的范围。

在这个页面上截图，原始文件时间是 2026-10-13 17:50:23 。随后回到 Termux 再查数据库，里面同样也有：

2026-10-13 17:50:23

手机管家正在要求同意隐私协议；同一时间，它的后台反诈记录机制把这张截图的时间也记了下来。

截图和数据库能证实当前待同意界面存在，而后台截图记录继续运行，也就是说，当前手机管家的前台同意状态并没有阻止后台的截图时间采集。

这套组件属于小米 XSOF 涉诈检测框架，小米开发者网站公开提供了相关 SDK 文档：

业务介绍：https://dev.mi.com/xiaomihyperos/documentation/detail?pId=2243
接入指南：https://dev.mi.com/xiaomihyperos/documentation/detail?pId=2255

官方资料描述，经过授权的合作应用可以查询近一段时间的涉诈风险行为摘要，包括是否截图、是否屏幕共享、是否安装过特定类型的风险应用等，部分查询使用最长 72 小时 的时间窗口。APK 查询和清理代码中也可以找到 259200000 毫秒这一阈值。

另一轮 APK Manifest 检查中确认，这台 HyperOS 3.0 上的 XSOF 声明了 com.xiaomi.security.xsof.service.version=3。

com.xiaomi.security.permission.ACCESS_XSOF
protectionLevel=normal

normal 是 Android 普通权限，安装应用时可以自动授予，不会像相机、麦克风那样单独弹出需要用户手动点击同意的授权窗口。在本次检测中的17 个相关包名中，有 16 个非手机管家包显示 ACCESS_XSOF 已由 Android 授予，包含小红书、贴吧、抖音、支付宝、淘宝、闲鱼、京东、高德等；另一个是定义这项权限的手机管家本身。16 个包既包括第三方 App，也包括小米自家应用。

其中百度贴吧额外做了单包核验，确实看到 requested permissions 中声明权限，并且 install permissions 下显示 granted=true。首次检查贴吧时它还是 stopped=true、notLaunched=true；不过后续批量检查已经变为 false/false。

但另一条调查线索向前推进了一步：小红书进程实际绑定上了 XSOF 服务。

测试过程中运行了小红书 com.xingin.xhs，版本为 9.49.2。Android 的 dumpsys activity services 中，出现了以下服务连接记录（此处截取关键字段，省略进程对象地址）：

ServiceRecord{... MiSafetyDetectService c:com.xingin.xhs}
intent={act=com.xiaomi.security.xsof.SAFETY_DETECT_SERVICE
        pkg=com.miui.securitycenter}
recentCallingPackage=com.xingin.xhs
recentCallingUid=10350
isBindService=true
Bindings:
  IntentBindRecord{... CREATE}
    requested=true received=true hasBound=true doRebind=false
    Client AppBindRecord{... ProcessRecord{... com.xingin.xhs/u0a350}}

这就不是在 Manifest 里写一个权限占位了。received=true 和 hasBound=true 表明，小红书进程确实拿到了该服务连接的 Binder。这是实际运行状态，并非静态信息。

但问题来了：连上服务之后，它到底调用了什么？

XSOF 的 SDK 实现中，004_2 对应过去行为查询（包含截图历史这一类信号），004_3 对应行为持续时长，004_4 对应风险评分。光看 Binder 绑定记录，根本看不出小红书有没有调用这些方法，更看不到鉴权成功返回了什么数据。

另一条调查分支还检查了小红书 base.apk 的 21 个主 DEX、两个附带 DEX 文件和 ARM64 分包里的 164 个原生库，没有找到上述 XSOF 接口名称的直接明文引用。于是出现一个有意思的现象：静态字符串没命中，真机绑定却发生了。 这可能涉及混淆、动态加载、运行时拼接或其他间接调用，但目前不能确认具体原因。

同apk还能看到 XSOF 的一部分处理过程会经过 com.xiaomi.trustservice，再调用 vendor.xiaomi.hardware.mrm。相关原生库里能找到设备可信状态、Verified Boot、传统 Root 痕迹和 SELinux 状态检查，以及调用高通 QSEE/TEE 的代码路径。XSOF 也有远程应用鉴权和 OneTrack 统计埋点。

另外，官方新版涉诈检测 API 的公开适用说明以中国大陆 HyperOS 3.1 及以上为主，而本机跑的是 HyperOS 3.0。这台设备确实已经在本地记截图时间。

所以争议其实很简单：反诈骗有没有必要？当然有。但为了反诈骗，普通用户什么时候截图为什么需要默认记录？这些记录为什么要提供一套可供商业合作方申请调用的摘要接口？为什么用户已经拒绝当前手机管家协议，后台相关记录仍然继续？这套处理依据哪份具体的隐私告知，用户能不能单独关闭？

就算数据完全留在本地，也不等于隐私问题不存在。只要获批第三方能够通过本机接口获得行为摘要，再由第三方自己处理和传输，那么是否存在“原始数据库上传到小米服务器”也不是唯一需要回答的问题。

希望有更多用户拿不同机型、不同固件复现。如果厂商认为这是必须运行、不能关闭的安全功能，就应该明确解释其数据范围、处理依据和用户控制方式。

反诈骗不应成为不解释数据收集边界的万能理由。