关于协议逆向的三个误解

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

误解通常来自把「工具的输出」当成「结论」。

先说结论

保护只提高成本，反编译不等于源码。

• 保护：提高成本而非阻断
• 反编译：丢类型与意图
• 逆向：建模 + 验证
• 看运行时数据
• 先假设再取证

误解一：加了保护就没法看

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

保护提升的是成本，不是绝对阻断；运行时的数据是真的。

误解二：反编译结果等于源码

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

反编译丢的是类型、命名和意图，这三样恰恰最费时间。

误解三：读懂汇编就会逆向

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

逆向的核心是建模：猜出原来的设计，再验证。

几个具体事实

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

怎么少走弯路

先建立「它应该怎么写」的假设，再去找证据。协议逆向是实验科学：假设、改包、看反应，循环到能预测为止。

还有几处容易忽略的

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

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

把工具输出当结论，是最贵的误解。