美团App WSS WebSocket逆向分析：从抓包到协议还原实战

1. 项目概述与工具链准备

我说句实在话，现在做客户端接口分析，十个里有七八个都在跟WebSocket较劲。美团App的很多实时数据——比如订单状态推送、骑手位置更新、消息中心的即时通知——走的都是WSS（WebSocket over TLS）通道，而不是传统的HTTP轮询。这背后的原因也很直接：WebSocket能维持一条长连接，服务端可以主动往客户端推数据，实时性比轮询高出一个量级，而且省掉了大量无意义的HTTP握手开销。

把“美团WSS WebSocket逆向分析”作为研究对象，并不是说要去碰什么不该碰的东西，而是这个案例特别典型。美团App的WSS实现基本代表了国内大厂的主流做法：TLS加密传输、自定义协议头、JSON或二进制负载、心跳保活机制、Token鉴权。把这套链路拆明白，你再去分析其他App的WebSocket通信，思路和方法论可以直接平移，很多东西都大同小异。

这篇文章我会从零开始，把完整链路走一遍：先说清楚怎么定位WSS端点和确认抓包方案，再分析握手阶段的参数构造逻辑，然后深入解析消息帧的数据格式和加解密规则，最后演示如何用Python脚本完整复现一次WSS连接，以及常见的反爬坑和排查思路。

动手之前，先把工具准备好。我列一下这次实际用到的全家桶：

• 抓包工具：Charles 4.x 或 Fiddler Everywhere，用于明文抓取HTTPS请求，定位WSS握手入口。Android 7.0以上系统默认不信任用户证书，所以还需要配合Frida或Magisk模块处理SSL Pinning。
• 反编译与代码分析：jadx 1.4+，用于反编译APK，搜索关键字定位WebSocket相关代码路径。配合JEB或GDA做交叉引用，效率会更高。
• 动态调试：Frida 15.x+，用来Hook关键方法，动态查看参数生成过程，或者绕过证书校验。
• Python环境：需要websocket-client库（新版叫websockets库），或者直接基于asyncio写原生WebSocket客户端。
• 辅助工具：010 Editor或十六进制工具，用于分析二进制消息帧；Wireshark用于TCP层的原始流量对照；Burp Suite也可以备用，处理特殊场景。

注意：本案的抓包分为两个层面。如果只是看WSS握手请求，Charles足够；但如果要看TLS内部的WebSocket帧，就必须解决证书信任问题。这里最干净的做法是给手机装Magisk模块，把用户证书移入系统证书目录，同时Hook掉App的SSL Pinning检测。两个步骤缺一不可，否则要么抓不到明文，要么App直接断网。

2. 定位WSS端点与确认分析目标

2.1 从流量入口反查WebSocket端点

第一步永远是抓包看流量。美团App打开后，会有大量HTTP请求，你需要先去过滤WebSocket握手请求——特征是HTTP Upgrade头，值为websocket。用Charles抓包时，直接在Filter栏输入websocket，所有WSS连接会立刻被过滤出来。

我这次抓到的主要WSS端点长这样：

code复制wss://activity-api.meituan.com:443/ws?app=meituan&channel=and&...

注意几个细节。端口用的是443，说明TLS终止在标准HTTPS端口上，这类设计是为了躲过防火墙对非常规端口的拦截。协议版本通常有v参数标识，不同版本的消息格式可能有差异。另外，美团倾向于把多个业务域的WebSocket合并成一个网关入口，通过URL上的app和scene字段做路由分发，所以单独一个WSS端点背后可能承载着多个不同业务的消息。

确认端点的下一步，是把握手请求的完整头信息复制下来。这里能挖出很多重要线索：Sec-WebSocket-Key、Sec-WebSocket-Version、Origin、Cookie，以及一堆自定义Header。其中自定义Header往往藏着鉴权参数，比如我这次就看到了x-token、x-uid、x-sign这几个关键字段。

2.2 静态代码搜索定位WebSocket入口

光靠抓包看不到内部的逻辑，接下来用jadx反编译APK，在代码层面找到WebSocket的初始化入口。首选搜索关键字是WebSocket、websocket、WebSocketClient、OkHttpClient（美团客户端网络层基于OkHttp，这是公开信息）。

jadx打开反编译结果后，用全局搜索wss://或ws://，通常能直接命中WebSocket地址的拼接逻辑。我这次命中的代码大概长这样：

