fbdata
HomeCartOrder QueryArticlesAPI Docs

返回文章
2026年7月22日/逆向分析

Facebook设备完整性链路分析

Facebook设备完整性链路分析

设备完整性链路

结论先说

这条链不是一个独立 API，而是 Tigon 发请求前自动补上的完整性头。

在 round2 里能看到：

  • request-builder-leave 时，TigonRequest 里还看不到它
  • 到 callback-enter onStarted 时，headers 里已经出现 X-FB-Integrity-Machine-Id

这说明它更像是发送前注入，不是业务层手工拼到每个请求里的。

证据

主要看这几个位置：

  • round2-dual-route-events-1783692914.jsonl
  • X_FB_INTEGRITY_DISCOVERY.md
  • X_FB_INTEGRITY_MACHINE_ID_ACTUAL_DATA.md

它怎么请求

它本身不单独发请求。

实际形态是：

  1. 业务先构造普通 TigonRequest
  2. 进入 TigonHttpClientAdapterImpl.executeAsync
  3. 发送前由框架层补上完整性头
  4. 真正发出去的是原业务请求，只是多带了这个头

典型请求类型在 round2 里有：

  • IMAGE / PREFETCH
  • GRAPHQL
  • OTHER

比如：

  • https://static-hkg1-2.xx.fbcdn.net/...webp
  • https://rupload.facebook.com/service_menu_uploads/...
  • https://b-graph.facebook.com?...

带了什么参数

最核心的是：

X-FB-Integrity-Machine-Id: gf5QakE6ik837QH7a1OV2xLw

同时常见还会有：

  • x-fb-sim-hni
  • x-fb-net-hni
  • x-fb-rmd
  • X-FB-HTTP-Engine
  • X-FB-Connection-Type
  • Priority
  • User-Agent
  • 有些请求还有 X-ZERO-EH

注意：真正的业务参数不在这个完整性头里，而是在原请求自己的 URL / body / multipart 里。

它怎么构造

从日志看，构造分两层：

1. 业务请求层

业务层先生成普通 TigonRequest，里面有：

  • method
  • url
  • category
  • body / buffers
  • 基础 headers

2. 框架注入层

在发送前，Tigon 相关链路把 X-FB-Integrity-Machine-Id 塞进 headers。

这点的关键证据是：

  • builder 结束时还没看到这个头
  • onStarted 时已经看到了

所以它不是每个业务点自己拼的，更像是统一注入。

这个值从哪来

当前日志里能确认的是：

  • 值稳定，反复出现
  • 24 个字符左右
  • 在同一会话里多次复用

更像是本地缓存值，大概率和 auth/auth_machine_id 这类本地存储有关。

但要严谨一点说：

  • 这两份 hook 没有直接打出读取点
  • 所以“具体是 SharedPreferences 还是别的缓存层”仍是推断

请求后得到什么

请求返回的是原业务请求的响应，不是完整性头的独立回包。

回包会先进入：

  • TigonHttpClientAdapter.Callback.onResponse
  • onBody
  • onEOM

然后再回到原来的发起方。

所以这里的传递关系是：

flowchart LR
  A[业务层构造 TigonRequest] --> B[Tigon发送前注入完整性头]
  B --> C[服务端收到请求并做完整性校验]
  C --> D[普通HTTP响应]
  D --> E[onResponse/onBody/onEOM]
  E --> F[原始业务调用方 / callback / prefetch逻辑]

它传递给谁

分两边看：

发出去以后

X-FB-Integrity-Machine-Id 传给服务端，用于完整性/设备标识校验。

回来以后

回的是原请求的响应，传回：

  • TigonHttpClientAdapter.Callback
  • 再到具体业务调用方

在 round2 里能看到的就是：

  • 图片预取请求收到 200
  • onBody 拿到 WEBP / 二进制内容
  • 然后继续交给原来的预取链路

一句话总结

这条链的本质是：

普通业务请求 + 框架自动注入的设备完整性头 + 服务端校验 + 原请求响应回流到原调用方

不是单独打一条“完整性 API”。