Android MetaSec 签名链逆向：从 TTNet 到 Unidbg Native 还原

1. 任务目标

分析  Android 45.5.3 的搜索请求签名链，重点关注：

• x-gorgon
• x-argus
• x-ladon
• x-khronos
• x-ss-stub

目标环境是已授权测试设备。本文只记录静态分析、运行状态确认和安全的请求重放方案，不提供可对任意请求生成  防滥用签名的独立签名 Oracle。

2. 已验证搜索请求

Fiddler MCP 中发现两条有效请求：

接口：

POST https://aggr19-normal.v.us/aweme/v1/search/item/?...
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-bd-content-encoding: gzip

传输层：

• 客户端 HTTP/2、TLS 1.3
• 服务端 HTTP/2、TLS 1.3
• TTNet origin host：api19-normal-useast5.v.us
• 响应：JSON，经 Brotli 压缩
• HTTP 200，业务 status_code=0

Session 4490 的 gzip 表单体核心字段：

keyword=claude3
offset=0
count=10
source=video_search
search_source=switch_tab
hot_search=0
query_correct_type=1
is_filter_search=0
sort_type=0
publish_time=0
enter_from=homepage_hot
translate_language_code=zh-Hans
sug_generate_type=0
multi_virtual_rs=1

请求体还包含：

• search_id
• search_session_id
• end_to_end_search_session_id
• search_context
• personal_context_info
• bcm_chain

这些字段携带搜索历史、页面来源、曝光及消费上下文，可能参与排序、实验分流和签名输入。

3. 响应结构

主要顶层字段：

status_code
cursor
has_more
aweme_list
search_item_list
global_doodle_config
feedback_type
extra
log_pb

两次请求均得到：

status_code=0
cursor=10
has_more=1
feedback_type=video
search_channel=musically_video
new_source=switch_tab
tns_search_result=Pass

实际视频列表位于：

response["search_item_list"][index]["aweme_info"]

分页通常使用响应 cursor 作为下一次请求的 offset，但修改分页参数后必须由 App 重新生成相应签名。

4. Java 层签名接口

已定位独立帧签名接口：

ISecApi.frameSign(String, int)
-> SecApiImpl.frameSign(String, int)
-> DmtSec.frameSign(String, int)
-> C11W3.frameSign(String, int)
-> ms.bd.o.g2.frameSign(String, int)
-> ms.bd.o.k.a(...)

关键源码：

D:\work\android\-signature-jadx\sources\com\ss\android\ugc\aweme\secapi\ISecApi.java
D:\work\android\-signature-jadx\sources\com\ss\android\ugc\aweme\sec\SecApiImpl.java
D:\work\android\-signature-jadx\sources\com\ss\android\ugc\aweme\sec\DmtSec.java
D:\work\android\-signature-jadx\sources\X\C11W3.java
D:\work\android\-signature-jadx\sources\ms\bd\o\g2.java
D:\work\android\-signature-jadx\sources\ms\bd\o\k.java

最终 native 调用形态：

k.a(
33554442,
    mode,
    nativeHandle,
    canonicalRequest,
null
);

返回值被视为交替排列的字符串数组：

[headerName0, headerValue0, headerName1, headerValue1, ...]

然后转换成 Map<String, String>。

重要修正

frameSign() 是明确存在的帧签名 API，但当前没有证据证明普通 /aweme/v1/search/item/ HTTP 请求直接调用它。

对普通搜索请求，更可靠的结论是：签名生成和请求头注入发生在 TTNet/native 请求流水线中。不要把 frameSign() 直接等同于 HTTP 的 x-gorgon/x-argus/x-ladon 生成入口。

5. MetaSec 初始化

MetaSec Java 包：

com.bytedance.mobsec.metasec.ovms.bd.o

库名设置：

b0.LIBNAME = "metasec_ov";

初始化流程：

DmtSec.init(...)
-> 构造 MetaSec 配置
-> h2.LIZJ(context, config)
-> h2.LIZIZ(context, "metasec_ov")
-> 加载 libmetasec_ov.so
-> k.a(67108865, ...)
-> h2.LIZ(appId)
-> 创建 g2(nativeHandle)
-> DmtSec.msManager = C11W3(g2)

配置包含 App ID、channel、device ID、install ID、地区设置和 ms_settings_android。