java复制public void connectWebSocket(String token, String uid) {
    HttpUrl url = HttpUrl.parse("wss://activity-api.meituan.com/ws")
        .newBuilder()
        .addQueryParameter("app", "meituan")
        .addQueryParameter("scene", "message_center")
        .addQueryParameter("v", "2.0")
        .build();
    Request request = new Request.Builder()
        .url(url)
        .addHeader("x-token", token)
        .addHeader("x-uid", uid)
        .build();
    mWebSocket = mOkHttpClient.newWebSocket(request, mListener);
}

这段代码的价值在于确认了三件事：WSS的路径和参数构造方式、自定义Header的字段名和值的来源、OkHttp作为底层WebSocket实现。有了这些，后续模拟连接时就知道该往哪里填参数了。

2.3 确认数据交互场景

定位了端点和入口代码之后，还得搞清楚一个更关键的问题：这个WebSocket连接上实际在传什么数据？这一步不能靠猜，要动态验证。

我的做法是：用Frida Hook住WebSocketListener的onMessage回调，把收到的消息实时打印出来。结合App的操作动作，比如下单、发消息、刷新订单状态，就能把消息内容和业务场景对应起来。实测下来，美团WSS通道上主要跑四类消息：服务端主动推送的订单状态变更、骑手实时位置坐标（按秒级频率推送）、消息中心的会话更新通知，以及客户端上行的业务请求（比如发送聊天消息、上报已读回执）。

把“场景联动分析”做扎实，后面写模拟客户端的时候才知道要监听哪些消息类型，才不会像个无头苍蝇一样乱撞。

3. WSS握手过程的参数构造与鉴权逻辑

3.1 握手请求的Header构造规则

WebSocket握手本质上是一次带Upgrade: websocket头的HTTP GET请求。服务端返回101状态码，连接就建立了。美团对这个握手做了差异化处理，主要体现在自定义Header上。

我把这次抓到的握手Header擦了敏感信息之后，核心结构是这样的：

code复制GET /ws?app=meituan&channel=and&v=2.0&scene=message_center HTTP/1.1
Host: activity-api.meituan.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xxxxxxxxxxxxxxxx
Sec-WebSocket-Version: 13
Origin: https://activity-api.meituan.com
x-token: eyJhbGciOi...
x-uid: 1234567890
x-app-version: 7.2.3
x-device-id: a8c0b1...

其中真正起到鉴权作用的是x-token和x-device-id。x-token是一串JWT格式的令牌，里面默认包含用户ID和会话信息。x-device-id是设备指纹标识，同一个账号如果频繁更换设备ID，会触发风控拦截。

实操中遇到的一个坑：直接把抓到的Header原样放到自己的脚本里跑，大概率第一次能通，第二次就被踢下线了。原因是服务端会校验Header中的Origin字段是否来自合法的App域名，同时会校验x-app-version是否在允许的版本白名单内。所以模拟时不能照抄，必须把自己伪装成正常客户端。

3.2 关键参数生成逻辑分析

逆向分析的核心，就是要把x-token和x-device-id的生成逻辑搞清楚。在代码层搜索这两个字段名的引用，会链到登录后的Token管理器和设备信息工具类。具体逻辑大致如下：

• x-token：用户登录成功后，由服务端下发，保存在本地SharedPreferences或SQLite中。短期有效，过期后需要走刷新逻辑。
• x-device-id：首次启动时生成，算法基于Android ID + Build信息 + 随机盐做MD5，存储在本地。如果App被重装、数据被清除，这个值会变化。
• x-sign：在某些业务场景下会额外出现，是对请求参数按字典序排序 + 拼接固定盐值后做MD5或SHA256的结果。

拆分清楚只是第一步，实际写脚本时需要模拟生成或者直接复用现成的本地Token。这里我建议先用登录态导出的Token做验证，确认整个链路畅通之后，再考虑搞定动态签名算法。两步走，避免一开始就被签名校验卡死。

3.3 证书校验与绕过策略

美团App的WSS连接做了双向TLS校验，客户端会验证服务端证书，同时服务端可能校验客户端证书链。最常见的绕不过去的问题是两类：证书校验失败导致连接直接断开，以及SSL Pinning检测导致Charles抓不到明文。

