协议逆向的工具链与取舍

改一个字节看对端是断连还是返回错误，比读代码更快确定字段含义，但别在生产上改，最好在实验环境

工具解决的是「看得见」的问题，判断还是要靠人。

先说结论

工具要少而熟。

• 静态：看结构
• 动态：看数据
• 辅助：做批量
• 先用熟的描述问题
• 效率来自脚本

三类工具

按这个分工选：

固定位置每次加一的字段多半是序号，用来做去重与重放判断，序号跳变通常说明丢了包，重放会直接失效。

怎么选

改一个字节看对端是断连还是返回错误，比读代码更快确定字段含义，但别在生产上改，最好在实验环境。

先用最熟的那个把问题描述清楚，再换工具验证。

几个具体经验

下面这些是相对确定的细节：

• protobuf 不带字段名，只能从 wire type 与取值分布反推每个字段的语义

别做的事

抓一次包就定下协议，漏掉所有可变长字段。

换工具不能代替思考，只会让你更晚发现问题。

一句提醒

协议逆向是实验科学：假设、改包、看反应，循环到能预测为止。

工具链稳定下来之后，效率提升来自脚本，不来自新工具。

还有几处容易忽略的

这些细节不影响入门，但影响你判断的准确度。

• 先找长度字段与魔数，协议的边界通常就由这两个东西定义，它们常在前 16 个字节里，先按这个假设试
• 载荷被压缩或加密时，要先确认能否绕过这一层，再谈字段级解析
• 把解析脚本写成可回归的测试用例，换版本时能立刻发现字段定义变了
• 把校验和当成加密，花两天时间找密钥
• 忽略大小端，字段值总是差 256 倍

工具是手脚，判断是脑子。