🔖协议分析

WebSocket 逆向和 HTTP 有什么不同HTTP 协议模拟是"一次性请求"的复制，WebSocket 是长连接状态机的复刻：握手、鉴权、心跳、消息编解码、重连，每个环节都有坑。抓包工具对 WS 的支持也弱于 HTTP（Charles 能看但不直观），先建立正确的分析姿势。分析姿势：先看懂消息格式Chrome DevTools 的 Network → WS → Messages 标签页能看到所有帧。重点观察：消息格式：JSON？protobuf？自定义二进制？（JSON 最好办，protobuf 按前文方法还原，自定义二进制最麻烦）消息类型字段：一般有个 type/cmd/op 字段区分

认出 protobuf：先看特征再动手抓包看到请求体是一堆二进制，先确认是不是 protobuf。特征很明显：开头几个字节是 08 xx 12 xx 1a xx 这种模式（field tag + wire type）能解出可读字符串，但字段之间没有分隔符Content-Type 常是 application/x-protobuf 或 application/octet-streamprotobuf 的 wire 格式核心规则：每个字段是 tag + value，tag = (field_number << 3) | wire_type。wire type 就五种：varint(0)

能跑和跑得久是两个工程协议模拟的技术验证（PoC）一天能搞定，但上线跑一周就大面积封号——差距在稳定性工程。本文讲把协议服务从 demo 变成生产系统的关键设计。稳定性问题的四个来源1. 凭证过期：token/cookie 过期没及时刷新，请求批量失败2. 风控累积：行为模式被风控逐步标记，通过率先缓降后跳水3. 目标变更：App/网站更新，签名算法或接口结构变了4. 资源枯竭：IP 被封、账号被封、设备档案被标记对应的稳定性设计逐个讲。凭证生命周期管理class CredentialManager: def __init__(self): self.creds = {

面对陌生 App 的标准作战流程新手逆向陌生 App 最容易犯的错是"上来就怼签名算法"——逆了三天算法，发现还要设备指纹；搞定指纹，发现还有行为风控。正确的流程是先侦察全貌，再决定主攻方向。这套流程我跑了几十个项目，稳定可靠。第一阶段：侦察（半天，不动手逆）1. 抓包看全貌挂上抓包工具（Charles/mitmproxy），把 App 的核心业务流程走一遍（登录、列表、详情、提交），回答三个问题：接口是 HTTP 还是私有协议？（决定分析工具）有没有签名参数？（sign/token/encrypt 字样）响应是明文还是密文？2. 静态看结构jadx 打开 APK（先不深入），看三样东西：加没