arjun1194/google-meet-protocol
GitHub: arjun1194/google-meet-protocol
一份通过插桩真实 Chrome 客户端逆向重构的 Google Meet 线路协议观测规范文档，涵盖传输、认证、加入序列、媒体协商和数据通道等全部细节。
Stars: 0 | Forks: 0
# Google Meet 协议
**一份关于 Google Meet 客户端如何与 Google 通信的观测规范。**
Google 并未公开任何相关内容。这里的所有内容都是通过对真实的 Chrome 客户端进行插桩、解码其发送的数据，然后从零开始重构每条消息，直到 Google 接受它而恢复出来的。如果某个声明是由从零开始的客户端重现的，文档中会明确指出。如果仅仅是观测到的，文档也会如实说明。
本仓库**仅包含信息** —— 没有客户端，没有机器人，也没有凭证。它的存在是为了让某人能够构建出这些东西。
## 一图看懂全貌
```
flowchart TB
subgraph BOOT["① Bootstrap — a browser, once per meeting"]
PAGE["GET meet.google.com/<code>
~2.3 MB of HTML"] PAGE --> SPACE["space id · spaces/<id>"] PAGE --> TOK["meeting token · epoch;opaque"] PAGE --> DBG["debug id"] end subgraph CTRL["② Control plane — gRPC-Web over plain HTTPS POST"] direction LR SYNC["SyncMeetingSpaceCollections
state + 20s long-poll"] UMD["UpdateMeetingDevice
device state, field-masked"] CMS["CreateMediaSession
DTLS · ICE · codecs · channels"] ISC["IssueIceServerConfig
STUN / TURN"] end subgraph MEDIA["③ Media plane — one bundled DTLS transport"] direction LR SCTP["SCTP
19 data channels"] SRTP["SRTP
one track per participant"] end subgraph CHAN["④ The channels that matter"] direction LR MD["media-director
ask for streams"] DCRPC["dcrpc
SSRC → device"] COLL["collections
roster · chat · hands"] MSG["meet_messages
send chat"] end SPACE --> CTRL TOK --> CTRL DBG --> CMS CMS --> MEDIA SCTP --> CHAN MD -.->|"allocation"| SRTP DCRPC -.->|"attribution"| SRTP style BOOT fill:#fff4e5,stroke:#e6a23c style CTRL fill:#e8f4fd,stroke:#409eff style MEDIA fill:#eaf6ec,stroke:#67c23a style CHAN fill:#f4ecf7,stroke:#9b59b6 ``` **这可以看作是四个事实。** 浏览器只需要使用一次，用于获取三个字符串。控制平面是四次普通的 HTTPS 调用，而不是 WebSocket。媒体平面是教科书般的 WebRTC。而所有有趣的事情 —— 谁在说话、他们叫什么、允许你接收什么 —— 都发生在该 WebRTC 会话*内部*的 data channel 上，而不是在 HTTP API 中。 ## 从这里开始 | 如果你想…… | 请阅读 | | --- | --- | | 在了解细节前先看整体轮廓 | [概览](docs/00-orientation.md) | | 发送你的第一个字节 | [传输层](docs/01-transport.md) → [身份验证](docs/02-authentication.md) | | 加入会议 | [加入序列](docs/03-join-sequence.md) | | 协商媒体 | [逐字段解析 CreateMediaSession](docs/05-create-media-session.md) | | 真正接收音频或视频 | [media-director](docs/07-media-director.md) + [dcrpc](docs/08-dcrpc.md) | | 知道谁在说话 | [dcrpc](docs/08-dcrpc.md) | | 读取聊天、名单、举手 | [集合与操作](docs/09-collections-and-actions.md) | | 了解到底能做什么 | [能力](docs/11-capabilities.md) | | 避免浪费一周时间 | **[失败模式](docs/12-failure-modes.md)** | ### 完整目录 **协议** - [00 · 概览](docs/00-orientation.md) —— 心智模型，以及四个让所有人都感到惊讶的点 - [01 · 传输层](docs/01-transport.md) —— gRPC-Web，以及为什么两个方向使用不同的编码 - [02 · 身份验证](docs/02-authentication.md) —— SAPISIDHASH，以及两个 token 缓存 - [03 · 加入序列](docs/03-join-sequence.md) —— 引导 → 同步 → 设备 → 媒体 - [04 · RPC 目录](docs/04-rpc-catalogue.md) —— 观测到的每一个服务和方法 - [05 · CreateMediaSession](docs/05-create-media-session.md) —— 逐字段解析 2.9 KB 的消息 - [06 · Data channel](docs/06-data-channels.md) —— 十九个预协商通道，无 DCEP - [07 · media-director](docs/07-media-director.md) —— 你如何请求发送任何内容 - [08 · dcrpc](docs/08-dcrpc.md) —— 顺序 RPC，以及 SSRC 到参与者的归属映射 - [09 · 集合与操作](docs/09-collections-and-actions.md) —— 资源模型、聊天、静音、举手 - [10 · 媒体平面](docs/10-media-plane.md) —— 从未跨越网络传输的 SDP、编解码器、RTP **实践** - [11 · 能力](docs/11-capabilities.md) —— 客户端能获取和做的事情，附带置信度 - [12 · 失败模式](docs/12-failure-modes.md) —— 针对发现的每个陷阱，提供 症状 → 原因 → 修复 - [13 · 捕获方法](docs/13-capture-methodology.md) —— 如何重现和重新验证所有内容 - [14 · 未解之谜](docs/14-open-questions.md) —— 目前仍未知的内容，以及如何攻克它 **参考表** - [标头](reference/headers.md) · [编解码器](reference/codecs.md) · [RTP 标头扩展](reference/rtp-header-extensions.md) - [Data channel](reference/data-channels.md) · [字段映射](reference/field-maps.md) · [网络抓包样本](reference/wire-samples.md) - [meet.proto](reference/meet.proto) —— 尽力而为重构出的 schema - [图表索引](diagrams/README.md) —— 每一张图表，均提供可复用的 Mermaid 源码 **交互式内容** - **[协议地图 ↗](https://arjun1194.github.io/google-meet-protocol/)** —— 一个独立的页面，包含可点击的分层模型、九步加入流程演练、针对四个捕获数据帧的**字节级浏览器**，以及可搜索的症状→原因查询表。源码：[site/index.html](site/index.html)。 ## 如何阅读证据标记 每一个不明显的声明都带有标记。它们不是装饰：这是一个逆向工程得出的协议，*“服务器接受了这个”*与*“这在抓包中看起来是对的”*之间的区别，意味着耗费一个下午还是整整一周时间的差异。 | 标记 | 含义 | | --- | --- | | ✅ **已证实** | 从零开始的客户端发送或解析了此内容，且服务器行为符合描述。可重现。 | | 👁 **观测到** | 在真实客户端的抓包中见过。未经独立重现。 | | 🧩 **推断** | 与证据以及协议其他部分的行为一致。但未作演示。 | | ❓ **未知** | 在此指出以揭示空白。请不要基于此进行构建。 | 一个关于这为何重要的具体例子，来自[失败模式](docs/12-failure-modes.md)：会议 token 曾连续几周被记录为*浏览器生成的证明*。这是 🧩 推断出来的，依据是它以 `ADmEuv` 开头且未联系任何证明端点。实际上它是服务器签发的，并且存在于一个响应标头中。试图伪造这样一个 token 而耗费的每一个小时，都花在了一个披着事实外衣的推断上。 ## 最耗费时间的五件事 首先写这一部分，因为本仓库的其余所有内容都是它们的下游。 1. **有两个会议 token 缓存，而不是一个。** 状态调用会根据响应标头轮换其 token；而媒体调用则永远保留初始引导值。将它们合并会被拒绝并返回 `400 invalid argument` —— 这与用于格式错误正文的措辞相同。 → [身份验证](docs/02-authentication.md) 2. **已连接的会话不携带任何内容。** ICE 到达 `connected`，DTLS 完成，但在你于 `media-director` data channel 上发送配置帧之前，不会有任何媒体到达。也没有任何报错。 → [media-director](docs/07-media-director.md) 3. **Meet 的 data channel 是预协商的，它从不发送 DCEP open。** 它在 `CreateMediaSession` 响应中为每个通道分配一个 SCTP 流 ID，然后直接向其写入二进制数据。一个等待被告知通道信息的客户端永远也等不到。 → [Data channel](docs/06-data-channels.md) 4. **流分配中的 SSRC 是 `fixed32`，而不是 varint** —— 这是整个协议中唯一的一个。如果将其作为 varint 读取，会得到一个看似合理但不匹配任何到达数据包的数字，导致会话看起来悄无声息地空无一物。 → [media-director](docs/07-media-director.md) 5. **请求是 gzip 压缩的；响应是 base64 编码的。** 这种不对称是真实存在的。捕获到的响应完全是可打印的 ASCII 字符，并且在解码一次之前看起来完全不像 protobuf。 → [传输层](docs/01-transport.md) ## 仍然缺失的内容 本文档的诚实边界，各用一句话概括。详细信息和攻击计划见[未解之谜](docs/14-open-questions.md)。 | 空白 | 后果 | | --- | --- | | 获取 Space ID 需要完整的浏览器指纹 | 每次会议仍需使用一次浏览器 | | 会议 token 的生成算法是不透明的 | 它只能被借用，永远无法被生成 | | `dcrpc` 流的**注册**已解码但未经证实 | 分配可能不遵循该握手流程 | | 字幕通道存在，但从未在抓包中携带文本 | 转录仍需语音引擎支持 | | 主持人专属控制项尚未映射 | 需要一个由测试账户拥有的会议 | ## 法律与道德立场 在使用其中的任何内容之前，请阅读此内容。 - 将 Google Meet 自动化**违反了 Google 的服务条款**。运行自动化程序的账号会被标记并禁用。请使用你能够承受损失的账号。 - 这是一份观测协议的文档，是通过观察作者运行的客户端、以及作者作为参与者参加的会议的进出流量而生成的。这里没有复制任何 Google 代码，这里的任何内容也没有绕过任何访问控制：所描述的每一个字节都需要一个已登录且已被准入会议的账号。 - 录制、转录或存储会议的音频、视频、聊天或参会者名单在大多数司法管辖区都受到监管，并且需要获得参会者的同意。你是否拥有这种同意是你自己的问题，而不是协议的问题。 - **如果你想要一个受官方支持的途径，请使用官方的 [Google Meet Media API](https://developers.google.com/meet/media-api)。** 它在不会导致你被封号的条款下，公开了一个刻意设计得非常相似的形态 —— 三个音频流、按参与者分离。当官方 API 不能覆盖你的使用场景时，本仓库非常有用；但这并不代表建议你避开官方 API。 ## 贡献 欢迎提供发现，尤其是纠正。在 [CONTRIBUTING.md](CONTRIBUTING.md) 中有一条规定：**每个声明都必须带有其证据标记，并且在未说明你运行了什么的情况下，不得将推断提升为事实。** 本文档历史上的几个结论曾连续几周被坚定地认为是错误的。这些标记使得这种情况得以被纠正。 ## 许可证 [CC BY 4.0](LICENSE)。使用它，在它的基础上构建，并注明出处。
~2.3 MB of HTML"] PAGE --> SPACE["space id · spaces/<id>"] PAGE --> TOK["meeting token · epoch;opaque"] PAGE --> DBG["debug id"] end subgraph CTRL["② Control plane — gRPC-Web over plain HTTPS POST"] direction LR SYNC["SyncMeetingSpaceCollections
state + 20s long-poll"] UMD["UpdateMeetingDevice
device state, field-masked"] CMS["CreateMediaSession
DTLS · ICE · codecs · channels"] ISC["IssueIceServerConfig
STUN / TURN"] end subgraph MEDIA["③ Media plane — one bundled DTLS transport"] direction LR SCTP["SCTP
19 data channels"] SRTP["SRTP
one track per participant"] end subgraph CHAN["④ The channels that matter"] direction LR MD["media-director
ask for streams"] DCRPC["dcrpc
SSRC → device"] COLL["collections
roster · chat · hands"] MSG["meet_messages
send chat"] end SPACE --> CTRL TOK --> CTRL DBG --> CMS CMS --> MEDIA SCTP --> CHAN MD -.->|"allocation"| SRTP DCRPC -.->|"attribution"| SRTP style BOOT fill:#fff4e5,stroke:#e6a23c style CTRL fill:#e8f4fd,stroke:#409eff style MEDIA fill:#eaf6ec,stroke:#67c23a style CHAN fill:#f4ecf7,stroke:#9b59b6 ``` **这可以看作是四个事实。** 浏览器只需要使用一次，用于获取三个字符串。控制平面是四次普通的 HTTPS 调用，而不是 WebSocket。媒体平面是教科书般的 WebRTC。而所有有趣的事情 —— 谁在说话、他们叫什么、允许你接收什么 —— 都发生在该 WebRTC 会话*内部*的 data channel 上，而不是在 HTTP API 中。 ## 从这里开始 | 如果你想…… | 请阅读 | | --- | --- | | 在了解细节前先看整体轮廓 | [概览](docs/00-orientation.md) | | 发送你的第一个字节 | [传输层](docs/01-transport.md) → [身份验证](docs/02-authentication.md) | | 加入会议 | [加入序列](docs/03-join-sequence.md) | | 协商媒体 | [逐字段解析 CreateMediaSession](docs/05-create-media-session.md) | | 真正接收音频或视频 | [media-director](docs/07-media-director.md) + [dcrpc](docs/08-dcrpc.md) | | 知道谁在说话 | [dcrpc](docs/08-dcrpc.md) | | 读取聊天、名单、举手 | [集合与操作](docs/09-collections-and-actions.md) | | 了解到底能做什么 | [能力](docs/11-capabilities.md) | | 避免浪费一周时间 | **[失败模式](docs/12-failure-modes.md)** | ### 完整目录 **协议** - [00 · 概览](docs/00-orientation.md) —— 心智模型，以及四个让所有人都感到惊讶的点 - [01 · 传输层](docs/01-transport.md) —— gRPC-Web，以及为什么两个方向使用不同的编码 - [02 · 身份验证](docs/02-authentication.md) —— SAPISIDHASH，以及两个 token 缓存 - [03 · 加入序列](docs/03-join-sequence.md) —— 引导 → 同步 → 设备 → 媒体 - [04 · RPC 目录](docs/04-rpc-catalogue.md) —— 观测到的每一个服务和方法 - [05 · CreateMediaSession](docs/05-create-media-session.md) —— 逐字段解析 2.9 KB 的消息 - [06 · Data channel](docs/06-data-channels.md) —— 十九个预协商通道，无 DCEP - [07 · media-director](docs/07-media-director.md) —— 你如何请求发送任何内容 - [08 · dcrpc](docs/08-dcrpc.md) —— 顺序 RPC，以及 SSRC 到参与者的归属映射 - [09 · 集合与操作](docs/09-collections-and-actions.md) —— 资源模型、聊天、静音、举手 - [10 · 媒体平面](docs/10-media-plane.md) —— 从未跨越网络传输的 SDP、编解码器、RTP **实践** - [11 · 能力](docs/11-capabilities.md) —— 客户端能获取和做的事情，附带置信度 - [12 · 失败模式](docs/12-failure-modes.md) —— 针对发现的每个陷阱，提供 症状 → 原因 → 修复 - [13 · 捕获方法](docs/13-capture-methodology.md) —— 如何重现和重新验证所有内容 - [14 · 未解之谜](docs/14-open-questions.md) —— 目前仍未知的内容，以及如何攻克它 **参考表** - [标头](reference/headers.md) · [编解码器](reference/codecs.md) · [RTP 标头扩展](reference/rtp-header-extensions.md) - [Data channel](reference/data-channels.md) · [字段映射](reference/field-maps.md) · [网络抓包样本](reference/wire-samples.md) - [meet.proto](reference/meet.proto) —— 尽力而为重构出的 schema - [图表索引](diagrams/README.md) —— 每一张图表，均提供可复用的 Mermaid 源码 **交互式内容** - **[协议地图 ↗](https://arjun1194.github.io/google-meet-protocol/)** —— 一个独立的页面，包含可点击的分层模型、九步加入流程演练、针对四个捕获数据帧的**字节级浏览器**，以及可搜索的症状→原因查询表。源码：[site/index.html](site/index.html)。 ## 如何阅读证据标记 每一个不明显的声明都带有标记。它们不是装饰：这是一个逆向工程得出的协议，*“服务器接受了这个”*与*“这在抓包中看起来是对的”*之间的区别，意味着耗费一个下午还是整整一周时间的差异。 | 标记 | 含义 | | --- | --- | | ✅ **已证实** | 从零开始的客户端发送或解析了此内容，且服务器行为符合描述。可重现。 | | 👁 **观测到** | 在真实客户端的抓包中见过。未经独立重现。 | | 🧩 **推断** | 与证据以及协议其他部分的行为一致。但未作演示。 | | ❓ **未知** | 在此指出以揭示空白。请不要基于此进行构建。 | 一个关于这为何重要的具体例子，来自[失败模式](docs/12-failure-modes.md)：会议 token 曾连续几周被记录为*浏览器生成的证明*。这是 🧩 推断出来的，依据是它以 `ADmEuv` 开头且未联系任何证明端点。实际上它是服务器签发的，并且存在于一个响应标头中。试图伪造这样一个 token 而耗费的每一个小时，都花在了一个披着事实外衣的推断上。 ## 最耗费时间的五件事 首先写这一部分，因为本仓库的其余所有内容都是它们的下游。 1. **有两个会议 token 缓存，而不是一个。** 状态调用会根据响应标头轮换其 token；而媒体调用则永远保留初始引导值。将它们合并会被拒绝并返回 `400 invalid argument` —— 这与用于格式错误正文的措辞相同。 → [身份验证](docs/02-authentication.md) 2. **已连接的会话不携带任何内容。** ICE 到达 `connected`，DTLS 完成，但在你于 `media-director` data channel 上发送配置帧之前，不会有任何媒体到达。也没有任何报错。 → [media-director](docs/07-media-director.md) 3. **Meet 的 data channel 是预协商的，它从不发送 DCEP open。** 它在 `CreateMediaSession` 响应中为每个通道分配一个 SCTP 流 ID，然后直接向其写入二进制数据。一个等待被告知通道信息的客户端永远也等不到。 → [Data channel](docs/06-data-channels.md) 4. **流分配中的 SSRC 是 `fixed32`，而不是 varint** —— 这是整个协议中唯一的一个。如果将其作为 varint 读取，会得到一个看似合理但不匹配任何到达数据包的数字，导致会话看起来悄无声息地空无一物。 → [media-director](docs/07-media-director.md) 5. **请求是 gzip 压缩的；响应是 base64 编码的。** 这种不对称是真实存在的。捕获到的响应完全是可打印的 ASCII 字符，并且在解码一次之前看起来完全不像 protobuf。 → [传输层](docs/01-transport.md) ## 仍然缺失的内容 本文档的诚实边界，各用一句话概括。详细信息和攻击计划见[未解之谜](docs/14-open-questions.md)。 | 空白 | 后果 | | --- | --- | | 获取 Space ID 需要完整的浏览器指纹 | 每次会议仍需使用一次浏览器 | | 会议 token 的生成算法是不透明的 | 它只能被借用，永远无法被生成 | | `dcrpc` 流的**注册**已解码但未经证实 | 分配可能不遵循该握手流程 | | 字幕通道存在，但从未在抓包中携带文本 | 转录仍需语音引擎支持 | | 主持人专属控制项尚未映射 | 需要一个由测试账户拥有的会议 | ## 法律与道德立场 在使用其中的任何内容之前，请阅读此内容。 - 将 Google Meet 自动化**违反了 Google 的服务条款**。运行自动化程序的账号会被标记并禁用。请使用你能够承受损失的账号。 - 这是一份观测协议的文档，是通过观察作者运行的客户端、以及作者作为参与者参加的会议的进出流量而生成的。这里没有复制任何 Google 代码，这里的任何内容也没有绕过任何访问控制：所描述的每一个字节都需要一个已登录且已被准入会议的账号。 - 录制、转录或存储会议的音频、视频、聊天或参会者名单在大多数司法管辖区都受到监管，并且需要获得参会者的同意。你是否拥有这种同意是你自己的问题，而不是协议的问题。 - **如果你想要一个受官方支持的途径，请使用官方的 [Google Meet Media API](https://developers.google.com/meet/media-api)。** 它在不会导致你被封号的条款下，公开了一个刻意设计得非常相似的形态 —— 三个音频流、按参与者分离。当官方 API 不能覆盖你的使用场景时，本仓库非常有用；但这并不代表建议你避开官方 API。 ## 贡献 欢迎提供发现，尤其是纠正。在 [CONTRIBUTING.md](CONTRIBUTING.md) 中有一条规定：**每个声明都必须带有其证据标记，并且在未说明你运行了什么的情况下，不得将推断提升为事实。** 本文档历史上的几个结论曾连续几周被坚定地认为是错误的。这些标记使得这种情况得以被纠正。 ## 许可证 [CC BY 4.0](LICENSE)。使用它，在它的基础上构建，并注明出处。
标签：Google Meet, WebRTC, 云资产清单, 内核驱动, 后端开发, 技术文档, 网络协议, 网络通信, 逆向工程