第32章网络协议逆向（一）

课程目录第32章网络协议逆向（一）

第32章：网络协议逆向（一）：Wireshark抓包分析、TCP/UDP协议基础

说实话，搞逆向这么多年，我越来越觉得网络协议分析是门必修课。不管你是分析恶意软件、调试通信协议，还是做物联网设备破解，最终都绕不开一个东西——抓包。

这一章，咱们就从最基础的Wireshark抓包开始，把TCP和UDP这两个传输层协议彻底搞明白。嗯，我保证不堆砌理论，全是实战中能用上的东西。

32.1 为什么逆向工程师必须懂网络协议？

你可能觉得，逆向不就是反汇编、看汇编代码吗？跟网络有什么关系？

我举个例子。几年前我分析过一个IoT设备，固件解包后全是二进制，静态分析半天没头绪。后来我架了个Wireshark，发现设备启动后不断向某个IP发送加密数据包。顺着这个线索，我找到了它的通信密钥——整个逆向过程，网络协议分析起了决定性作用。

说白了，网络协议是应用程序的“对外接口”。你逆向一个程序，如果看不懂它在网络上发什么、收什么，那你就只看到了冰山一角。

32.2 Wireshark 抓包基础

Wireshark 是网络分析界的瑞士军刀。免费、开源、功能强大。我个人的习惯是，只要遇到网络通信相关的逆向任务，第一件事就是开Wireshark抓包。

32.2.1 安装与启动

Windows、macOS、Linux都有对应的安装包。安装时注意勾选“安装WinPcap/Npcap”，这是底层抓包驱动。我曾经遇到过装完Wireshark但抓不到包的尴尬，最后发现是Npcap没装好。

32.2.2 抓包过滤器 vs 显示过滤器

这两个概念容易混淆，我简单说清楚：

抓包过滤器：在抓包前设置，只抓符合条件的包。语法简单，但一旦设置就不能改。
显示过滤器：抓完包后，在结果中筛选。语法更丰富，可以随时调整。

实战中我一般先用抓包过滤器缩小范围，再用显示过滤器精确定位。比如：

# 抓包过滤器：只抓80端口（HTTP）
port 80

# 显示过滤器：只显示源IP为192.168.1.1的HTTP请求
ip.src == 192.168.1.1 and http

小技巧： 如果你不确定目标程序用哪个端口，可以先不设过滤器，全量抓几秒钟，然后看“Protocol”列，哪个协议出现频率高，就重点分析哪个。

32.2.3 跟踪流（Follow Stream）

这是我最常用的功能。右键点击任意一个TCP包，选择“Follow” → “TCP Stream”，Wireshark会自动把整个会话的数据拼接起来，以ASCII或Hex形式展示。

为什么要用这个？因为很多协议的数据是分多个包传输的。你一个个看，根本看不出完整内容。跟踪流直接给你“对话记录”，省事多了。

32.3 TCP协议基础

TCP（传输控制协议）是面向连接的、可靠的传输协议。说白了，它保证你发的数据对方一定能收到，而且顺序不乱。

32.3.1 三次握手

TCP建立连接需要三次握手。这个你肯定听过，但你真的在Wireshark里看过吗？

SYN：客户端发送SYN包，表示“我要连接你”。
SYN-ACK：服务器回复SYN-ACK，表示“收到，我准备好了”。
ACK：客户端再发ACK，表示“好的，开始通信”。

在Wireshark里，你看到的前三个包就是这三个。如果只有两个（比如只有SYN和RST），说明连接被拒绝了——这在逆向分析中经常遇到，比如目标服务器只允许特定客户端访问。

32.3.2 四次挥手

断开连接时，需要四次挥手：

主动方发FIN
被动方回ACK
被动方发FIN
主动方回ACK

嗯，这里有个坑。我曾经分析一个程序，发现它断开连接时只发了FIN，没有收到对方的FIN-ACK。后来发现是程序异常退出，没有正常关闭socket。这种“半关闭”状态在逆向中很常见，说明程序可能被kill了或者有bug。

