1. 项目概述为什么我们需要从抓包走向协议还原如果你做过客户端开发、安全测试或者对网络通信感兴趣那么“抓包”这个词对你来说一定不陌生。无论是用 Wireshark 看 TCP 三次握手还是用 Fiddler/Charles 拦截一个 HTTP 请求修改参数抓包工具让我们能直观地看到数据在网络中流动的样子。这就像给网络通信装了一个透明的玻璃管道数据包在里面怎么走看得一清二楚。但不知道你有没有遇到过这种情况用抓包工具成功拦截到了一个 App 或者小程序的请求满心欢喜地打开一看请求体Request Body或者响应体Response Body却是一堆看不懂的“乱码”。它们可能以.pb后缀出现或者 Content-Type 写着application/x-protobuf甚至更隐蔽的直接就是一段二进制数据。你尝试用常规的 JSON 或 XML 解析器去处理结果当然是失败。这时候抓包工具提供的只是一个“管道视图”而管道里流动的“液体”究竟是什么成分、什么结构你依然一无所知。这就是我们今天要面对的核心问题如何从抓到的“二进制乱码”中逆向出它原本的结构化协议特别是当这个协议是 Google 的 Protocol Buffersprotobuf时。Protobuf 因其高效的编码、紧凑的体积和跨语言支持在移动端、微服务、游戏、物联网等领域被广泛使用。微信小程序、抖音、以及许多金融、游戏类 App 的后台接口都大量采用了 protobuf 协议。对于开发者理解这个协议有助于调试和对接第三方服务对于安全研究员或逆向爱好者还原协议是分析应用逻辑、发现潜在漏洞的第一步对于测试人员这可能是实现自动化接口测试的关键。因此“从抓包到 protobuf 协议还原”不再是一个小众的黑客技巧而是一项越来越实用的工程能力。这个实战项目的目标很明确我们不满足于仅仅“看到”数据包我们要“理解”它。我们将扮演一个协议侦探的角色从一次成功的抓包开始通过静态分析、动态调试、代码定位等多种手段最终还原出定义这份二进制数据的.proto文件。有了这个.proto文件我们就能像使用 JSON 一样轻松地序列化和反序列化这些数据从而真正“读懂”应用的通信内容。整个过程我会结合我多次在分析移动端 App、小程序通信协议时踩过的坑把核心思路、工具链和避坑技巧毫无保留地分享给你。2. 核心思路与工具选型侦探的武器库在开始动手之前我们必须先理清思路。逆向解析 protobuf 协议本质上是一个“由果推因”的过程。我们手头只有最终编码后的二进制结果抓到的包需要反推出产生这个结果的“模具”.proto 定义文件。这通常有两条主要路径在实际操作中往往需要结合使用。2.1 路径一静态分析——寻找协议定义的“源代码”这是最直接、最理想的方法。如果能在客户端如 APK、IPA、小程序包的代码或资源文件中直接找到.proto文件或者由它编译生成的代码如 Java 的.java文件、Python 的_pb2.py文件那问题就解决了一大半。针对 Android APK我们可以使用apktool、jadx-gui等工具对 APK 进行反编译。重点搜索.proto后缀的文件或者搜索包含com.google.protobuf导入的类。有时开发者会将.proto文件作为资源打包有时则会直接使用编译后的 Java 类。使用jadx-gui的全文搜索功能搜索关键词如 “.proto”, “protobuf”, “MessageLite” 等往往能有意外发现。针对微信小程序小程序的包本质上是压缩文件可以通过一些解包工具获取其源代码。在小程序的service或utils等目录下有时会存在*.proto文件或*_pb.js这样的编译后文件。如果找到了.proto文件恭喜你可以直接使用。如果只找到_pb.js我们可以通过分析其结构反向推导出大致的.proto定义虽然不完整但极具参考价值。针对 iOS App需要对 IPA 文件进行解密和脱壳然后使用class-dump、Hopper或IDA进行二进制分析寻找与 protobuf 相关的符号。这条路门槛较高但原理相通。实操心得不要一上来就想着硬啃二进制。花 30 分钟仔细做一遍静态资源搜索如果能找到现成的.proto或相关代码能节省你后面几个小时甚至几天的工作量。很多中小型项目为了开发方便确实会把协议定义文件打包进去。2.2 路径二动态分析与黑盒推导——当源代码无处可寻更多的时候我们找不到现成的协议定义。协议可能由服务器动态下发或者代码经过了高度混淆和加密。这时我们就需要扮演“黑盒测试员”通过输入和输出来推测系统内部逻辑。基于已知结构的模糊测试如果我们能通过抓包收集到同一个接口在不同场景下的大量请求/响应样本就可以进行对比分析。例如一个返回用户信息的接口用户 A 和用户 B 的响应二进制数据其差异部分很可能就对应着“用户名”、“用户ID”这些字段。通过对比多个样本可以初步推断出哪些字节是长度标识哪些是字段标识Field Number哪些是实际数据。Hook 关键函数这是动态分析中的“杀手锏”。无论是 Android 的 Xposed/Frida还是 iOS 的 Frida我们都可以 Hook 住 protobuf 序列化/反序列化的关键函数。例如在 Java 层我们可以 Hookcom.google.protobuf.MessageLite#parseFrom(byte[])或#toByteArray()方法。当 App 调用这些方法时我们的脚本就能同时捕获到原始的二进制数据和已经被解析成的内存中的对象。通过打印这个对象的类名、字段名和值我们就能直接“看到”协议的结构。这是最高效的方法。使用专用逆向工具有一些开源工具专门为此而生例如protobuf-inspector。它的原理是给定一段 protobuf 二进制数据它会尝试按照 protobuf 的编码规则Varint, Length-delimited 等进行解析并生成一个可能的结构树。虽然它无法得知确切的字段名字段名在编码时已被丢弃只有字段编号 Field Number 被保留但它能准确地告诉你每个字段的编号、数据类型int32, string, embedded message 等和值。这为我们手动编写.proto文件提供了最关键的依据。工具选型清单抓包工具Fiddler/Charles(HTTP/HTTPS 代理适合 App/小程序)、Wireshark(底层网络抓包全能但复杂)、mitmproxy(可编程的代理适合自动化)。静态分析jadx-gui(Android 反编译)、apktool(Android 资源解包)、unzip/7z(解压小程序包)。动态分析Frida(跨平台动态插桩首选)、Xposed(Android 旧版系统常用)。Objection(基于 Frida 的渗透测试框架) 也内置了一些 protobuf 相关的命令。协议分析protobuf-inspector(Python 脚本核心工具)、blackboxprotobuf(另一个 Python 库功能类似)。辅助工具protoc(Google 官方的 protobuf 编译器用于验证和编译我们还原的.proto文件)、Python或Node.js环境用于运行分析脚本。注意事项使用 Frida 等动态工具需要手机有 RootAndroid或越狱iOS权限或者在可调试的模拟器中进行。对于微信小程序由于其运行在微信的沙盒环境中直接 Hook 微信主进程的难度较大通常更依赖静态分析抓到的包和protobuf-inspector这类黑盒分析工具。3. 实战全流程拆解一步步还原一个未知协议光说不练假把式。我们假设一个最棘手的场景分析一个安卓 App 的登录接口我们抓到了它的登录请求和响应包内容是 protobuf 格式并且在反编译的代码中找不到任何明显的.proto痕迹。我们将按照以下步骤进行。3.1 第一步成功抓包并提取关键数据首先确保你的手机和电脑在同一个局域网并在手机上配置好代理指向运行着 Fiddler/Charles 的电脑。在 App 中完成一次登录操作。定位请求在抓包工具中找到登录相关的请求。通常路径可能包含login、auth等关键词。确认其Content-Type是application/x-protobuf或者查看其Request Body是一堆非文本的二进制数据在 Fiddler/Charles 的 TextView 或 HexView 中查看。导出二进制数据这是关键一步。我们不能直接复制粘贴显示出来的乱码。以 Charles 为例选中该请求右键选择Save Response…或Save Request…将其保存为一个.bin或.dat文件。务必保存原始二进制流。在 Fiddler 中可以在Inspectors-TextView或HexView标签页看到原始数据但导出更推荐使用Fiddler Script或直接复制 Hex 值。避坑技巧很多新手在这里犯错直接复制了抓包工具界面里经过部分解码或格式化的文本导致后续分析失败。一定要导出原始二进制字节流。一个简单的验证方法是用文本编辑器如 VS Code 的 Hex Editor 模式打开你保存的文件看到的应该是以十六进制表示的数字如08 96 01 12 07...而不是‰...这样的乱码字符。3.2 第二步初窥门径——使用 protobuf-inspector 进行首次解析拿到login_request.bin后我们首先使用protobuf-inspector进行自动化解析。安装工具pip install protobuf-inspector运行解析在终端中进入你保存.bin文件的目录执行protobuf-inspector login_request.bin或者将输出重定向到文件以便仔细查看protobuf-inspector login_request.bin request_structure.txt解读输出打开request_structure.txt你会看到类似下面的结构1: 1 (VARINT) 150 2: 2 (LENGTH_DELIMITED) my_username 3: 2 (LENGTH_DELIMITED) my_encrypted_password 4: 5 (LENGTH_DELIMITED) \n\x07\x01\x02\x03\x04\x05\x06\x07第一列如1:这就是字段编号 (Field Number)是 protobuf 编码的核心。它代替了字段名使得编码非常紧凑。第二列如1 (VARINT)这是数据类型 (Wire Type)。1代表VARINT用于 int32, int64, uint32, bool, enum 等2代表LENGTH_DELIMITED用于 string, bytes, embedded messages 等还有其他类型如5代表 32-bit fixed。第三部分解析出来的值。对于VARINT是数字对于LENGTH_DELIMITED是字符串或嵌套消息的二进制表示。上面的输出告诉我们这个登录请求消息我们暂时命名为LoginReq大概有 4 个字段字段1 (编号1): 一个整数值 150可能是版本号或某种标识。字段2 (编号2): 字符串 “my_username”。字段3 (编号3): 字符串 “my_encrypted_password”看起来是加密后的密码。字段4 (编号4): 又是一个LENGTH_DELIMITED类型但其值是一串二进制字节。protobuf-inspector发现它内部还有结构所以尝试继续解析输出了\n\x07...。这里的\n十六进制 0x0A本身就是一个字段编号为 1类型为LENGTH_DELIMITED的嵌套消息的开始。这很可能是一个设备信息结构体DeviceInfo。3.3 第三步深入挖掘——结合动态 Hook 验证与丰富信息仅凭一个样本的静态分析我们无法确定字段的确切类型比如字段1是 int32 还是 int64和字段名。这时就需要 Frida 出场了。我们的目标是 Hook 住 App 中构造这个登录请求的地方看看在序列化成二进制之前内存中的对象到底是什么样子。定位 Hook 点如果反编译的代码中能看到一些疑似请求的类名如LoginRequest、AuthReq等可以直接尝试 Hook 其toByteArray()方法。如果找不到一个更通用的方法是 Hook protobuf 的基础方法// Frida JavaScript 脚本示例 Java.perform(function() { var ByteString Java.use(com.google.protobuf.ByteString); var MessageLite Java.use(com.google.protobuf.MessageLite); // Hook parseFrom 当App解析服务器响应时触发 MessageLite.parseFrom.overload([B).implementation function(bytes) { console.log(\[*] parseFrom called. Class: \ this.$className); // 打印调用栈有助于定位是哪个业务类在调用 console.log(Java.use(\android.util.Log\).getStackTraceString(Java.use(\java.lang.Exception\).$new())); // 打印原始的二进制数据十六进制 console.log(\Raw bytes (hex): \ ByteString.copyFrom(bytes).toString(\hex\)); // 继续执行原方法 return this.parseFrom(bytes); }; // Hook toByteArray 当App将对象序列化时触发 var toByteArray MessageLite.toByteArray; if (toByteArray) { MessageLite.toByteArray.implementation function() { console.log(\[*] toByteArray called. Class: \ this.$className); console.log(Java.use(\android.util.Log\).getStackTraceString(Java.use(\java.lang.Exception\).$new())); // 尝试将这个对象转成字符串看看如果类实现了toString方法 try { console.log(\Object toString: \ this.toString()); } catch(e) {} var result this.toByteArray(); console.log(\Serialized bytes (hex): \ ByteString.copyFrom(result).toString(\hex\)); return result; }; } });将脚本保存为hook_protobuf.js通过frida -U -f com.target.app -l hook_protobuf.js命令注入进程。触发与观察在手机上再次进行登录操作。观察 Frida 控制台的输出。你可能会看到类似这样的日志[*] toByteArray called. Class: com.target.app.model.LoginRequest Object toString: username: \my_username\ password: \[encrypted]\ version: 150 device: {device_id: \xxx\, os_version: \10\}太棒了这行toString()的输出简直就是“宝藏”。它直接告诉了我们类的完整路径com.target.app.model.LoginRequest字段名username,password,version,device字段名与编号的对应关系结合之前protobuf-inspector的输出我们就能确定字段编号 1 -version(int32)字段编号 2 -username(string)字段编号 3 -password(string)字段编号 4 -device(message, 类型是DeviceInfo)嵌套消息DeviceInfo的内部结构也通过toString()部分揭示了。实操心得动态 Hook 的成功率并非 100%。如果 App 使用了代码混淆类名和方法名会变得毫无意义如a.a.a.c。这时Hook 通用的MessageLite方法依然有效但通过toString()获取字段名的希望渺茫。此时我们需要依赖多样本对比和protobuf-inspector对嵌套消息的递归解析并辅以对 App 行为的理解来猜测字段含义例如一个在登录后才出现的字段可能是session_token。3.4 第四步拼图完成——编写与验证 .proto 文件根据以上所有信息我们可以开始编写初步的.proto文件了。创建 .proto 文件基于我们的发现创建app_protocol.protosyntax proto3; // 假设是 proto3 语法目前更常见 message DeviceInfo { string device_id 1; string os_version 2; // 可能还有其他字段需要更多样本或更深入的Hook来发现 } message LoginRequest { int32 version 1; string username 2; string password 3; DeviceInfo device 4; } // 我们还可以根据响应包定义 LoginResponse message LoginResponse { int32 code 1; string message 2; string user_id 3; string session_token 4; }注意字段编号必须严格对应。数据类型根据protobuf-inspector的 Wire Type 和 Hook 看到的实际值来推断VARINT通常是int32/int64/uint32/bool/enum需要根据数值范围进一步判断。编译与验证使用protoc编译器将.proto文件编译成你所用语言的代码。这里以 Python 为例protoc --python_out. app_protocol.proto这会生成app_protocol_pb2.py。终极测试编写一个简单的 Python 脚本用我们还原的协议来解析最初抓到的二进制包。import app_protocol_pb2 with open(login_request.bin, rb) as f: data f.read() req app_protocol_pb2.LoginRequest() req.ParseFromString(data) # 关键步骤反序列化 print(f\Version: {req.version}\) print(f\Username: {req.username}\) print(f\Password (encrypted): {req.password}\) print(f\Device ID: {req.device.device_id}\) print(f\OS Version: {req.device.os_version}\)如果脚本能成功运行并打印出符合预期的数据那么恭喜你协议还原基本成功如果ParseFromString抛出错误说明你的.proto定义与二进制数据不匹配需要回头检查字段编号、数据类型或嵌套结构是否正确。4. 进阶技巧与疑难问题排查实战中绝不会一帆风顺。下面是一些你可能遇到的“坑”及其解决方案。4.1 字段类型判断陷阱问题protobuf-inspector显示类型是VARINT值是一个很大的数如 4294967295这到底是int32、int64还是uint32解决上下文推断如果是版本号、状态码int32通常足够。如果是数据库主键 ID可能是int64。多样本对比收集该字段在不同请求中的值。如果出现了负数那它一定是sint32或sint64因为 protobuf 的VARINT对负数编码效率低通常会用sint32进行 ZigZag 编码。protobuf-inspector对于 ZigZag 编码的sint32/sint64有时能正确识别并解码有时则不能需要留意其输出提示。动态验证如果 Hook 到了对象尝试修改这个字段的值如设置一个负数再序列化抓包用protobuf-inspector看编码变化是判断类型最准确的方法。4.2 嵌套消息与 repeated 字段问题protobuf-inspector输出中一个LENGTH_DELIMITED类型的值内部又解析出了新的字段这肯定是嵌套消息。但如何区分一个字段是单个嵌套消息还是同类型消息的列表repeated解决观察重复模式如果字段编号在同一个父消息中重复出现那它极大概率是repeated字段。例如你看到输出中有多个5: 2 (LENGTH_DELIMITED) ...那么字段5就是一个repeated string或repeated SomeMessage。分析业务逻辑如果这个接口是返回一个好友列表那么包含多个用户信息的字段自然是repeated。动态修改验证通过 Frida 修改内存中的对象给疑似repeated的字段添加多个元素然后抓包观察二进制结构的变化。4.3 抓包失败或数据加密问题App 使用了证书绑定SSL Pinning或双向 TLS 认证导致 Fiddler/Charles 无法解密 HTTPS 流量抓到的全是Tunnel to或乱码。解决绕过证书绑定使用 Frida 脚本 Hook 掉 App 的证书验证逻辑如OkHttp的CertificatePinnerTrustManager等。网上有大量现成的脚本。使用虚拟机或模拟器在已 Root 的安卓模拟器如 MuMu、夜神中安装用户证书到系统目录可以绕过很多证书绑定。全流量解密如果 App 使用了自定义的加密套件或非标准 SSL 库可能需要更底层的 Hook或者退而求其次不解密 HTTPS只分析其 TCP/UDP 层的 payload如果 payload 本身也被加密了那难度会剧增。问题即使抓到了包password字段也是一串明显的密文如 Base64 编码的二进制数据。解决协议还原和内容解密是两个层面。我们还原的.proto文件定义了“容器”的结构。password字段的类型是string或bytes这没错但它里面装的是加密后的数据。要解密它需要找到 App 内加密的密钥和算法这属于更深入的逆向工程范畴。但至少我们现在知道了该从哪里LoginRequest.password字段去获取密文。4.4 一份常见问题速查表问题现象可能原因排查思路与解决方案protobuf-inspector解析失败报错二进制数据不是有效的 protobuf或已加密/压缩1. 确认抓包导出的是原始二进制。2. 检查数据是否被 Gzip 压缩查看 HTTP 头Content-Encoding。3. 数据可能被额外加密需先解密。还原的.proto能解析请求但无法解析响应请求和响应使用了不同的消息类型定义分别为请求和响应创建不同的 message 类型如LoginReq和LoginResp。它们是完全独立的。Hook 不到toByteArray或parseFrom调用1. 类被混淆。2. App 使用非标准 protobuf 库或自定义序列化。1. 尝试 Hook 更底层的 Java 方法如ObjectOutputStream。2. 搜索是否使用了其他序列化框架如 FlatBuffers。3. 关注protobuf-inspector的输出如果结构清晰可暂不依赖 Hook。字段含义不明缺乏业务上下文1. 结合 App 界面显示猜测如返回一个数字后用户昵称改变该数字可能是 userId。2. 对比不同用户、不同操作下的数据包找差异点。3. 搜索字符串常量也许能在反编译代码中找到线索。编译.proto时提示字段编号冲突同一个 message 内字段编号重复仔细检查protobuf-inspector的输出确认是否有重复编号被误判为不同字段。确保.proto文件中编号唯一。5. 从还原到应用让协议为你所用成功还原出.proto文件不是终点而是起点。现在你可以做很多有趣且有用的事情构造请求模拟客户端使用生成的pb2代码你可以用 Python 等语言轻松编写脚本自动完成登录、查询、提交等操作实现自动化测试或数据采集。解析响应监控数据实时解析服务器的响应用于监控接口状态、分析业务数据流。协议模糊测试通过修改生成的请求消息中的字段构造畸形或异常数据对服务器进行模糊测试寻找潜在的安全漏洞。辅助逆向分析在动态调试时能够将内存中的二进制数据快速反序列化成可读的对象极大提升分析效率。最后我想说逆向解析 protobuf 协议是一个需要耐心、细心和一定经验积累的过程。它没有一成不变的公式更像是一种在静态分析、动态调试和逻辑推理之间不断切换的“侦探艺术”。最重要的不是记住所有工具命令而是理解 protobuf 的编码原理Varint、ZigZag、Field Number Wire Type并形成一套自己的分析流程抓包取证 - 静态搜索 - 黑盒解析 - 动态验证 - 假设重构 - 测试确认。每成功还原一个复杂的协议你对网络通信和数据编码的理解都会深一层。希望这份结合了实战细节和心得的指南能成为你下次遇到“二进制乱码”时手边最有力的参考。