从 x-acf-sensor-data 到规模化：Frida 主动调用 + 云手机 / RK3588 redroid 方案实战

本文最后更新于：2026年7月20日中午

适用场景声明:本文面向授权范围内的安全研究、CTF、渗透测试与反爬对抗学习。请在合法授权前提下使用,遵守目标平台的服务条款与当地法律。

一、问题起点:x-acf-sensor-data 是什么

在 Lowe’s App 的请求包里能看到一个自定义请求头 x-acf-sensor-data,值是一长串编码字符串。它的本质是:

Akamai Bot Manager(Bot Defender)移动端 SDK 生成的设备指纹 + 行为传感器 + 环境完整性数据。

拆开看:

x-acf-...:acf 是 Lowe’s 自定义前缀(各家会改名,避免直接暴露 akamai / sensor_data),功能上等同 Akamai 官方 Android/iOS SDK 默认的 X-acf-sensor-data。
sensor-data:Akamai 的核心概念。Web 端这些数据 POST 到 /akam/.../pixel 或塞进 _abck cookie;App 端没有浏览器环境,native SDK 把采集到的数据编码后放进这个自定义头发出去。

里面装了什么

类别	内容
设备指纹	型号、OS 版本、屏幕分辨率、语言、时区、电量、内存
传感器	加速度计 / 陀螺仪 / 磁力计读数(真机才有真实抖动)
行为	触摸事件、按压坐标、滑动轨迹、页面停留时间
运行环境	root/越狱检测、hook 框架(Frida/Xposed)检测、模拟器检测、debug 检测
完整性	SDK 版本号、时间戳、服务端校验签名

服务端拿到后跑风控模型,判断是真人真机还是脚本/模拟器/篡改环境,决定放行、加验证码还是封禁。

逆向难点

采集逻辑在 native 层(.so / C++),不是纯 JS。
有强 反调试 / 反 hook / 完整性校验。
服务端校验时间戳新鲜度与行为合理性,重放很快失效(一次性 / 短时效)。

结论:纯静态还原算法成本极高。业界主流走 Frida 主动调用 + 真实/仿真设备——不还原算法,而是让 App 里的 SDK 帮你生成。

二、核心思路:Frida 主动调用(不还原算法)

让 App 里的 SDK 帮你生成 sensor-data,你只负责”喂参数、取结果”,并包装成 HTTP 服务对外提供。

整体架构

你的爬虫/协议端
      │  HTTP: POST /gen  { url, cookies, ... }
      ▼
┌─────────────────────────┐
│  调度层 (自建 Server)     │  负载均衡 / 设备池管理 / 保活
└─────────────────────────┘
      │  RPC (frida rpc.exports)
      ▼
┌─────────────────────────┐
│  设备池 x N              │
│   ├ Lowe's App (已装)     │
│   ├ frida-server (root)   │
│   └ 你的 agent.js 注入    │
└─────────────────────────┘
      │  主动调用 SDK 生成函数
      ▼
   返回 x-acf-sensor-data 字符串

第一步:定位 SDK 生成函数

Akamai 移动 SDK 最典型的入口是 com.akamai.botman.CYFMonitor,里面有静态方法 getSensorData() 直接返回字符串。

先枚举可疑类:

Java.perform(function () {
    Java.enumerateLoadedClasses({
        onMatch: function (name) {
            if (name.toLowerCase().indexOf('akam') !== -1 ||
                name.indexOf('botman') !== -1 ||
                name.indexOf('CYFMonitor') !== -1) {
                console.log(name);
            }
        },
        onComplete: function () {}
    });
});

Hook 先观察行为,确认返回值就是请求头里那段:

Java.perform(function () {
    var CYF = Java.use('com.akamai.botman.CYFMonitor');
    CYF.getSensorData.implementation = function () {
        var ret = this.getSensorData();
        console.log('[sensor-data] ' + ret);
        return ret;
    };
});

如果被藏在 native .so,用 IDA/Ghidra 定位导出符号,再用 Interceptor / NativeFunction 调用。

第二步:改为主动调用(RPC exports)

Hook 是被动等 App 触发;主动调用是想要就调,不走完整交互。

// agent.js
rpc.exports = {
    genSensor: function () {
        return new Promise(function (resolve) {
            Java.perform(function () {
                try {
                    var CYF = Java.use('com.akamai.botman.CYFMonitor');
                    var ActivityThread = Java.use('android.app.ActivityThread');
                    var ctx = ActivityThread.currentApplication().getApplicationContext();
                    CYF.initialize(ctx);          // 视 SDK 版本而定
                    var data = CYF.getSensorData();
                    resolve(data);
                } catch (e) {
                    resolve('ERR: ' + e);
                }
            });
        });
    }
};

