CTF圈子里有个默认共识：Misc是新手最容易上手的方向，但同时也是最容易“一看就会、一做就废”的题型。尤其是流量分析，很多刚入门的同学拿着pcapng文件，打开Wireshark之后看着满屏花花绿绿的包，脑子一片空白，不知道从哪下手。这篇文章我想用一次实战Writeup的形式，把流量分析这类题目的完整思路、Wireshark的核心玩法以及我踩过的坑一次性讲清楚。内容会照顾到纯新手，也会给有一定基础的朋友补充一些平时文档里不会写的细节。
先说清楚：这篇文章适合谁？如果你是CTF新手，想在Misc方向建立信心，流量分析一定是最值得投入的题型——它不像逆向和Pwn那样门槛高，也不像Web那样需要掌握大量框架漏洞，只要会看包、会追踪流、会用过滤器，配合一点编码基础和文件结构知识，就能解决大部分题目。如果你已经打过几场比赛，这篇文章也能帮你整理一套更高效的做题流程，尤其是面对那些“流量包巨大、flag藏得刁钻”的情况，一套清晰的排查顺序比盲目翻包管用得多。
1. 这类题到底在考什么：流量分析的四种核心套路
先说一个新手最容易产生的误区：以为流量分析就是“打开Wireshark，肉眼找flag”。实际上，CTF里的流量分析题，考的不是你抓包的能力（那叫渗透测试），而是分析已有流量包的能力。出题人预先构造好一次或多次网络通信过程，把flag藏在这个过程里，你的任务是通过分析数据包，还原出这个通信过程，找到flag。
我总结了一下，90%以上的流量分析题跑不出下面四种套路：
套路一：明文传输直接暴露flag。这是最简单的一类，HTTP协议、FTP协议、Telnet协议里直接传递了包含flag的字符串。比如一个POST请求里带着flag=xxxxx，或者一份下载的文件名就叫flag.txt。这类题目的难点不在找flag，而在过滤器的使用效率——你要能快速从几千个包里筛出含有关键字的那个。
套路二：隐藏文件提取。流量里传输了图片、压缩包、文档等文件，flag藏在文件内容里。常见的考法有：用wget下载的图片实际上是张PNG，binwalk跑一下发现尾部还有隐藏的zip；或者HTTP响应里嵌了一张二维码图片，扫一扫就是flag。这类题目的本质是文件提取和文件分析。
套路三：编码与加密数据还原。通信过程中用Base64、URL编码、十六进制等方式对flag做了处理，或者使用简单的异或、栅栏密码等古典加密。你需要在流量里找到这些编码后的字符串，然后做解码。有些题目会做得更隐蔽，比如把flag拆成多段，分散在多个包里。
套路四：协议交互过程还原。这是进阶玩法，需要你对各种网络协议本身有了解。典型的有：通过TCP流重组还原聊天记录；通过USB流量分析键盘敲击；通过DNS查询记录还原恶意通信内容；甚至是通过蓝牙、Wi-Fi管理帧等冷门协议传递信息。
拿到一道题，先别急着乱翻，花30秒判断它属于哪一类，这会直接决定你的排查方向。我自己的习惯是先用下面这个顺序快速预判：看包大小分布、看协议统计、看有多少TCP流、看有没有明显的大包（通常是文件传输）。这一步做完，基本能猜出题目的大致考点。
2. Wireshark核心技能：过滤器才是流量分析的真正武器
很多新手学Wireshark，上来就学怎么抓包，结果抓了一堆无关流量，反而把自己绕晕了。CTF流量分析是分析已有的包，核心技能不是抓包，而是过滤和追踪。我把最常用、最高频的滤镜语法整理成了一套“CTF专用速查表”，这套东西我在实际做题时反复用到，比背一整本Wireshark手册实用得多。
2.1 显示过滤器的黄金三件套：IP、端口、协议
Wireshark的显示过滤器（Display Filter）就是用来筛选你关心的包的，最基础的就是这三类：
按IP筛选：
ip.src == 192.168.1.1或ip.dst == 192.168.1.1，也可以用ip.addr == 192.168.1.1同时匹配源和目的。做题的时候多数用ip.addr，因为你往往不确定flag是在请求还是响应里。按端口筛选：
tcp.port == 80、tcp.dstport == 8080。HTTP默认80，HTTPS默认443，FTP默认21，SSH默认22。看到奇怪的端口要敏感，CTF里出题人常把服务跑在非常规端口上，比如8888、1337这种。按协议筛选：
http、dns、ftp、tcp、udp直接输入协议名即可。做这种题，我会直接看http，因为绝大多数流量分析题都以HTTP协议为主角。
实际做题时，这几个条件经常组合使用，比如ip.src == 10.0.0.1 && http && tcp.port == 80。
2.2 关键字检索：Ctrl+Alt+Shift+T和Ctrl+F的组合拳
如果题目明确告诉你flag格式（CTF比赛一般约定为flag{...}、ctf{...}），最暴力的思路就是在流量里直接搜这个字符串。Wireshark支持在数据包字节里搜索字符串，快捷键是Ctrl+Shift+F（macOS上略有不同），搜索类型选择“String”，搜索范围选“Packet details”、“Packet bytes”或者“Packet list”。
但这里有个坑，很多新手搜flag{搜不到，因为数据可能被URL编码过（flag%7B）、可能是Base64（ZmxhZ3s=）、可能是十六进制（666c61677b）、甚至可能是分片传输。所以我会用两个交叉验证的方法：
- 先用
Ctrl+F搜“flag”这个单词本身，能搜到就顺藤摸瓜。 - 搜不到就搜
http.request或http.response，把所有HTTP请求/响应列出来，逐个看参数名和URI，flag往往藏在这些地方。
另外强烈推荐Ctrl+Alt+Shift+T（或者右键Follow -> TCP Stream），这个功能可以把整条TCP流的内容重组还原出来，相当于把一次完整的HTTP通信内容（包含请求头和请求体）原样呈现，比在包列表里一格一格看高效得多。流量分析题里，80%的flag都能在“Follow TCP Stream”之后的文本里找到。这个操作太常用了，我一度把它叫“流量分析一把梭”，因为很多题目真的就是点开流、复制文本、找flag三步走。
2.3 统计工具：不点白不点的Protocol Hierarchy
Wireshark的“Statistics -> Protocol Hierarchy”能显示所有协议的层次结构和流量占比。这对我来说是做题的第一步：先看这个文件里到底有什么协议。有些题目会故意塞入大量ARP广播包作为噪声，真正的通信只在某几条TCP流里；也有的题目混杂了HTTP、DNS、ICMP，但flag藏在ICMP的payload里。看一眼协议统计，心里就有数了。
类似的还有“Statistics -> Conversations”，能看到各个IP对之间的通信流量大小。如果发现某条TCP流传输了好几MB数据，而其他流只有几百字节，那这个“异常大”的流十有八九藏着文件传输，值得单独追踪。
2.4 抓包过滤器vs显示过滤器，别搞混了
刚入门的朋友容易混淆这两个概念。抓包过滤器（Capture Filter）是在抓包之前设置的，意思是“只抓我关心的流量”，作用是节省磁盘空间，但你不做现场抓包，根本用不上。显示过滤器（Display Filter）是抓完或打开pcapng之后用的，作用是“从已有流量里挑我想要的”。CTF流量分析题只需要掌握显示过滤器，抓包过滤器了解即可。
3. 实战Writeup：从打开数据包到拿到flag的完整过程
下面我用一道模拟题来完整演示做题流程。这道题是我按照CTF Misc流量分析题的常见套路设计的，融合了HTTP传输、Base64编码和图片隐写三个考点，练完这道题，你已经能应对相当一部分流量分析题目了。
3.1 题目描述与初始侦查
下载下来的文件叫capture.pcapng，没有任何题目描述，只有一句话：“某黑客攻陷了一台服务器并下载了机密文件，请找到文件中的flag。”
第一步，打开文件，按Ctrl+Shift+E查看协议统计（或者Statistics -> Protocol Hierarchy）。我看到的统计结果是：ARP占了大量包（典型的干扰项），然后就是HTTP协议，集中在192.168.1.105和192.168.1.1之间。再查看Conversations，发现这两个IP之间只有两条TCP流，其中一条传输了约2MB数据。
到这里我就形成了一个初步判断：2MB的数据大概率是文件下载，聚焦这条TCP流。
3.2 过滤HTTP请求与TCP流追踪
输入显示过滤器http，把所有HTTP包列出来。Wireshark会自动标记HTTP请求（GET/POST）和响应（200 OK）。我快速浏览了一下请求URI，果然看到一个可疑的GET请求：
GET /secrets/flag.zip HTTP/1.1注意，有些题目并不会把文件名起得这么直白，可能是/download/abc123，也可能是/upload/file.php这类伪装路径，所以不能光看URI猜测，还是要配合TCP流追踪来确认内容。
右键这个HTTP请求包，选择“Follow” -> “TCP Stream”。此时弹出一个窗口，显示重组后的HTTP报文。最底部有一段乱码——不对，仔细看，是一串Base64字符串。这个字符串开头是UEsDBBQACAgIAA...，我立刻反应过来：UEsDB是ZIP文件的Base64编码开头（ZIP文件的十六进制文件头是50 4B 03 04，Base64编码后就是UEsDB）。
这里有个小知识点，识别Base64编码的文件内容，最靠谱的方法是看开头的几个字符，根据Base64编码规则，常见的文件类型会有固定的可见前缀。比如UEsDB是ZIP，iVBORw0KGgo=是PNG，/9j/4AAQ==是JPEG。这个方法比“把Base64全部解码再去识别”快得多。
3.3 Base64解码与文件头识别
把这段Base64字符串复制出来，用Python或者在线工具解码。我习惯用Python，因为后续还要做文件分析和隐写提取，一条龙解决：
import base64 b64_data = "UEsDBBQACAgIAA... 完整Base64字符串粘贴到这里" with open("flag.zip", "wb") as f: f.write(base64.b64decode(b64_data))解码出来的flag.zip用file命令验证，确认是ZIP压缩包。直接unzip flag.zip，如果顺利的话，里面应该就是flag文件——但实际CTF题里往往不会这么顺利，这是全题的第一个坎：解压需要密码，或者压缩包本身被做了伪加密处理。
3.4 伪加密破解：ZIP伪加密的判定与修复
这题里，unzip提示需要密码。我先尝试了弱密码（123456、admin、flag），全部失败。然后检查ZIP的加密标志位：
binwalk flag.zipbinwalk没有检出明显的附加数据。接着用16进制编辑器打开zip文件，检查flag.txt对应的条目头。ZIP文件条目头中有一个关键字段：通用位标志（General Purpose Bit Flag），位于文件头偏移4字节处，占2个字节。如果这个值的十六进制是09 08，说明是伪加密；如果是09 00，说明是普通加密。
我看了一下，这个ZIP条目的通用位标志是09 08，而00 08才是真加密。所谓“伪加密”，就是出题人手动把00改成了09，骗过了解压软件，其实根本没有加密。修复方法很简单：把09 08改回00 08，保存后直接解压。
# 用Python修复伪加密 with open("flag.zip", "rb") as f: data = bytearray(f.read()) # 找到通用位标志并修改 data[4] = 0x00 # 具体位置依文件而定 with open("flag_fixed.zip", "wb") as f: f.write(data)改完后再解压，这次成功拿到了flag.txt。你以为到这里就完了？我打开flag.txt，发现里面写的是一段Base64：ZmxhZ3t3aXJlc2hhcmsuY29tX2lzX2Z1bn0=。再解码，得到flag{wireshark.com_is_fun}。
到这里才算是完整的一题。这道题里包含了流量分析最常见的两个隐藏点：一是Base64编码隐藏在TCP流中，二是ZIP伪加密，两个考点任何一个没有经验，都会卡住很久。
3.5 另一种超常见考点：从HTTP响应中提取图片隐写
上面的题是把zip藏在HTTP流里，还有一种几乎同等高频的考法：flag直接藏在HTTP获取的图片里。操作方式是这样的：在http过滤结果里，看响应包的Content-Type以及Content-Length。如果发现一个响应包响应体特别大，而请求只是个普通GET，那八成是下载了一个图片。右键Follow TCP Stream，选择“Show data as: Raw”——重点来了，然后点击“Save as”把你看到的原始数据保存成文件，这个文件往往就是一个图片。
图片拿到手之后，依次尝试三件套：strings（提取字符串）、binwalk（检测嵌入文件）、steghide（隐写提取）。CTF流量分析题里的图片很少是“普通图片”，要么尾部藏了压缩包，要么是LSB隐写，要么是Exif信息里写了flag。我见过一道题，flag被拆分后分成了两半，一半藏在图片的Exif里，另一半在另一条流的TCP payload里，需要自行拼接。这类题目的核心思路是：不要把图片当作图片，要当作可能的容器。
4. 不同协议下的流量分析进阶：HTTP之外的花样
HTTP协议是流量分析的“主战场”，但CTF题不可能永远只考HTTP。下面这几个进阶方向，是我在刷题时真实遇到过、并且花了不少时间才摸清套路的。提前了解它们，至少能让你见到题目时不慌。
4.1 FTP流量：用户名密码最容易漏
FTP流量分析难度不高，但新手经常犯一个错：盯着数据包列表看，却不知道FTP的认证过程是在控制连接里以明文传输的。过滤器输入ftp或ftp-data就可以看到两条不同的逻辑链路。ftp控制连接里通常能看到USER和PASS命令，flag有时就伪装成密码，有时候藏在某个下载的文件里。注意ftp-data是分离的数据连接，真正传文件的是这个，Follow TCP Stream之后选择原始数据保存，流程跟HTTP提取类似，但容易忘记。
4.2 DNS隧道与exfil：流量小但戏多
DNS协议流量分析是进阶选手的试金石。正常的DNS请求只有几十字节，但如果某个域名形如flag.attacker.com，或者子域名部分包含大量字符，比如b3BlbnNzbC5jb20=.example.com这种，那就是DNS隧道，也就是有人把数据编码后塞进了域名查询里。遇到这种情况，先把DNS请求里的查询名全部导出，然后按照分隔符拆解，再逐个解码。Wireshark里可以用dns.qry.name这个过滤器字段，把所有查询名列出来，一目了然。
4.3 USB流量：键盘和鼠标藏着密码
USB流量分析可以算Misc里的一个独立分支，这里简单提一下套路。键盘流量每个包的有效数据通常8字节，第三个字节对应按键码，把一系列按键码按照HID键值表映射成字符，就能还原出输入的字符串。鼠标流量则是看位移的偏移量，可能是坐标记录，也可能隐藏了信息。如果你的题目里看到大量URB_INTERRUPT in的包，那大概率就是USB键盘采集题。这类题用Wireshark能打开，但处理起来比较繁琐，可以配合tshark先导出数据：
tshark -r capture.pcapng -T fields -e usb.capdata > usb_data.txt然后写Python脚本处理键值映射。我最大的经验教训是：不要试图在Wireshark图形界面里肉眼看几百个USB包，一定要导出来用脚本处理，省时省力还不会看漏。
4.4 TCP流重组：当协议识别失效时
有些题目刻意避免使用标准协议，纯粹走裸TCP。这时候Wireshark的协议解析器不会显示http或ftp，整个包列表看起来就是一个个TCP包。别慌，用“Follow TCP Stream”逐条查看，很多题目flag就是直接写在TCP payload里的，甚至还有那种把flag拆成语录、模拟网络聊天记录的题。我建议的顺序是：先看Conversations统计里哪条流数据量最大，然后依次Follow这些流，把内容全部过一遍。遇到实在没思路的packet，右键 -> Protocol Preferences，关闭某些协议的自动解析可能是破局点，因为有时Wireshark把自定义二进制协议误判成了标准协议，关闭解析就能看到原始payload。
5. 流量分析题实战工具链：不只是Wireshark
熟练使用Wireshark是基础，但做题效率往往取决于你愿不愿意用工具组合。我自己做流量分析题的时候，工作流是这样的：Wireshark负责看和筛选，tshark负责导出数据，Python负责解码和还原，binwalk和strings负责文件内容提取，必要时还会上NetworkMiner这类工具做辅助。我把这些工具的使用姿势整理如下。
tshark：Wireshark的命令行版本。优势在于批量处理和管道操作。导出HTTP所有请求头：
tshark -r capture.pcapng -Y http -T fields -e http.request.uri；导出所有TCP流的payload：tshark -r capture.pcapng -T fields -e tcp.payload。在做大规模流量分析时，tshark的效率远高于图形界面，写脚本批量处理题目时更是必备。NetworkMiner：一个免费的流量分析辅助工具，可以自动从pcapng里提取传输的文件（Files标签页），还能按主机分组展示通信关系。对新手来说最实用的功能就是“提取文件”，比手工Follow TCP Stream再保存要快好几倍。不过要注意，NetworkMiner只负责提取，文件内容是不是flag，还得回到binwalk和strings这一步来验证。
binwalk / foremost：用于文件分析和隐藏文件提取。binwalk可以检测文件尾部附加的数据，foremost可以从原始数据中自动剥离出多种格式的文件。当你在流量里提取出一个看不懂的文件时，先跑
binwalk看结构，再跑foremost看能拆出什么东西。strings + 正则：
strings file | grep -iE "flag|ctf|key"可以作为快速筛选，但有时候flag被拆开藏在不同的行里，我用一个更实用的做法：把提取出来的所有字符串都导入到文本编辑器中，然后用正则([a-zA-Z0-9]{10,})刷一遍长字符串，这些长字符串大概率是编码后的flag或者密钥材料。
我一般不建议在新手阶段同时上太多工具。先把Wireshark + tshark + Python这三件套玩熟，等题目难度上来了，再逐步引入NetworkMiner和foremost，效果更好。
6. 一键梭哈思路：流量分析通用做题流程SOP
有了前面的基础，我来把整个做题流程总结成一个可复用的SOP。我自己是按这个顺序走的，每一步都有明确目的，不会东翻翻西翻翻浪费时间。
第一步：了解全局（30秒）
打开pcapng后，先看Statistics -> Protocol Hierarchy，搞清楚流量里有哪些协议。再看Statistics -> Conversations，找出通信量最大的IP对和TCP流。这一步的目的是建立全局观，判断题目属于哪一类考法。
第二步：关键字搜索（1分钟）
Ctrl+F搜“flag”，如果搜到了就直接顺着定位。搜不到就搜{、}、ctf等常见字符，再搜不到就想一想flag可能被编码成了什么，比如Zmxh（Base64的fla开头），%66%6C%61%67（URL编码）等。
第三步：按协议逐块排查（3分钟）
依次使用http、dns、ftp、tcp等过滤器，对每种协议的主要流执行Follow TCP Stream，重点看有没有文件传输和可疑字符串。这一步做题速度取决于对协议的熟悉度，遇到不懂的协议字段，右键查看官方描述或者直接转原始字节看内容。
第四步：文件提取和内容鉴定（5分钟）
凡是发现有文件传输的流量，一律提取出原始数据，然后依次用file、strings、binwalk做鉴定。这一步最容易出flag，也最需要耐心。有一年某CTF的题，压缩包里还有一层压缩包，套了三四层，最后才看到flag，纯粹考验耐心和自动化处理脚本的能力。
第五步：编码转换和密码还原（5分钟）
如果找到的字符串看起来不直观，使用CyberChef或者自己写脚本，依次尝试Base64、Base32、十六进制、URL解码、ROT13、异或等常见编码方式。CTF有一个不变的真理：出题人不会把flag明文扔在流量里，但也不会用一个你完全无法破解的加密方式，最多是Base64加一次字符反转，或者异或一个单字节密钥。多尝试几种，总有一款适合。
第六步：兜底的原始数据检查
实在没有思路时，选择Statistics -> Endpoints，查看是否有异常的IP或端口。有时候flag藏在ICMP包里的payload，有时藏在UDP端口的高字节序里，有时藏在TCP的序列号或者初始窗口中（这类题比较偏门，但确实有人出）。兜底检查的核心原则是：不要放过任何看起来“多余”的数据。
上面这套流程，我在几十道题上验证过，除了一些偏门的底层协议题，绝大多数题目都能在15分钟内解开。
7. 做题经验与常见坑：那些让我卡关两小时的教训
写到最后，分享一些平时文章不会写但实战血泪总结的经验。有些坑我踩过不止一次，写出来希望能帮到你。
第一个坑：TCP流追踪时只看了文本，忽略了Raw数据。Wireshark的Follow TCP Stream默认以文本显示，但如果传输的是二进制文件，文本模式会显示成乱码，很多新手以为这是加密数据就放弃了。实际上切换到“Show data as: Raw”，再Save as保存，就能还原出原始文件。看到乱码先别慌，先切Raw看看。
第二个坑：忘了pcapng可能包含多个接口的流量。有些题目用的是多接口抓包文件，在Wireshark左下角接口栏会显示多个编号。有的flag只在某一个接口的流量里，如果只盯着默认接口，永远找不到。做题时如果感觉包很少、内容很单一，检查一下是否有其他接口的流量被折叠了。
第三个坑：纯手工翻包，拒绝写脚本。当流量包里有几百个相似的HTTP请求、每个请求的响应体里都有一段Base64，纯手工复制粘贴会把人搞疯。这时候就用tshark导出所有数据，再用Python批量Base64解码，几秒钟就能完成。CTF是一种效率游戏，能用脚本解决的绝不手工做。
第四个坑：把HTTP响应里的压缩文件直接硬解。有的题目Wireshark会把响应体里的文件内容按“HTML”或者“文本”分块显示，导致你复制的Base64不完整。遇到这种情况，通过“File -> Export Objects -> HTTP”直接导出所有HTTP对象，这才是最干净的提取方式，避免绕过Wireshark重组逻辑造成的截断问题。
第五个坑：忽略了时间过滤和排序功能。有些题的flag藏在“最早”或者“最晚”的流里（模拟攻击链的开始和结束）。在Wireshark中点击Time列排序，快速找到时间戳异常的那几条记录，往往会有意外发现。另外，可以用frame.time过滤特定时间段的流量，这在流量包特别大时很实用。
我在实际做题中最依赖的一个小习惯是：每解出一个中间结果，马上记录在文本文件里，记录下所用过滤器、追踪的流编号、解码方式和解出的字符串。这样如果最终结果不对，还能回溯检查是哪一步出了问题，不用重新翻包。这个方法在比赛计时场景下特别有用，强烈建议一试。
流量分析这个方向，在CTF里看起来不够酷炫，但它其实是信息安全的基本功——每一次真实的安全事件响应都是从流量分析开始的。能把Wireshark玩熟，能从杂乱的数据包里准确还原出攻击者的动作，这本身就是一项非常实用的能力。这篇文章从流量分析的题型分类、Wireshark核心操作、完整实战Writeup到常见坑技巧都覆盖了，希望对你有所帮助。如果在做题时遇到卡壳，不妨回到这篇SOP里对照流程，大部分时候，问题出在“你还没有穷尽所有可能性”。