32.3.3 序列号与确认号

TCP的可靠性依赖于序列号（Seq）和确认号（Ack）。每个字节都有一个序列号，接收方通过确认号告诉发送方“我收到了哪些字节”。

在Wireshark里，你可以看到：

Seq = 1, Ack = 1
Seq = 1, Ack = 1450
...

如果发现序列号跳跃很大，或者确认号不连续，说明有丢包重传。这在分析网络性能问题时很有用。

32.4 UDP协议基础

UDP（用户数据报协议）就简单多了。无连接、不可靠、不保证顺序。说白了，就是“发了就不管了”。

你可能会问：那为什么还要用UDP？

因为快啊。实时性要求高的场景（比如视频通话、游戏、DNS查询），用TCP的握手和重传机制反而会卡顿。UDP丢几个包无所谓，只要整体流畅就行。

32.4.1 UDP报文结构

UDP头部只有8个字节：

字段	长度	说明
源端口	2字节	发送方端口
目的端口	2字节	接收方端口
长度	2字节	UDP头部+数据的总长度
校验和	2字节	可选，用于检测数据是否损坏

在Wireshark里看UDP包，你会发现没有序列号、没有确认号、没有握手。数据直接扔在“Data”字段里。逆向分析UDP协议时，你只需要关注端口和载荷内容。

32.4.2 实战：分析一个UDP游戏协议

我记得有一次分析一个手机游戏，它用的是UDP通信。抓包后发现，每个包的前4个字节是一个魔数（0xDEADBEEF），后面跟着操作码和参数。通过对比不同操作（移动、攻击、聊天），我逐步还原了整个协议格式。

这个过程其实不复杂：

抓包，过滤出目标IP和端口
观察每个UDP包的载荷，找规律
改变游戏行为，看哪些字段变化
逐步推断出字段含义

  核心思路： 协议逆向的本质就是“找规律”。无论协议多复杂，最终都是字节流。你只要找到哪些字节是固定的、哪些是变化的、变化和什么行为相关，就能一步步还原。

32.5 TCP vs UDP：如何选择？

在逆向分析中，你不需要替开发者做选择，但你需要知道为什么他们选了某个协议。这能帮你更快理解程序的行为。

特性	TCP	UDP
连接	面向连接	无连接
可靠性	可靠（重传、确认）	不可靠（尽力而为）
顺序	保证顺序	不保证顺序
速度	较慢（有开销）	较快（无开销）
典型应用	HTTP、FTP、SMTP	DNS、VoIP、视频流

如果你在Wireshark里看到大量TCP重传包，说明网络质量不好，或者程序对可靠性要求很高。如果看到UDP包频繁丢失，但程序依然正常运行，说明它做了应用层的容错处理——这在逆向时值得注意。

32.6 知识体系总览

下面这张图总结了本章的核心知识结构。我建议你把它当作一个“地图”，随时回来对照。

32.7 避坑指南

我曾经踩过的坑：

抓包时忘记关闭防火墙：Windows防火墙默认会拦截很多端口，导致抓不到包。建议先关闭防火墙或添加例外规则。
混淆了源端口和目的端口：在Wireshark里，源端口是发送方的，目的端口是接收方的。分析时一定要搞清楚数据流向。
忽略了校验和错误：如果Wireshark显示“Checksum offloading”，说明网卡硬件计算了校验和，但Wireshark抓到的包是未计算前的，所以显示错误。这不是真的错误，可以忽略。

32.8 本章小结

这一章我们讲了Wireshark的基本用法、TCP和UDP的核心概念。说实话，这些只是网络协议逆向的入门。但基础打牢了，后面分析HTTPS、自定义协议、甚至加密协议时，你才能游刃有余。

我个人建议你立刻打开Wireshark，抓一下自己电脑上的网络包。看看浏览器访问网页时的三次握手，看看DNS查询时的UDP包。亲手操作一遍，比看十遍教程都管用。

嗯，下一章我们会深入分析一个真实的自定义协议，到时候你会看到这些基础知识是怎么派上用场的。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录