孙绿1. 项目背景与核心挑战
某音电商平台的即时通讯系统采用protobuf作为聊天协议的数据交换格式，这是目前互联网企业处理结构化数据的通用方案。protobuf作为Google开源的二进制序列化工具，相比JSON具有更小的数据体积和更快的解析速度，但其二进制特性也给开发者带来了逆向分析的难度。在实际业务场景中，理解这套协议对于开发第三方客户端、数据分析工具或自动化运营系统都具有重要价值。
我最近完整逆向分析了某音2023年最新版的移动端聊天协议，过程中发现其protobuf结构相比去年版本有了重大变更，新增了多种消息类型和加密字段。本文将分享从抓包定位到完整解析的全套方法论，重点解决三个核心问题：如何快速定位关键协议接口、如何还原被混淆的proto定义文件、如何处理嵌套加密的二进制数据。这些技巧同样适用于其他采用protobuf的APP逆向工程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逆向工程准备阶段
2.1 工具链选型与配置
逆向protobuf协议需要组合使用多种工具，经过多次实测对比，我推荐以下工具组合：
- 抓包工具：Charles+Postern（安卓）或Thor（iOS），需配置SSL证书穿透
- 反编译工具：JADX用于静态分析，Frida用于动态调试
- 协议分析工具：protobuf-inspector配合自定义Python解析脚本
- 环境隔离：建议使用真机+企业证书打包的开发版APP，避免风控机制
重要提示：某音2023年起启用了双向证书校验，直接抓包会得到加密数据。需要在Frida中hook SSL库的
SSL_CTX_set_custom_verify函数绕过验证。
2.2 关键接口定位技巧
通过静态分析APK的Smali代码，搜索com.bytedance.im.core.proto包路径可以快速定位协议相关类。但更高效的方法是动态追踪：
python复制# Frida脚本示例：监控protobuf序列化调用
Interceptor.attach(Module.findExportByName("libim.so", "proto_encode"), {
onEnter: function(args) {
console.log("Proto encode called for message type: " +
Memory.readUtf8String(args[1]));
}
});
某音的消息协议主要分布在以下接口：
/im/message/send消息发送/im/message/sync消息同步/im/session/list会话列表/im/msg/batch批量操作
3. protobuf结构逆向实战
3.1 原始数据捕获与清洗
通过抓包获取到的原始数据示例（已脱敏）：
code复制00000000: 0a 24 33 34 35 36 37 38 39 30 31 32 33 34 35 36 .$34567890123456
00000010: 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012
00000020: 12 0a 08 01 12 02 08 01 1a 04 74 65 73 74 22 04 ..........test".
使用protobuf-inspector初步解析：
bash复制python3 protobuf_inspector.py -f captured.bin
输出显示存在字段嵌套：
code复制field 1: length delimited (message)
field 1: varint (1)
field 2: varint (1)
field 3: length delimited (test)
3.2 proto文件还原方法
通过逆向Java层代码找到关键线索：
java复制// 反编译得到的消息构建代码
public void buildMsg() {
IMMessage.Builder builder = IMMessage.newBuilder();
builder.setType(IMEnum.MSG_TEXT); // 消息类型
builder.setContent(textContent); // 文本内容
builder.setTimestamp(System.currentTimeMillis());
}
据此编写对应的proto定义：
protobuf复制message IMMessage {
enum MsgType {
MSG_TEXT = 1;
MSG_IMAGE = 2;
MSG_VIDEO = 3;
}
required MsgType type = 1;
required string content = 2;
optional int64 timestamp = 3;
// 后续通过字段分析补充更多定义
}
3.3 动态验证技巧
使用修改版APP注入测试代码验证proto定义：
java复制// 注入点示例
IMMessage testMsg = IMMessage.newBuilder()
.setType(MsgType.MSG_TEXT)
.setContent("protocol_test")
.build();
Log.d("ProtoTest", Base64.encode(testMsg.toByteArray()));
对比抓包数据与测试输出，可以验证字段映射关系。某音的消息协议通常包含以下核心字段：
| 字段编号 | 类型 | 含义 | 出现版本 |
|---|---|---|---|
| 1 | enum | 消息类型 | v1+ |
| 2 | string | 内容体 | v1+ |
| 3 | int64 | 时间戳 | v1+ |
| 5 | bytes | 加密载荷 | v3+ |
4. 高级逆向技巧
4.1 嵌套消息处理
某音的消息协议采用多层嵌套设计，例如商品卡片消息的结构：
code复制IMMessage
└── MsgContent (field 2)
├── GoodsCard (field 5)
│ ├── GoodsId (field 1)
│ ├── GoodsTitle (field 2)
│ └── GoodsImage (field 3)
└── ActionLinks (field 6)
处理这类数据需要分层解析：
python复制def parse_nested_proto(raw_bytes):
outer_msg = OuterMessage()
outer_msg.ParseFromString(raw_bytes)
if outer_msg.HasField('content'):
content_msg = ContentMessage()
content_msg.ParseFromString(outer_msg.content)
if content_msg.type == CONTENT_GOODS:
goods_msg = GoodsMessage()
goods_msg.ParseFromString(content_msg.payload)
return goods_msg
4.2 加密字段破解
从v3.5版本开始，某音对部分字段进行了AES加密，密钥获取方式：
- 在native层
libencrypt.so中找到getMsgKey函数 - 通过Frida hook获取运行时密钥：
javascript复制Interceptor.attach(Module.findExportByName("libencrypt.so", "getMsgKey"), {
onLeave: function(retval) {
console.log("Message key: " +
Memory.readByteArray(retval, 16));
}
});
解密示例代码：
python复制from Crypto.Cipher import AES
def decrypt_payload(ciphertext, key):
iv = ciphertext[:16]
data = ciphertext[16:]
cipher = AES.new(key, AES.MODE_CBC, iv)
return unpad(cipher.decrypt(data), 16)
5. 常见问题与解决方案
5.1 字段映射错误
现象：解析时出现Field not found错误
原因：版本更新导致字段编号变更
解决：
- 对比不同版本的APK中
buildProto方法的变化 - 使用差分分析工具比较新旧协议样本
5.2 数据校验失败
现象：修改后的消息被服务器拒绝
原因：存在hidden字段校验
排查步骤：
- 检查消息头部的
checksum字段 - 逆向
validateProto方法验证逻辑 - 常见校验算法包括CRC32和自定义哈希
5.3 性能优化建议
处理海量消息时的优化技巧：
- 预编译proto定义文件
- 使用C++版本protobuf解析器
- 对固定结构消息启用缓存
c++复制// 示例：使用Google的C++解析器
IM::Message msg;
msg.ParseFromArray(data, len); // 比Python快8-10倍
6. 协议更新维护
某音通常每季度更新一次协议，建议建立自动化监控体系：
- 通过CI自动反编译新版APK
- 对比关键类的方法签名变化
- 使用差分工具比较协议样本
维护proto定义文件的版本控制策略：
code复制/protos
├── v1.0
│ ├── im.proto
│ └── types.proto
├── v2.3
│ └── im_v23.proto
└── current -> v2.3
这套逆向方法论已在多个电商平台验证通过，核心思路是静态分析与动态调试相结合。实际操作中最耗时的往往是加密字段的处理，建议重点突破密钥生成逻辑。保持协议定义的版本化管理，可以大幅降低后续维护成本。