解决方案我实测下来有效的是组合拳：先用Magisk + Move Certificates模块把Charles证书装入系统证书目录，再用Frida跑一段SSL Pinning绕过脚本。这两步搞定后，Charles就能正常看到WSS里面的内容了。

如果你手头没有Root设备，备选方案是：在模拟器里用Android 7.0以下的老镜像（默认信任用户证书），或者直接在代码层HookTrustManagerImpl的verifyChain方法，强制返回信任。

4. WebSocket消息帧结构与数据解析

4.1 WebSocket帧格式速览

WebSocket的帧结构是RFC 6455定义的，了解它不需要把协议栈背下来，但核心的几个位段必须清楚。每个帧由FIN位、Opcode、Mask位、Payload Length和Masking Key构成。客户端发给服务端的帧必须做掩码处理（Mask位为1），服务端下发的帧不做掩码。

Opcode是重点，常用值就三个：0x1表示文本帧，0x2表示二进制帧，0x8表示关闭帧，0x9是Ping，0xA是Pong。抓包时看到Opcode为1的消息，直接用UTF-8解码就能看到JSON数据；如果是2，就得走反序列化逻辑，去还原Protobuf或者自定义二进制结构。

美团WSS的文本帧内容，默认是JSON格式。一个典型的服务端主动推送消息长这样：

json复制{
    "type": 101,
    "seq": "abc123",
    "timestamp": 1690000000000,
    "data": {
        "messageId": "m123456",
        "scene": "order_status",
        "content": "骑手已取餐",
        "extra": {}
    }
}

type字段是消息类型编号，seq是消息唯一序号，timestamp是毫秒级时间戳。data里套的是业务数据。解析时只需要把type和data取出来，按照业务约定做分发就行。

4.2 二进制帧的Protobuf还原思路

美团部分高频场景（比如骑手位置推送）用的是二进制帧，底层编码是Protobuf。Protobuf的消息结构由.proto文件定义，逆向时没有现成的定义文件，需要靠特征去反推。

反推的办法是分三步走。第一步，抓一批二进制消息样本。第二步，用protoc --decode_raw做未知字段解析，把二进制转成可读的字段编号和值。第三步，根据字段编号连续性和值类型，推断出消息结构的字段命名，重新写一个.proto文件并验证。

我举个例子，抓到的十六进制长这样：

code复制08 01 10 98 b6 01 1a 0c 31 31 36 2e 32 35 32 2e 31 33 38 2e 35 22 0f ...

用protoc --decode_raw解析后的结果是：

code复制1: 1
2: 20118
3: "116.252.138.5"
4: "34.2587,108.9542"

对照一下业务场景就能猜出来：字段1可能是消息类型，字段2是时间戳或序号，字段3是服务端IP，字段4是经纬度字符串。把多个样本的规律总结出来，就能做出准确率很高的解析器。

4.3 心跳与保活机制

WebSocket长连接最怕的是一段时间没消息就被网络中间层断开。美团的做法是标准的Ping/Pong心跳机制，客户端每隔约30秒发送一个Opcode为9的Ping帧，服务端回复Opcode为10的Pong帧。如果超过一定时间没收到Pong，客户端就主动断开重连。

自定义协议实现心跳的情况也有。有些场景App会在WebSocket通道里发送一个{"type": 1001, "data": {}}这样的业务层心跳包，服务端同样回复业务层的Pong包。判断方式很简单：如果发Ping后服务端没有响应，看有没有业务层心跳包即可。两种模式的应对策略不同，模拟客户端时务必确认清楚。

实测建议：如果你自己写WebSocket客户端，心跳间隔不要小于20秒，也不要大于60秒。美团服务端对超时断开的阈值大概是90秒左右。不过为了保险，最好参考抓包的实测间隔，别拍脑袋定。

5. 模拟客户端完整实现

5.1 基础版WebSocket连接脚本

验证完协议细节，就可以直接用Python写一个模拟客户端。我用的是websocket-client库，先用最简单的同步模式打通流程：

python复制import websocket
import json
import time

def on_message(ws, message):
    print("收到消息:", message)

def on_error(ws, error):
    print("错误:", error)

def on_close(ws, close_status_code, close_msg):
    print("连接关闭:", close_status_code, close_msg)

