JS逆向案例-某方的protobuf逆向解析

一、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，会有更详细的介绍

三、推荐文章

• 通过JS逆向ProtoBuf 反反爬思路分享
• 由某知识平台延伸的 Protobuf 协议分析学习
• JS逆向-Protobuf逆向解析