一、Protobuf的特征
① Protocol buffers是一种语言无关、平台无关、可扩展的
序列化结构数据的方法；严格说不算是加密，只能是叫序列化结构数据，让可读变为疑似的乱码① 请求头里明显有提示，媒体类型是proto，
content-type: application/grpc-web+proto
② 参数或者响应被序列化：呈现乱码格式0B，无论请求参数还是响应都无法看出是什么
③ 上面序列化的数据都可以复制保存为解析
.bin文件，解析.bin文件显示原始数据有两种方法，都会出现还原失败的情况，这和复制下来的序列化数据有关④ 方法1：直接复制序列化的数据，然后用
blackboxprotobuf模块解析，即可看到原始数据，但是有可能是失败的结果，如图并未正常还原
⑤ 方法2：需要去链接 https://github.com/protocolbuffers/protobuf/releases/ ，下载
protoc-3.19.4-win64.zip并解压，然后D:\Programmer\protoc-3.19.4-win64\bin添加环境变量，然后即可在cmd执行protoc --decode_raw < test_data.bin，其中test_data.bin是一个文件名称，即可看到原始数据，当然这个也会有解析失败的情况比如Failed to parse input.
⑥ 解析protobuf方法也有两种：一种就是步骤4的方式(推荐)，另一种需要通过步骤5的方式来分析，先根据特征编写.proto文件，然后再编译生成python包pb2，然后再导pb2包去解析，此过程比较复杂，如果步骤5确实行不通的话，再尝试改方法
二、Protobuf的解析思路流程
① 打开fiddler抓包，请求查看选择
HexView，然后选择一定范围黑色的十六进制数，然后右击保存为.bin文件，比如保存为source_form_data.bin文件
② 获取
原始数据(即反序列化)，以及消息类型，其中依赖安装：pip install blackboxprotobuf，然后按如下脚本解析步骤①保存下来的source_form_data.bin文件，如果.bin文件解析报错，说明你保存的十六进制范围有问题，需要调试找原因，不一定所有的黑色字体十六进制都要保存import blackboxprotobuf # 1、得到消息类型message_type with open(r"source_form_data.bin", "rb") as fp: data = fp.read() deserialize_data, message_type = blackboxprotobuf.protobuf_to_json(data) print(f"原始数据: {deserialize_data}") print(f"消息类型: {message_type}") # 消息类型③ 对于请求参数
原始数据和消息类型的作用：原始数据deserialize_data和消息类型message_type都需要，因为我们需要把它按序列化的格式进行传送请求，所以通过上面的解析.bin文件，我们就可以得到原始数据和消息类型
④ 请求参数需要注意的点就是，
部分原始数据deserialize_data的value类型应该与消息类型的type类型保持一致，比如message_type里面’5’: {‘type’: ‘int’, ‘name’: ‘’}对应的type类型是int类型，那么你相应的deserialize_data的key"5"的值1也应该是int类型 ，其它看是否报错再进一步调整
⑤ 对于响应结果
原始数据和消息类型的作用：只要得到原始数据就行了
⑥ 按如上步骤请求和响应处理好后，再运行即可得出结果，其中有些坑可以到文章末尾推荐的文章里面找到解决方案
对啦，我的公众号
逆向OneByOne，会有更详细的介绍