网络协议分析实战：从抓包、静态分析到协议还原的完整拆解

简介网络协议分析与逆向是理解未知通信机制的核心技能本次提供的压缩包聚焦协议逆向方法并延伸至微信协议研究。内容源自法国学者Georges Bossert与Frédéric Guihéry开发的协议分析工具相关资料同时包含香港中文大学关于微信协议分析的PDF论文适合安全研究员、协议逆向工程师以及对微信通信原理感兴趣的开发者。压缩包属于zip格式整体大小约3.11MB其中可明确识别的文件类型为PDF论文文件总数与逐项明细在下载页暂未公开。目前已有1387人学习读者从中可梳理协议逆向的整体思路了解工具的设计与应用方式并通过论文获取微信协议在数据包结构、通信流程及安全机制方面的具体剖析有助于后续开展网络流量解析、接口测试和安全性评估等工作。1. 三座山、一条主线网络协议分析的又一次拆解协议逆向最容易被低估的不是加密而是“找差异”。这是我做完一次针对某 IM 类 App也就是资源标题里“微信协议分析”那个方向的完整拆解之后最大的感受。整场复盘下来真正花时间的不是解包而是在一堆看起来几乎一模一样的流量里找出谁在变、谁没变、谁负责校验。网络协议分析从来不是打开抓包工具那一刻开始的它由三座山组成抓包链路、静态分析和协议还原。这篇就按这条主线把每一步的判断依据、工具与命令、以及踩坑记录一次讲清楚。给两类人看做 App 安全评估的和刚准备入行协议逆向的新手。读完你至少能分清一个未知协议的突破口应该从哪里找。2. 抓包入口先定通道再动手工具与命令一次讲清2.1 开始抓包前先分清目标 App 走哪条链路很多新手拿到一个 App第一件事就是打开抓包工具然后盯着空荡荡的列表发呆。我自己的固定习惯是先花 15 分钟想清楚“业务在什么时候会产生数据”再决定用什么姿势抓。IM 类 App 几乎都是两条链路并存的短连接走 HTTP/HTTPS负责登录、资料、列表这类请求响应长连接走自定义 TCP负责消息推送、心跳、状态同步。这两条链路对应完全不同的抓包策略选错了入口后面的时间基本白费。判断目标走哪条链路有三个低成本信号。第一看应用启动后有没有周期性的小包出现这种基本都是心跳是自定义长连接的存在证据第二看传输端口是不是 80/443 之外的高位端口比如 8080、8000、9000 这类大概率是私有协议入口第三看抓到的包体里有没有直观的 JSON 字段全是二进制头和不可读内容就别指望 HTTP 工具帮你解析了。把这个判断做在前面后面的命令和工具才有意义。链路类型典型特征适合观察什么HTTP/HTTPS 短连接URL 路径清晰、方法为 GET/POST业务动作、参数变化、登录态传递TCP 自定义长连接固定端口、心跳包、二进制头消息推送、状态同步、协议字段结构这个表是我每次抓包前必看的。先定链路再选工具顺序反了就会陷入“抓到一大把东西但什么也说明不了”的窘境。2.2 两个抓包入口怎么选模拟器和真机的取舍抓包入口无非两个模拟器环境和真机环境。两者的差别不是简单换个设备而是决定了你能不能顺利装上证书、能不能稳定复现行为。模拟器的优势在于系统环境可控证书安装和重启恢复都容易版本回滚也快缺点也明显某些 App 会检测模拟器特征出现“在模拟器上死活不产生业务流量”的情况。真机的优势是行为真实但系统级证书安装门槛高一旦校验失败排查成本也高。我一般会这么选第一次接触未知 App优先模拟器因为上手快能迅速判断协议是什么形态等到需要验证字段真实性和校验机制时再切回真机做对照。这个顺序能减少环境因素干扰把注意力先集中在协议本身。入口选的判断依据就这么简单——先求跑通再求真实。2.3 抓包三步走从命令到过滤条件链路和入口确定后实际抓包可以压成三步。第一步确认网络连通保证手机或模拟器与抓包机在同一网段能互通第二步启动抓包命令把流量落盘第三步用带界面的工具打开结果按条件过滤把目标流量从噪声里挑出来。# 抓取 tcp 80/443 端口的流量保存为 pcap 文件 # -i eth0 指定抓包网卡-s 0 表示不截断包长度避免丢失字段细节 # -w 参数把原始包写入文件方便后续离线分析 tcpdump -i eth0 -s 0 -w target.pcap tcp port 80 or tcp port 443这条命令适合起步场景。真正复杂的长连接协议建议扩大端口范围同时把写入文件的格式保持为 pcap方便后续在图形界面里过滤。抓完后的过滤条件同样关键先用 IP 缩小范围再叠加端口和协议类型ip.addr 192.168.1.100 (tcp.port 8080 || tcp.port 443) tls先按 IP 过滤是因为同一网段往往有大量广播包IP 能把范围缩小到目标设备再按端口过滤是因为同时跑的连接很多端口是最稳定的区分特征最后按协议类型过滤是确认链路形态。这三层过滤下来基本就是一条干净的协议流。过滤器写不对十有八九是条件太宽把一堆无关包也圈进来了。2.4 工具怎么挑别被“看得见”骗了选抓包工具我踩过不少坑。有一类带界面的工具看起来很直观打开就能看到请求列表但碰到自定义 TCP 协议就彻底失明所有二进制包全部堆成一坨乱码过滤功能也不够灵活反而是命令行抓包加图形分析组合能覆盖的场景更广。工具类型强项不足命令行抓包原始流量完整、可脚本化、资源占用低上手门槛高过滤语法要学图形界面分析可视化过滤、协议解码直观、导出方便对私有协议解码能力弱大文件容易卡应用层抓包类直接呈现业务字段和参数只认 HTTP 类协议长连接直接失灵还有个玄学问题必须提IPv6 流量在部分工具里默认不展示导致你以为某个功能压根没有网络请求实际上流量早就走了 IPv6 通道。排查不明原因“缺包”时先把 IPv6 显示关掉或单独过滤一次往往能发现问题出在哪里。判断一个抓包方案好不好用就看两点协议解码能力够不够全过滤条件能不能精准框住目标源和端口。3. 静态分析别急着看内存先翻字符串和算法常量3.1 拿到安装包后先做三件事静态分析不是一上来就开反编译工具瞎看而是从安装包本身找线索。我拿到一个待分析的安装包固定做三件事解包看结构、查壳、导字符串。解包是为了看代码是集中在 dex 里还是分散在多个模块里查壳是为了知道里面代码能不能直接读还是需要先脱壳处理导字符串则是快速建立对协议特征的初步印象。这三步做完基本能判断这个 App 的协议分析难度在哪一档。导字符串是个容易被低估的动作。协议相关的算法常量、URL 路径、甚至字段名都会以可读字符串的形式留在 native 库里用命令直接筛# 从 native 库里导出可打印字符串粗筛加密算法与接口路径 # -i 忽略大小写方便同时匹配 AES/aes 这类差异 strings libcore.so | grep -iE aes|md5|sha|/v[0-9]/|protocol看到的内容是线索不是结论。如果字符串表里有 AES、SHA 这类算法名说明本地可能存在整体加密或签名校验如果出现 protocol、message、encode 之类词汇说明协议栈是自研的后面得花更多精力在字段结构上。反过来如果什么都搜不到大概率是壳把字符串处理过先脱壳再说。这一步的输出直接决定你用什么姿势进入下一步。3.2 识别加密与校验的两条路常量与交叉引用识别包体用了什么加密算法有两条路一条是常量匹配即根据 AES、MD5、SHA 这类特征常量定位代码位置另一条是交叉引用反编译时跟踪关键函数被谁调用顺藤摸瓜找到深层数据流。常量匹配适合快速过滤交叉引用适合确认逻辑。识别方法适用场景判断依据常量匹配快速粗筛、定位可疑函数代码里出现算法标准常量或固定的 iv/key 值交叉引用确认调用链、判断作用域被调函数传入的数据来自哪个 buffer、结果流向哪我一般会这么处理先用常量匹配把可疑位置全部标出来再用交叉引用逐个确认这个算法到底是用来加密包体还是只做了本地文件校验。两者的区别决定后面协议还原的工作量——如果只是本地校验那跟线上包体无关浪费时间研究就是走偏了。3.3 静态分析之后强制做一次回溯验证静态分析最容易犯的错是看着代码路径就以为抓到了协议真相。判断代码里哪一条路径真正被线上执行唯一的方法是回到抓包结果里对一遍。我拿模拟项目 X 做过一次复盘静态分析时推断包体是裸 JSON结果回溯流量时发现实际数据是一层自定义 TLV 结构嵌套JSON 只是最外层展示。这种偏差不回溯根本发现不了。回看抓包结果的步骤也很简单先找一个已知业务动作的完整请求把静态分析得到的字段字典逐项比对看看每个字段是否能在流量里找到对应位置。能对上说明分析方向正确对不上就回到反编译代码里重新定位。强迫自己做完这次回溯能避免把大量时间浪费在一个错误的假设上这个习惯直接决定协议分析是三天收工还是三个星期打转。4. 协议还原黑匣子变白盒从字段字典到重放脚本4.1 协议还原的四个观察维度抓包和静态分析解决的是“流量长什么样、代码里写了什么”协议还原要回答的是“每个字节负责什么”。我的做法是取同一种业务动作的多个样本把它们摆在一起逐字节对照。对照时固定看四个维度长度、类型、序号、校验。长度决定包体边界类型决定这个包属于哪种业务序号负责时序校验负责完整性。这四个维度里序号是最容易被当成加密高地的字段——其实它往往就是普通时间戳或递增值。对照样本时把差异字段单独拎出来看哪些字段在每次请求里都变哪些不变。每次都变的通常是序号、时间戳或随机值几乎不变的可能是业务类型或版本号规律性变化的基本就是校验和或加密块。把这套观察整理成字段字典协议就从黑匣子变成了有结构的东西。下面是一个简化的字段字典样例类似格式我会在每个协议分析项目里建一份偏移长度字段名变化规律0-12包类型固定值区分业务动作2-54包长度随 payload 长度变化6-94序列号每次请求递增10-134时间戳秒级时间14不定payload有加密特征需继续分析4.2 从样本包到重放脚本第一个可执行原型字段字典有了就可以构造第一个重放脚本。写重放脚本的目的不是直接打线上流量而是在自建环境里验证字典对不对。下面这段代码是重放脚本里最核心的一块它按字段字典构造协议包并发送。import socket import struct import time s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(5) host 192.168.1.100 port 8080 # 按字段字典组包2字节类型 4字节包长 4字节序号 4字节时间戳 变长payload pkt_type 0x0101 # 包类型来自字典第一行 seq int(time.time()) 0xFFFFFFFF # 序号字段用当前时间取整模拟递增 timestamp int(time.time()) payload bhello_protocol length 2 4 4 4 len(payload) # 大端序打包避免字节序不一致导致服务端解析错位 header struct.pack(HIII, pkt_type, length, seq, timestamp) packet header payload s.connect((host, port)) s.send(packet) # 先读 10 字节头部类型2 长度4 序号4再按长度读取 body resp_head s.recv(10) if len(resp_head) 10: resp_type, resp_len, resp_seq struct.unpack(HII, resp_head) print(回包类型, hex(resp_type), 长度, resp_len, 序号, resp_seq) s.close()这里的HII是大端序格式H 表示 2 字节无符号整数I 表示 4 字节无符号整数顺序对应类型、长度、序号。时间戳字段直接用当前秒级时间是为了先验证“服务端是否认可动态时间戳”这一假设。脚本跑通之后再逐步替换 payload 内容观察服务端的拒绝和接受条件。第一步跑通时 payload 通常故意用固定内容避免变量太多影响判断。4.3 重放不是目的检验字段变化才是重点说句血泪经验重放脚本写出来不难难的是通过改字段看懂服务端校验逻辑。常见误区是一上来就改 payload发现被拒就以为是加密没破解其实服务端最先校验的往往是序号和时间戳这两个字段错了包根本进不到业务层。做字段敏感性测试时一次只改一个字段是最好的习惯。具体做法是准备两组包一组原样重放一组只改动目标字段然后对比回包差异。比如只把时间戳改成固定值如果服务端直接断开连接说明时间戳参与校验如果把包类型从 0x0101 改成 0x0102回包字段结构变化明显说明包类型决定了业务分支。一轮测下来每个字段的职责就能标清楚。服务端校验的强度分布往往不均匀很多系统只认真校验了序列号对 payload 内容反而宽容这种不对称就是协议分析的突破口。5. 协议分析的避坑与排查五条踩坑记录与通用顺序5.1 五条踩坑记录协议分析里翻车最多的几个地方我按“现象 → 原因 → 解决”的方式整理出来都是真实发生过的问题直接对着排查比自己从头试要快得多。踩坑一抓包十分钟列表里一条流量都没有。现象工具开着设备也连上了业务操作也做了但列表空空的。原因过滤条件写死在了 80/443 端口而目标 App 的长连接跑在 8080 端口所有流量都被条件挡在了外面。解决先把过滤条件里端口相关的部分去掉全局抓一把再按“端点”统计看这个设备到底访问了哪些端口确定真实的协议端口后再回去改条件。踩坑二HTTPS 包能抓到但内容全是乱码。现象TLS 握手都看到了就是解密不出业务字段。原因App 校验了证书指纹不接受系统里后装的证书导致中间人链路没生效。解决把抓包证书安装到系统证书目录而不是用户证书目录同时确认目标 App 没有单独的证书锁定逻辑。确认锁定的最快方式是改一份错误配置看它是否立刻断开。踩坑三重放一次就被断开怀疑人生。现象构造好的包发过去服务端直接断连连错误码都没有。原因seq 字段写死成了固定值服务端发现序列号重复或回退判定为无效包。解决构造包时让序号随时间递增先别动其他字段同时检查时间戳是否与服务端时区一致时区偏差也会造成类似问题。踩坑四反编译看到的是 AES流量里却是纯明文。现象静态分析圈定了一个加密函数代码逻辑也看着像但抓包结果里字段直接可读。原因加密只作用于本地存储或某些特殊接口真正走业务协议的那条通道根本没调用这个函数。解决用交叉引用查清函数调用链确认加密数据流向哪个 socket 写入点别困在一个局部结论里出不来。踩坑五抓包文件和重放脚本对不上。现象脚本里按字段字典组包发包后服务端一直无响应回头查抓包文件发现包体比字典多出 4 个字节。原因字段字典漏掉了头部后面的扩展位或者服务端在包头之外另有固定字段。解决重新逐字节对照最近一次抓包文件把每个偏移位的值填进字典再核一遍这个动作看着枯燥但能救回半天调试时间。5.2 排查顺序从链路到校验踩坑踩多了我总结出一套固定的排查顺序链路 → 时间 → 校验 → 设备唯一标识。链路不通后面全是空谈链路通了但重放失败先看时间戳和序号这类时序字段时序没问题再怀疑校验算法最后才是设备信息类的唯一标识问题。这四步里链路问题最容易被环境因素掩盖时序问题最难一眼发现校验问题往往要回到静态分析里找答案。排查层常见症状常见结果链路无流量 / 一个方向有包端口过滤错误、证书未生效时间重放后立刻断开时间戳回退、时区不一致校验包能通但拿不到业务回包序号字段写死、校验位置算错设备标识同包换设备失败存在设备指纹绑定需模拟固定 ID5.3 合规边界提醒讲到这里必须把话说明白协议分析与逆向应当只用于自己的学习环境、爬虫行为评估和有授权的安全测试不能绕过登录态、不能批量抓取他人隐私数据、更不能借协议分析做外挂和灰产。我写这篇的方向是“把思路讲清楚把边界画明白”重放脚本的价值在于验证字段字典而不是教你绕过某个服务的限制。做协议分析的人先守住这条线技术才有长期价值。6. 最后一块拼图一份协议分析的验证清单做完一次完整的协议分析不是以“脚本能发包”为终点而是以“能复现、能解释、能传给下一个人”为标准。我现在每次收尾都用一套固定清单逐项打勾才敢说这个协议看懂了。验证项通过标准抓包链路捕获 10 分钟流量业务动作样本不少于 3 组链路确认已区分短连接与长连接端口和协议类型明确标注静态分析已导出字符串表圈出算法候选并完成交叉引用核对字段字典每个字段都标了偏移、长度、职责和变化规律重放验证自建环境里 3 次重放通过序号随时间递增回溯对照字典字段与真实流量逐字节吻合无遗漏字节这份清单看起来很基础但它恰恰能挡住大多数翻车。我见过太多分析做到一半就陷进“这个字段是不是加密”的死胡同里回头一看连最基础的端口都没确认。清单的顺序就是我前面讲的整条主线先打通链路再做静态分析然后还原字段最后用重放验证。每次做完六项心里才踏实。回到开头那句话协议分析真正的难度不是解包而是把一堆相似流量里藏着的规律找出来。把这个规律记录成字段字典、验证成可重放脚本你手里这份网络协议分析资料才算真正变成了自己的东西。从那以后我每次拿到陌生协议都会强制自己先建字典、再做对照再急也要走完这条路径希望这篇经验能帮你少走几趟弯路。本文还有配套的精品资源点击获取