Python 侧驱动:

import frida

device = frida.get_device_manager().add_remote_device('设备IP:27042')
session = device.attach('com.lowes.android')   # 或 spawn
script = session.create_script(open('agent.js').read())
script.load()
sensor = script.exports_sync.gen_sensor()
print(sensor)

包成 Flask/FastAPI 接口,爬虫端每次发请求前调一次拿新 token。

三、设备底座三方案对比

Frida 链路三种方案通用,区别在跑在什么设备上。这直接决定 sensor-data 能不能过 Akamai 风控。

维度	本地真机农场	云手机平台	RK3588 + redroid
反检测(过 Akamai)	★★★★★ 最强,真传感器	★★★☆☆ 看平台,部分 ARM 云虚拟化有特征	★★☆☆☆ 裸装弱,需重补环境
成本	高(硬件+电+维护)	中(按量/包月)	低(一次性硬件)
密度/并发	低(一机一实例)	高(平台弹性)	中(单板 3-5 容器)
维护复杂度	高(USB农场/OpenSTF)	低(免运维)	中(内核+Docker)
可控性	高	低(受平台限制)	高(完全自控)
root/frida	需自行 root	部分平台禁止	默认 root,自由

什么时候选哪个

要极致过检、量不大 → 本地真机。真传感器 + 真硬件,Akamai 最难识别。
要快速起量、免运维 → 云手机平台(腾讯 WeTest / 华为云 CloudPhone / Genymotion Cloud / 国内云手机)。注意选真机型云手机而非纯模拟器。
要长期自控、控成本、有折腾能力 → RK3588 + redroid。本文重点。

为什么不用 x86 模拟器

Akamai SDK 会检 QEMU 特征、传感器全 0、ro.hardware=goldfish。x86 模拟器跑 ARM App 还要 houdini 翻译层,又多一层特征。RK3588 是 ARM 原生,不需要翻译,native .so 原速运行,天然干净一截。

四、RK3588(Orange Pi 5 Plus)落地详解

Orange Pi 5 Plus 是 RK3588 官方验证过的板子,内核那关基本免踩坑。使用 CNflysky/redroid-rk3588。

这个镜像直接给你的东西

LineageOS 20(真 ROM 的 build.prop,比裸 AOSP 像真机)
Magisk(Kitsune 分支) 内置 → 能装 Zygisk 模块、丢 frida-server
GApps 内置 → 过 Play Integrity 的前提
Mali-G610 GPU 硬件加速 → 真 Mali GPU 指纹,不是软渲染
surfaceflinger 去 FLAG_SECURE、假 WiFi、scrcpy 键鼠

对打 Akamai 而言:真 Mali GPU + LineageOS 真 ROM prop,起点已比普通 redroid 干净。

第一道坎:内核

唯一容易卡死的地方。Orange Pi 5 Plus 需要:

Armbian vendor 内核(RK35xx),不能用 mainline
开 CONFIG_ANDROID_BINDERFS=y、CONFIG_PSI=y
/lib/firmware/ 里有 Mali CSF GPU 驱动和固件
DMA-BUF 支持
宿主系统:Debian 12/13 或 Ubuntu 22.04,Docker 20.10.24+

起容器

git clone https://github.com/CNflysky/redroid-rk3588.git --depth 1
cd redroid-rk3588
docker compose up -d

# 或手动:
docker run -d -p 5555:5555 -v ~/redroid-data:/data \
  --restart unless-stopped --name redroid --privileged \
  cnflysky/redroid-rk3588:lineage-20

起来之后的工作流

1. adb connect localhost:5555 && adb root
2. 推 frida-server-arm64(改名改端口,躲 Akamai 反 frida 检测)
3. 装 Lowe's App
4. frida attach → rpc.exports.genSensor() 拿 x-acf-sensor-data
5. 拼真实业务请求打回去,看返回 / _abck 有没有失败标记(~-1~)

先跑这个最小验证,再补环境。 别一上来堆模块。

密度

Orange Pi 5 Plus(8 核 + 最高 16/32G 内存)一般能稳跑 3-5 个容器并发,每个独立 Magisk/frida。改 --name、-p 端口、-v 数据目录区分。别拉满——Akamai 会关联同板高频 token,需设备轮换 + 限速。

五、过检环境补全(被拦时按优先级补)