def on_open(ws):
    print("连接成功")
    # 发送一个业务层心跳包
    ws.send(json.dumps({"type": 1001, "data": {}}))

headers = {
    "x-token": "你的token",
    "x-uid": "你的uid",
    "x-app-version": "7.2.3",
    "Origin": "https://activity-api.meituan.com"
}

ws = websocket.WebSocketApp(
    "wss://activity-api.meituan.com/ws?app=meituan&channel=and&v=2.0&scene=message_center",
    header=headers,
    on_message=on_message,
    on_error=on_error,
    on_close=on_close
)
ws.on_open = on_open

# 启动连接，不设超时
ws.run_forever()

这个脚本能跑通，代表着整条WSS链路已经打通了。需要注意，如果服务端校验了Sec-WebSocket-Protocol子协议，你需要在请求头里加上对应的值，否则握手会返回403。

5.2 心跳保活与断线重连增强版

长连接场景下，一个健壮的客户端必须具备三个能力：自动心跳、断线重连、消息去重。我写了一个增强版，把心跳放到独立线程里跑，每30秒发一次Ping和一次业务心跳；连接断开后按指数退避策略重连，最多重试5次。

python复制import websocket
import json
import time
import threading

HEARTBEAT_INTERVAL = 30
MAX_RETRY = 5

class WSSClient:
    def __init__(self, url, headers, token):
        self.url = url
        self.headers = headers
        self.token = token
        self.ws = None
        self.retry_count = 0
        self.last_pong_time = time.time()

    def connect(self):
        self.ws = websocket.WebSocketApp(
            self.url,
            header=self.headers,
            on_message=self.on_message,
            on_error=self.on_error,
            on_close=self.on_close,
            on_pong=self.on_pong
        )
        self.ws.run_forever(ping_interval=HEARTBEAT_INTERVAL, ping_timeout=10)

    def on_message(self, ws, message):
        print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] {message}")

    def on_error(self, ws, error):
        print("错误:", error)

    def on_close(self, ws, close_status_code, close_msg):
        print("连接关闭，尝试重连...")
        self.reconnect()

    def on_pong(self, ws, message):
        self.last_pong_time = time.time()

    def reconnect(self):
        if self.retry_count < MAX_RETRY:
            delay = min(2 ** self.retry_count, 60)
            print(f"{delay}秒后重连...")
            time.sleep(delay)
            self.retry_count += 1
            self.connect()
        else:
            print("重试次数耗尽，放弃连接")

client = WSSClient(
    "wss://activity-api.meituan.com/ws?app=meituan&channel=and&v=2.0&scene=message_center",
    headers,
    token
)
client.connect()

websocket-client库自带的ping_interval和ping_timeout参数非常好用，底层会自动发Ping帧和管理Pong超时，省掉了自己写心跳线程的很多麻烦。如果服务端对Ping/Pong特别敏感，可以在on_pong里更新一个时间戳，再单独开线程检查这个时间戳是否超过阈值，超过就主动断开重连。

5.3 消息多路分发与业务处理框架

实际的业务场景里，收到的消息类型五花八门，不能每个消息都走同一套处理逻辑。我习惯把消息解析和业务处理解耦，按type字段做分发。这一版我用字典做处理器映射，新增消息类型时只需要注册回调函数即可。

python复制class MessageDispatcher:
    def __init__(self):
        self.handlers = {}

    def register_handler(self, msg_type, handler):
        self.handlers[msg_type] = handler

    def dispatch(self, raw_message):
        try:
            msg = json.loads(raw_message)
            handler = self.handlers.get(msg.get("type"))
            if handler:
                handler(msg.get("data", {}))
            else:
                print(f"未注册的消息类型: {msg.get('type')}")
        except Exception as e:
            print(f"消息解析失败: {e}, 原始消息: {raw_message}")

def handle_order_status(data):
    print(f"订单状态更新: {data.get('content')}")

def handle_location_update(data):
    print(f"骑手位置: {data.get('extra', {}).get('lat')}, {data.get('extra', {}).get('lng')}")

dispatcher = MessageDispatcher()
dispatcher.register_handler("order_status", handle_order_status)
dispatcher.register_handler("location_update", handle_location_update)

框架搭好后，业务逻辑的迭代速度会快很多。每接到一个未知消息，先打日志看结构，确认字段含义后写个处理函数注册上去就行。