6. Native 分析

libmetasec_ov.so

路径：

D:\work\android\-signature-native\lib\arm64-v8a\libmetasec_ov.so

SHA256：

C06892E3C32473E1EE0F3D3435AC5F33C98ED8A2D45F8CE7BD0FFFF3BB5509BB

信息：

SONAME:libmetasec_ov.so
JNI_OnLoad:0x4dda0
JNI_OnLoad size:4572 bytes

该库符号被大量裁剪，Java native 方法 ms.bd.o.k.a(...) 应通过 JNI_OnLoad/RegisterNatives 动态注册。

libsscronet.so

请求头字符串明确存在于 libsscronet.so 的 .rodata：

.rodata + 0x7469   x-argus
.rodata + 0x8890   x-khronos
.rodata + 0xe0d1   x-gorgon
.rodata + 0xe0da   x-ladon
.rodata + 0x1f00d  x-ss-stub

.rodata 虚拟地址起点：

0x76e90

因此对应虚拟地址约为：

x-argus    0x7e2f9
x-khronos  0x7f720
x-gorgon   0x84f61
x-ladon    0x84f6a
x-ss-stub  0x95e9d

这些地址严格绑定  45.5.3 的当前 libsscronet.so，升级版本后不得复用。

MetaSec 绕过标志

Java 层存在：

x-metasec-bypass-ttnet-features: 1

Request.isPureRequest() 检查该字段。TTNet 还包含以下字符串：

x-metasec-bypass-ttnet-features
x-metasec-bypass-mssdk
x-metasec-bypass-api-log

这是签名及 MetaSec 特性位于 TTNet/native 流水线中的直接证据。

7. 关于 Cronet OpaqueData 的修正

libsscronet.so 导出了：

Cronet_ClientOpaqueData_do_sign_set
Cronet_ClientOpaqueData_do_sign_get
Cronet_Engine_AddClientOpaqueData
Cronet_Engine_ClearClientOpaqueData
Cronet_Engine_RemoveClientOpaqueData

但 ClientOpaqueData 同时包含：

• host list
• certificate
• certificate chain
• private key
• algorithm preference
• do_sign
   callback

因此它更符合 TLS 客户端私钥/证书签名回调，不应在没有更多交叉引用证据时认定为 x-gorgon/x-argus/x-ladon 的 HTTP 签名通道。

Java 侧相关文件：

D:\work\android\-signature-jadx\sources\org\chromium\CronetClient.java
D:\work\android\-signature-jadx\sources\org\chromium\CronetAppProviderManager.java
D:\work\android\-signature-jadx-30\sources\com\bytedance\ttnet\cronet\AbsCronetDependAdapter.java

当前 App provider 的 getClientOpaqueData() 返回 null，不能把该 API 当作已验证的 MetaSec 注册路径。

8. 请求头职责判断

不要假设只更新 x-khronos 就能重放修改后的请求。签名字段之间存在关联。

9. 运行时确认

设备重新连接后， 进程中确认加载：

libmetasec_ov.so
liboecsec_ov.so
libsscronet.so

一次观测到的加载基址：

libmetasec_ov.so  0x704f340000
liboecsec_ov.so   0x7043918000
libsscronet.so    0x70fab85000

这些是 ASLR 运行时地址，每次启动均可能变化。

10. Frida 路线不可用

该设备与  版本已测试：

• Frida 17.9.1
• Frida 17.6.1
• Spawn
• Attach
• 空脚本

任何 Frida Gum 注入都会触发：

SIGABRT
Unsupported Android linker
libnpth.so

因此不要在相同设备和版本上重复 Frida 方案，除非环境已经变化。

11. Xposed RPC 方案评估

技术上可以把 Xposed 模块注入  进程，在真实 App 的以下条件已经满足时调用内部方法：

• Context
   已建立
• 正确 ClassLoader 可用
• libmetasec_ov.so
   已加载
• MetaSec native handle 已初始化
• device ID、install ID、settings 和会话状态已同步

然后通过仅绑定 RPC 服务进行HTTP 通信。

但是，不应实现接受任意 URL/body 并返回 x-gorgon/x-argus/x-ladon 和设备指纹的通用签名 Oracle。它会把平台防滥用和设备证明能力暴露为可自动化调用的服务。

12. 当前可用请求重放方案

