1. 流量分析到底在分析什么先把这个事情说透流量分析不是一个需要高深数学基础的“高冷技能”它的本质就是把网络上传输的数据包抓下来然后搞清楚这些数据包在说什么、在干什么。你平时刷网页、聊语音、传文件所有这些行为都会变成一串一串的数据包在网络里跑。流量分析要做的事情就是把这些包一个个解开把里面的信息还原出来。这个技能在CTF网络安全竞赛里几乎是必考的最常见的出题方式就是给你一个pcap文件数据包捕获文件让你从里面找flag。而“流量分析”这个热词之所以能火起来很大程度上就是因为CTF的流量分析题里出现过一类很有意思的考法——拿到一个包含VoIP通话流量的pcap文件最后还原出来的是一段通话录音。这类题目一开始让很多人懵圈流量分析不是找字符串、找文件吗怎么还能跟语音扯上关系实际上VoIPVoice over IP基于IP网络的语音通话技术流量分析的考点并不算冷门。SIP协议负责建立通话、RTP协议负责传输实际的声音数据抓包抓到的这些协议最终是可以把“声音数据”从包里提取出来重新拼成一段能播放的音频文件的。换句话说流量分析不仅能还原文件、图片、网页内容连“谁在什么时间给谁打了电话、说了什么”也能还原出来。这篇文我不会去给你背一遍协议栈的教科书内容而是按照我实际做流量分析的经验把一个完整、可上手的流程讲清楚。包括流量分析整体的思路框架、常见协议的识别方法、wireshark的关键用法以及大家最关心的“流量还原音频”“从pcap里提取文件”这类实操最后附上我在做题和实际工作中踩过的一些坑。无论你是刚接触CTF的新手还是做安全运维想补这块短板按这个流程走一遍应该能少走不少弯路。2. 上手之前先把思路框架搭起来2.1 流量分析解决的是哪几类问题我在带新人时发现很多人拿到一个pcap文件之后第一反应就是一顿乱点看看这个包、看看那个流抓了半天也找不到头绪。问题的根源不在于不会用工具而在于脑子里没有一个“先干什么、再干什么”的框架。根据我做题和做事的经验流量分析要解决的问题基本可以归成这四类问题类型典型场景关键突破口找明文字符串登录框、搜索框、通信消息里直接传了flag搜索协议、跟踪TCP流、过滤关键字还原传输文件图片、压缩包、文档被传输过但没落地追踪HTTP流、导出对象、binwalk分析分析攻击行为扫描、爆破、注入、木马回连协议统计、异常流量模式、时间线梳理还原多媒体内容VoIP通话、视频流被捕获SIP会话分析、RTP流提取、音频重组我见过太多人只知道“找字符串”这一种玩法一旦题目里没有明文flag就卡死。而实际上像VoIP还原音频这种题如果你心里没有“流量里还能藏音频”这个概念给你一天时间也找不到正确的方向。所以拿到pcap之后第一件事不是双击点开而是先自问一句这份流量是哪类场景下产生的是Web访问产生的、是文件传输产生的还是语音通话产生的场景判断对了后面的一切动作才会有方向。2.2 判断场景的核心依据怎么快速判断场景我从不用那种“一层层点界面”的笨办法直接看统计结论。打开pcap之后第一时间我会看两个地方菜单栏的Statistics统计→ Protocol Hierarchy协议分级这里一眼就能看出这份流量里都有哪些协议、每个协议的包数量和占比。菜单栏的Statistics → Conversations会话这里可以看到有哪些IP在通信、端口是什么、数据量多大。这两个面板看完基本上就能给流量“画像”了。比如看到HTTP、TCP、DNS为主多半是网页浏览流量。看到FTP、TCP数据连接端口20/21多半是文件上传下载。看到SIP、RTP/UDP成规模出现那基本可以确定是VoIP通话流量。看到ICMP大量出现且数据包不规则可能要怀疑是隧道或探测行为。尤其是VoIP场景你在Protocol Hierarchy里一下就能认出那个标志性的组合SIP协议负责“打电话的动作”RTP协议负责“说话的声音”。这两类协议一出现脑子里就要立刻弹出“这个题可能要还原音频”的预判。2.3 工具选型Wireshark外的组合拳流量分析的主力工具是Wireshark这个没得说。但在大量CTF题和真实场景里只靠Wireshark一个有UI的工具效率和深度都不够。我给新人的建议是准备一套组合工具按需取用wireshark交互式深挖流量、协议解析、流重组的第一选择尤其是可视化操作它最顺手。tsharkWireshark的命令行版本擅长批量处理、快速筛选、从大包里提取字段信息。tcpdump主要用于实时的抓包拿到现成pcap后我也会用它做一些快速过滤和切割。stringsLinux下的一个极简命令直接从二进制数据里抽出可打印字符串找明文flag时效率极高。binwalk / foremost做文件提取和隐写分析时要用能从数据里分段拆出隐藏文件。audacity处理音频还原时使用剥出原始语音数据后要在这里做格式整理、降噪、播放。这些工具不要求一次全装但至少tshark、strings和binwalk我建议提前装好因为它们会在后面几个实操环节里频繁登场。3. 核心环节流量里的“找”和“还原”3.1 从pcap里捞明文信息最基础的玩法从一个pcap文件里直接捞字符串和明文通信内容。这类题目考的是“你知不知道流量分析要关注哪些地方”不需要太高深的技巧。第一步用strings快速扫一遍。在命令行里执行strings capture.pcap | grep -i flag\|ctf\|key\|secret这个命令能把pcap里所有可读字符串提出来然后筛含有关键字的行。之所以先跑这个命令是因为很多新手题就直接把flag放在某个HTTP请求的URL参数里、或者放在某个登录请求的POST数据里strings一次就能筛出来。即便筛不出来也能对这份流量里有没有明文内容有一个整体感觉。第二步用Wireshark的“跟踪流”功能做完整还原。在Wireshark里随便选中一条HTTP或TCP包右键选择追踪流 → TCP流 / HTTP流Wireshark会把整个会话的数据按顺序拼起来展示。比如HTTP登录请求你在这里能看到完整的请求头和请求体flag往往就藏在username或password字段里。关于这一步有一个习惯我必须强调不要只看第一个包更不要只盯着数据包列表的Bytes区域死磕。把流的完整内容展开看很多线索在分片后的单一包里是看不全的只有把整个流拼接起来才能看到全貌。3.2 从流量里还原文件如果明文里找不到flag接下来要想到的是这段流量里是不是传过文件典型场景是HTTP下载、FTP上传下载还有一些压缩包是通过邮件附件走的SMTP协议。以最常见的HTTP传输文件为例在Wireshark里用菜单栏的文件 → 导出对象 → HTTP会弹出一个列表里面列出了所有通过HTTP传输过的文件对象。直接勾选保存就能把文件导出来。导出之后对文件做进一步分析比如解压、查看图片、检查文件尾部的附加信息等。这里有一个很关键的细节有些题目会把flag藏在图片或压缩包的尾部附加字节里。比如一张正常的图片文件你用strings或者xxd看它的末尾会发现一段不相关的字符串——这往往就是隐藏信息。还有一种情况导出的文件不是标准格式比如扩展名被改过或者文件头被抹掉了就需要用binwalk或者010 Editor检查文件特征。用binwalk检查文件特征和提取附加数据的方法binwalk flag.jpg如果binwalk提示文件里有压缩包或者出现“Zlib compressed data”之类的字样说明这个图片里还塞了别的东西再用binwalk -e自动化提取。3.3 VoIP通话录音的提取与还原说完了文件和字符串到这篇博文的重头戏怎么从流量里把VoIP通话内容还原成可听的录音。先说一个背景VoIP系统里负责“打电话”的是SIP协议它负责呼叫的建立、转发、挂断默认跑在UDP的5060端口。而实际的声音数据走的是RTP协议RTP通常使用UDP的偶数端口常见的范围在16384到32768之间。RTP包传的是编码后的音频数据比如G.711编码编码规则是把模拟声音信号转成数字的PCM数据块再封装成RTP包发送。我们要做的就是把这些RTP载荷里的数据块按顺序提取出来、拼接起来再还原成音频文件。第一步确认流量里有VoIP通话。在Wireshark的Protocol Hierarchy里看到SIP和RTP就说明通话流量存在。接着在Wireshark的菜单栏里找到Telephony电话→ VoIP Calls这里会列出捕获到的所有VoIP会话包括主叫、被叫、时间、状态等信息。看到这里思路就可以闭环了有通话、有RTP流目标就是把通话内容抽出来当证据/flag。第二步用Wireshark内建的“播放/导出音频”功能。在VoIP Calls列表里双击一条通话记录Wireshark会自动弹出RTP流分析窗口。点击“Play Stream”可以直接听通话内容点击“Export”可以把通话的音频数据导成文件。听起来很简单对吧但对新手来说坑就在这Wireshark默认导出的是原始RTP载荷格式不一定能被普通播放器直接打开需要在导出时选对格式一般选“.au”或“.wav”比较稳或者在导出后用Audacity做格式转换。提示如果导出的音频播放出来是“哔哔”的噪声或速度不对先别急着怀疑数据有问题。大概率是导出时没有去除RTP头部或是编码格式选错了。Wireshark在Telephony → RTP → RTP Streams里有“Analyze”选项分析之后再生成为WAV会比纯手工拼接靠谱很多。第三步tshark手工提取RTP载荷做兜底。Wireshark的UI一步到位在多数情况下很香但有些场景下比如RTP流被分片切碎、或者流量不止一路通话它就显得笨拙。这时候我用tshark命令手工提取反而更可控。核心思路是把RTP包的载荷payload提取出来去掉RTP头只保留音频数据然后拼接成一个原始PCM文件再用Audacity打开。大致命令流程如下# 先过滤出某一通电话的RTP流查看载荷格式 tshark -r capture.pcap -Y rtp udp.port40000 -T fields -e rtp.payload # 提取RTP载荷存成原始数据文件 tshark -r capture.pcap -Y rtp udp.port40000 -T fields -e rtp.payload | tr -d \n rtp_audio.raw # 用xxd把十六进制文本转成二进制 xxd -r -p rtp_audio.raw rtp_audio.pcm生成了.pcm文件之后用Audacity打开导入时选择“Raw Data”编码选择适合G.711的“Unsigned 8-bit PCM”如果载荷是64kbps的G.711 u-law或A-law可能需要先做u-law/A-law到线性PCM的转换Audacity里有对应的滤波选项。设置好采样率一般是8000Hz或16000Hz就能播放通话内容了flag往往就以两位数口令或一段文本的形式出现在录音里。3.4 编码格式与静默音频的坑在多人一起做VoIP题目时我观察到大家最容易卡住的有两点一是导出的音频“全是噪声”二是音频“只听到半句后半段没声了”。关于噪声原因往往是RTP载荷里不只包含语音数据还可能包含了编码器的一些冗余信息或者你的解码方式不匹配。G.711有两种变体——u-law和a-law如果把a-law的载荷按照u-law去播出来的基本都是噪声。处理办法是在Audacity导入后用“Effect → Filter Curve”或直接换解码方式试一遍直到听出人声为止。关于后半段没声通常是因为RTP流里存在**静音抑制VAD语音活动检测**机制。说话停了RTP包就不发了但这些“空白档”在时间线上是存在的。如果在提取时没有按时间戳把空白补上直接拼接数据就会导致音频时间轴缩短、后半段与字幕或文本对不上。处理这类问题要回到Wireshark里看RTP的Marker和时间戳字段确认丢包和静音的位置做到“按时间戳重组”而不是“按包顺序硬拼”。4. 实操流程一次完整的CTF流量分析题演示讲到现在可能还有些抽象我拿一个典型的CTF流量分析题来完整走一遍流程。这个题是我根据常见出题思路模拟的但步骤和手法完全是我实际做题时的那一套。假设你拿到一个名为phone.pcap的文件题目提示说“flag是一串电话号码藏在通话中”。我们按完整流程走一遍。4.1 第一步全局观察给出预判打开文件先看Protocol Hierarchy。如果表格里出现SIP和RTP的统计条目立刻判定这是VoIP场景。此时的目标已经变了不是去翻HTTP请求而是要重建通话音频。接着看VoIP Calls列表找到活动通话。我的习惯是把每通电话的主叫号码、被叫号码、时间戳记下来因为号码本身就是重要的线索有时候flag直接就是“拨打的主叫号”。4.2 第二步用Wireshark导出通话音频在Telephony → VoIP Calls中双击通话记录等待RTP Stream Analysis窗口加载。点击“Export”时我推荐选“.au”格式因为后面还要导入Audacity做处理.au的兼容性和原始PCM的还原度更好。导出后文件大约是几十KB到几百KB取决于通话时长。4.3 第三步Audacity清洗与播放把导出的音频拖进Audacity。通常会出现两种情况直接就能听到清晰的语音这是最简单的情况照着念出flag即可。播放是“机器人声音”或“水下声音”这是因为导出的是压缩域格式。这时选择整段音频执行“Effect → Noise Reduction”先降底噪再观察波形确定人声频段必要时用“Effect → Equalization”做频段补偿。还有一种更暴力的方案是直接在Audacity里转换样本格式底部状态栏的Sample Rate处点击可切换8kHz/16kHz/32kHz循环试听即可。4.4 第四步tshark手工提取作为兜底如果Wireshark导出失败或者题目故意设置了多路通话干扰就走tshark手工提取路线。先看RTP流有哪些tshark -r phone.pcap -Y rtp -T fields -e rtp.ssrc -e rtp.payload | head -20选定一路目标SSRC后用前面的提取命令把该路载荷全部转成PCM再用Audacity导入。值得一提的小技巧在命令行提取时先用-e rtp.timestamp把时间戳也导出来比较时间戳的跳变如果发现严重不连续说明中间有丢包这时需要在拼接时按时间戳补零否则还原出来的语音会断断续续。4.5 第五步把“结果”整理成可提交格式CTF里最后的flag可能是一串电话号码、一句口令或者一个名字。我在听到音频之后会先写一遍听到的内容然后倒回去再听一遍校验发音是否清楚。曾经有一次我听成“five”结果答案是“nine”因为录音里说话人口音很重第二遍仔细听才纠正过来。多听一遍校验虽笨但有用。5. 干货速查常见问题与排查手册最后把这些年做流量分析遇到的高频问题整理成一张表给新人当“排障手册”用。每条都是实际踩过的坑不是理论猜测。问题现象可能原因排查与解决打开大pcap卡死pcap文件过大单个包数量超百万先用tshark按IP或端口过滤导出子集再导入Wireshark或改用tshark批处理能导出文件但打不开文件头损坏或扩展名错误用file命令识别真实类型用binwalk或010 Editor手工修复文件头HTTP对象列表为空文件不是通过HTTP明文传输的转查FTP端口21或SMTP端口25/110/143搜关键字“filename”“attachment”TCP流跟踪出来是乱码流量经过了压缩或加密协议查看是否为HTTPSTLS若是则寻找有没有会话密钥或关注是否有zip类压缩传输先导出后解压导出音频全噪声RTP载荷的编码格式判断错误在Audacity里切换a-law/u-law逐段试听不同采样率语音断断续续RTP流中有丢包或有静音抑制回到RTP Streams分析看丢包率提取时按时间戳拼接丢失段补零同一pcap有多个SIP通话题中故意录制了多路干扰通话逐条在VoIP Calls里试听或根据SIP的Call-ID精确过滤出一路RTP再处理strings扫不到flag传输内容编码过或藏在非文本协议里换binwalk拆文件检查每个导出的附件关注DNS查询字段、ICMP载荷等“低频”位置时间线混乱不知道从哪看起捕获的流量跨度大、无关流量多在Wireshark里用时间显示格式View→Time Display Format调成相对时间以首包为0起点按时间顺序切分分析协议分级里看不到SIP/RTP用的端口非默认端口编辑→首选项→Protocols→SIP/RTP自定义端口重新解析或者直接看UDP载荷中SIP方法字段INVITE/REGISTER上面这些坑大多不是某一个动作导致的而是“前面选错了方向”累积出来的。所以我的核心建议仍然是拿到pcap先定场景、再看统计、最后才动手挖细节这个顺序能帮你跳过一大半的坑。提示做流量分析时我建议每做一个关键动作都做一个书面记录比如“看到什么协议、导出了什么文件、结论是什么”。很多流量分析题的pcap里不止一条线索写下来能让思路清晰很多也避免重复劳动。6. 个人经验流量分析要“先理解再点工具”最后分享一点我个人的体会。流量分析这个技能如果只停留在“会用Wireshark”的层面遇到没见过的题很容易慌。但如果你把底层逻辑理顺了——数据包是分层的、协议是有状态的、信息是可以重组的——那不管出题人把flag藏在明文、文件、图片还是通话录音里你的应对思路都能自然生成。我在带新人时反复强调一个观点工具只是放大器理解才是杠杆。你按这篇文里说的流程练过两三次之后建议我不给详细步骤只给场景标题让脑子先想“应该怎么做”再看实操步骤对不对。这样训练出来的“场景→动作”反射比记住一百条菜单栏路径都管用。再分享一个小技巧处理任何pcap之前先用tshark输出一份“精简清单”只包含时间、协议、源目IP、长度这几个字段tshark -r capture.pcap -T fields -e frame.time_relative -e ip.src -e ip.dst -e frame.len -e protocol | head -100这份清单能让你在一分钟内快速浏览整份流量的骨架有助于发现问题、提取线索、定位目标。很多人一上来就陷入数据包的“森林”里这份骨架清单就是你的地图。流量分析这门功夫练的就是“把看不见的信息语言翻译成人话”。从找字符串到还原文件再到把通话录音变成一句口令技能维度其实是一个逐步上升的路径。顺着路径走多踩几次坑、多回头看几次数据包的结构时间长了你也会形成那种一看到协议列表就能脱口而出“这题要干嘛”的直觉。