6. 常见问题与排查技巧实录

6.1 WSS连接失败的高频原因

把这段实操中反复踩过的坑整理成一张表，遇到问题可以先对照检查。

6.2 抓包无法看到WSS明文内容

这是最容易让人卡壳的环节。Charles装了证书，手机也信任了证书，但WSS连接还是无法解密。原因几乎都出在SSL Pinning上。App在代码里校验了证书的指纹或者公钥，和系统信任的证书链不匹配，直接断开连接。

解决办法是跑Frida脚本绕过校验。核心思路是Hook掉OkHttp的CertificatePinner类，将check方法替换为空操作，或者Hook系统的TrustManagerImpl让所有证书都通过校验。

python复制import frida
import sys

def on_message(message, data):
    print(message)

script_code = """
Java.perform(function() {
    var CertificatePinner = Java.use('okhttp3.CertificatePinner');
    CertificatePinner.check.overload('java.lang.String', 'java.util.List').implementation = function(a, b) {
        console.log('Bypassing CertificatePinner.check');
    };
});
"""

device = frida.get_usb_device()
pid = device.spawn(["com.meituan.xxx"])
session = device.attach(pid)
script = session.create_script(script_code)
script.on('message', on_message)
script.load()
device.resume(pid)

注意：这段脚本只是辅助分析的手段，请不要在正式生产环境使用，也不要用它去绕过正规服务的安全限制。分析完了就删掉，别留着。

6.3 Protobuf解析时的字段推断心得

Protobuf字段推断是最需要耐心的一环。我见过不少新手拿到二进制帧，上来就想直接猜字段名，然后自己写一个proto文件怼进去，结果解析出来全是乱码。

正确的姿势是先收集足量样本，再做暴力解析。至少收集20条相同场景的二进制消息，用protoc --decode_raw逐一解码，把字段编号和值的类型列成一张表。对比多组数据后，你会发现规律：固定字段编号对应固定含义，值类型包括varint、string、fixed32、fixed64等。

一个必须注意的坑是嵌套消息。如果字段值是长度不定的字节串，那这个字段可能是一个嵌套的Protobuf消息。遇到这种情况，把字节串再次交给protoc --decode_raw继续展开，一层层剥洋葱，就能还原出完整的嵌套结构。

6.4 Token过期与风控规避策略

模拟客户端跑久了，必然会遇到token失效或者触发风控的情况。实测有效的做法有这么几点：

• 定期刷新token，不要一个token用到底。美团token的有效期大约是24小时左右，过期了需要调用登录接口刷新。
• 避免在短时间内发起大量的重连操作。每次断开后重连，如果不加退避策略，服务端会判定为异常流量。建议重连延迟按指数退避，从1秒、2秒、4秒、8秒一直涨上去。
• 行为模拟需要贴近真实用户。如果只是长连接挂着收消息，一般不会触发风控；但如果高频主动发消息，或者频繁切换设备ID，就可能触发设备指纹异常。

我最常用的一套组合拳是：抓包时用真机 + 完整登录态，验证阶段用模拟器 + 固定设备ID，长期跑的时候用云手机 + 独立账号。分环境隔离，出问题的概率会低很多。

6.5 长连接状态机的监控思路

写好WSS客户端不代表万事大吉，长期跑还需要一套状态监控。我习惯在客户端里维护一个状态机，记录Connecting、Connected、Reconnecting、Disconnected四种状态，每次状态变化都打日志并写入本地文件。

除此之外，还应该记录消息流水和心跳延迟。心跳延迟可以通过Ping帧发送时间和Pong帧接收时间之间的差值计算，如果连续几次都超过5秒，说明网络链路有问题，需要调整心跳间隔或者切换网络。监控数据攒上一周，基本能摸清连接的稳定性规律，后续做重连策略微调就有据可依了。

整个项目做下来，我最深的体会是：WSS逆向分析的价值，不在于能把一条WebSocket连接跑通，而在于你通过这个过程，把一套复杂系统的通信机制完整地拆解了一遍——从TLS到WS帧，从JSON到Protobuf，从代码追踪到协议还原。这套方法论在任何一个App的WebSocket分析中都能复用。最后再分享一个细节：分析过程中记得把每一步的抓包原始数据和代码交叉引用截图留档，后面写报告复盘的时候，这些素材才是最有说服力的东西。