产品有需求要全力满足，产品没有需求创造需求也要满足。

本次的主角是携程APP。以它为例子介绍一下Protobuf协议逆向分析及协议仿真。

本文你将了解到Google Protobuf的逆向分析及协议还原等知识。

机票价格接口

按照正常的过程，我们逆向第一步应该是抓包。下面是我抓到的。

看到这里不要怀疑，我们抓包没有问题，那为什么会这样呢。

正常情况下，抓到的包应该是标准的HTTP协议格式，我们实现完成整个报文的仿真模拟，然后发包即可。但是现在，我们什么都看不到。

抓包我使用的工具是Packet Capture，它是基于本地VPN实现的抓包，可以支持TCP及以上层的消息捕获。

那么，我们现在就有理由怀疑，携程的网络通信，没有使用HTTP协议，而是自建协议完成的。

分析完毕，那么下一步我们怎么来找到收发包位置呢。

（此处省略几万字的定位过程）

经过长时间的寻找，后来灵机一动，如果是我来写接收数据的代码，很可能我要写个while True的循环，然后用已经建立连接的socket进行循环接收数据。以此为标识，我们找找看。

紧接着，我们在最后一个结果中找到了想要的接收数据的标识。

当我们跟着这个invokeResponse一直下去，就能找到一个神奇的地方“ctrip.business.comm.ProcoltolHandle”，（在这里你能找到所有的序列化和反序列化过程）到这里，具体的逆向就不表了。相信看到这的同学继续找下去不是问题。从这里我们可以知道，每一个包前面有14个字节的协议头，之后是gzip压缩的结果。再后面是4字节的包体的长度，然后是消息内容。

这样我们就可以写出来解码的代码。

需要说明一下的是，data的来源即是我们抓包抓到的十六进制，copy出来就可以。

接下来着重说一下这个proto_decode。

我们反序列化protobuf是利用google提供的工具protoc.exe，带参数执行可以解码成可读的形式。（感谢YungGong协助）

这个其实就是相当于HTTP协议里的header了，可是我们现在还不知道字段名，记住这些数字。我们在代码里找找看。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！