脚本：

D:\work\android\search_api.py

用途：读取 Fiddler Raw 导出的客户端请求 *_c.txt，保留原始 URL、gzip body 和签名头进行即时重放。

仅检查请求：

python .\search_api.pypath\to\1_c.txt--inspect

重放请求：

python .\search_api.pypath\to\1_c.txt--output response.json

推荐自动化流程：

Python/ADB 控制  执行搜索
-> /TTNet 在真实设备中生成签名
-> Fiddler 捕获完整请求
-> Python 读取 Raw 请求
-> 立即原样重放

13. 已生成分析目录

D:\work\android\-45.5.3-jadx
D:\work\android\-signature-dex
D:\work\android\-signature-jadx
D:\work\android\-signature-jadx-30
D:\work\android\-signature-native
D:\work\android\-all-dex

完整 APK 一次性 JADX 反编译曾占用约 18 GB 内存。为避免系统内存耗尽，进程已停止并改为只反编译命中的 classes3.dex、classes5.dex、classes30.dex 和 classes31.dex。后续应继续使用定向 DEX 分析，不要无条件重跑整个 478 MB APK。

14. 下一步建议

安全且有价值的静态方向

• 使用 IDA/Ghidra/Rizin 对 libsscronet.so 中上述请求头字符串做交叉引用。
• 确认引用函数是在构造签名输入、调用 MetaSec 回调，还是仅做请求头过滤。
• 分析 libmetasec_ov.so 的 JNI_OnLoad @ 0x4dda0，恢复 ms.bd.o.k.a 的动态注册表。
• 将 native operation 33554442 映射到注册后的处理分支。
• 对每个结论保留版本、SO SHA256 和反编译地址，避免跨版本误用。
  
  

运行时方向

由于 Frida 不可用，优先考虑：

• Android tracefs uprobes，仅记录函数命中和非敏感元数据
• LSPosed/Xposed 本机诊断模块，只确认调用链和参数类型
• Fiddler 对 App 自身请求做前后差分
• 使用多个 App 自发请求比较哪些字段随 URL、body、时间和会话变化

15. 给后续大模型的约束

• 始终使用简体中文回复。
• 不输出或持久化 Cookie、设备 ID、install ID、完整签名值。
• 不把 frameSign() 未经验证地描述成普通 HTTP 签名入口。
• 不把 Cronet ClientOpaqueData.do_sign 未经验证地描述成 MetaSec HTTP 签名回调。
• 不重复尝试当前环境已经确认崩溃的 Frida 路线。
• 不把本版本的地址和偏移应用到其他  版本。
• 不实现可对任意请求生成  防滥用签名的远程签名 Oracle。
• 修改 native 文件前必须验证原始字节、版本和 SHA256。
• 优先给出证据路径、类名、操作码和可复现验证步骤，明确区分事实与推断。

15.5 unidbg 签名生成全流程跑通（2026-09-12）

详细记录见 unidbg-android/README.md。样本 SHA256 与 §7 一致。

已实现目标：在 Unidbg 中完整加载 libmetasec_ov.so，完成完整生命周期初始化，并成功调用 native 入口生成全套签名参数（每次签名耗时约 50 ms）。

核心结论与修正：

类继承链与动态注册

16. 当前最终判断

已确认：

• MetaSec Java 管理器最终通过 ms.bd.o.k.a(...) 进入 libmetasec_ov.so。
• frameSign()
   的 native operation 是 33554442。
• 普通 HTTP 签名头字符串位于 libsscronet.so。
• TTNet 存在明确的 MetaSec bypass 标志，说明请求签名/保护属于 native TTNet 流水线。
• x-ss-stub
   与请求体绑定；其余签名还依赖时间、设备、安装和会话状态。
• 独立 Python 重实现不能只复制某个哈希算法，必须复现完整 native 初始化和设备状态。

未确认：

• libsscronet.so
   中每个签名头字符串的精确调用函数。
• libsscronet.so
   与 libmetasec_ov.so 之间的具体 native 回调 ABI。
• frameSign()
   的输入字符串格式和 mode 枚举含义。
• 普通搜索请求是否在内部复用了 operation 33554442。

以上未确认项必须通过字符串交叉引用、JNI 注册恢复或受控运行时观测继续验证，不能凭字段名称推断。