裸 redroid 出的 sensor-data 大概率被判高风险(_abck 带 ~-1~)。按下表优先级补:

优先级	补什么	用什么	备注
1	过 Play Integrity	KOWX712/PlayIntegrityFix / osm0sis/PlayIntegrityFork(Zygisk)	Magisk 已内置
2	隐藏 root/frida	Shamiko + Zygisk DenyList	把 Lowe’s 加进 DenyList
3	一机一指纹	DeviceSpoofLab-Magisk	改 serial/AndroidID/MAC
4	传感器(最难)	无现成开源,自己 hook `SensorManager`/HAL	redroid 打 Akamai 的真正分水岭

关键提醒

Play Integrity 通过 ≠ Akamai 通过。 PIF 只改给 Google DroidGuard 看的 props,Akamai native SDK 是独立采集,尤其传感器它不管。
最大开源空白 = 传感器伪造。 redroid 没物理加速度计/陀螺仪,sensor-data 里行为数据全 0。没有成熟开源项目帮你造合理传感器抖动流,得自己 hook SensorManager/HAL 造数据。前 3 项是”别露馅”,第 4 项是”要像真人”。
redroid 装 PIF 有坑:装完 SafetyNetFix/PIF 后重启可能导致容器 unauthorized(adb 掉线),参考 redroid-script Issue #49。

反向自检

用 happylishang/AntiFakerAndroidChecker 站在风控视角检自己:IMEI/AndroidId/序列号/MAC 拿不拿得到、模拟器特征暴不暴露。补完环境先自检再上量。

六、验证闭环

拿到 token 别急着上量,先验证:

用生成的 x-acf-sensor-data 拼真实业务请求(商品详情 / 加购)。
看返回是不是正常数据,而非 _abck 里出现 ~-1~ 之类失败标记(Akamai 失败态特征)。
对比一台真机跑同样流程的返回,直观看差距在哪。
观察连续 N 次成功率和封禁曲线,调设备轮换 / 限速。

七、时效性与工程注意

sensor-data 带时间戳,必须现取现用,不能缓存重放。
部分版本 getSensorData 输出要和请求的 cookie(_abck/bm_sz)、URL 路径匹配,需把这些作为 RPC 参数传进去,否则服务端交叉校验失败。
App 重打包(塞 gadget)会触发签名完整性校验 → 优先走 root + frida-server 不改包 路线(redroid 默认 root,天然适配)。

八、总结

阶段	做什么
认清目标	`x-acf-sensor-data` = Akamai 移动端加密上报,含设备指纹+行为+环境完整性
选技术路线	不还原算法,Frida 主动调用 `CYFMonitor.getSensorData()`,包成 HTTP 服务
选设备底座	极致过检→真机;快速起量→云手机;自控控成本→RK3588 redroid
RK3588 落地	Orange Pi 5 Plus + CNflysky/redroid-rk3588,LineageOS 20 + Magisk + 真 Mali GPU
过检补全	Play Integrity → 隐藏 root/frida → 一机一指纹 → 传感器伪造(核心难点)
验证	现取现用,打真实请求看 `_abck` 是否失败标记,对比真机

一句话: RK3588 redroid 是”高性价比自控设备池”,技术链路能通;真正的工作量不在生成 token,而在把容器伪装得足够像真机——尤其是传感器数据这块开源空白,决定成败。

参考仓库

CNflysky/redroid-rk3588 —— RK3588 专用 redroid 镜像
ayasa520/redroid-script / abing7k/redroid-script —— 给 redroid 加 Magisk/GApps/libndk
remote-android/redroid-doc / redroid-modules —— 官方文档与内核模块
KOWX712/PlayIntegrityFix / osm0sis/PlayIntegrityFork —— 过 Play Integrity
yubunus/DeviceSpoofLab-Magisk —— build.prop / 指纹伪装
happylishang/AntiFakerAndroidChecker —— 反向自检

逆向 > 移动端逆向

#逆向 #Akamai #Frida #redroid #RK3588 #移动端逆向 #反爬

从 x-acf-sensor-data 到规模化：Frida 主动调用 + 云手机 / RK3588 redroid 方案实战

https://kingjem.github.io/2026/07/20/Akamai移动端sensor-data-Frida主动调用-redroid-RK3588方案/

作者

Ruhai

发布于

2026年7月20日

许可协议

Mac 48GB 统一内存本地模型运行指南上一篇

Win11 一键去广告瘦身：Win11Debloat 与那行 irm 命令下一篇