
简介本资源面向中职学校网络安全技能比赛选手及网络空间安全方向的学习者聚焦数据流量分析与数据安全取证场景以B.pcapng数据包为核心素材帮助读者掌握从真实流量中提取关键线索的实战方法。压缩包内共1个docx文档大小约3.27MB内容围绕渗透机环境下的数据包分析任务展开涵盖数据库flag定位、黑客扫描主机IP识别、服务器内核版本提取、扫描命令还原、一句话木马上传文件追踪以及服务器下载文件内容还原等典型考点并附有数据包下载链接与提取码便于对照练习。目前已有744人学习下载适合需要系统训练流量分析思路、熟悉取证工具操作与赛题解题流程的读者参考可作为备赛复盘与技能查漏补缺的辅助材料。1. 从一份 B.pcapng 说起流量分析取证到底在考什么很多人第一次拿到 B.pcapng 这种流量包第一反应是直接丢进 Wireshark 里翻协议树翻了两小时还在 TCP 重传里打转。这份资源其实是一套面向中职技能比赛网络安全赛项的流量分析解析文档核心围绕一个 Windows7 靶机环境下的数据包 B.pcapng 展开配套 BT5 渗透机root/toor作为操作入口。它要解决的不是怎么抓包而是包已经抓好了你怎么从里面把 flag 一条条挖出来——数据库里的字符、被扫描的主机 IP、服务器内核版本、扫描命令、木马上传的文件名、下载文件的内容六个任务点覆盖了流量取证里最典型的几类线索。适合正在备赛的学生、刚接触 CTF 流量题的从业者以及需要给学员讲从流量到证据这条链路的教练。它不教你协议原理它教你在一堆十六进制里找到那根线头。2. 环境搭起来BT5 与 Windows7 靶机的取证链路2.1 为什么是 BT5 加 Windows7 这套组合这套环境的选择不是随便定的。BT5BackTrack 5作为渗透机自带 Wireshark、tcpdump、foremost、binwalk 等一整套流量与文件分析工具root/toor 直接登录就能用省去了在 Windows 上装一堆依赖的麻烦。Windows7 靶机则是被攻击方B.pcapng 就是在它的网卡上抓下来的流量。两台机器通常放在同一个 Host-Only 或 NAT 网段里保证流量干净、没有外网干扰。我一般会先确认三件事BT5 能不能 ping 通 Windows7、Wireshark 的版本是否支持 pcapng 格式BT5 自带的 1.8.x 是支持的、以及靶机的 IP 是不是 192.168.10.x 段。因为后面任务二要找的扫描目标 IP 是 192.168.10.12如果靶机网段不对你分析出来的结论和题目对不上。提示BT5 是比较老的发行版如果你用 Kali 替代工具路径和默认账号会变但 Wireshark 的操作逻辑完全一致不影响解题。2.2 把 B.pcapng 导入 Wireshark 并做第一轮过滤拿到 B.pcapng 之后第一步不是急着看内容而是先建立时间轴感。打开 Wireshark加载文件先看 Statistics → Summary确认包数量、抓包时长、平均速率。然后按协议分层看Statistics → Protocol Hierarchy哪些协议占了大头HTTP、TCP、DNS 各占多少。# 在 BT5 命令行下快速看一眼文件基本信息 capinfos B.pcapng # 输出会给出包数、时长、文件大小、封装类型capinfos是 Wireshark 套件里的命令行工具不用开图形界面就能拿到包的元信息。重点看 Number of packets 和 Capture duration如果包数只有几百个说明这是一个精简过的比赛用包可以逐条看如果上万就必须靠过滤器缩小范围。接下来用显示过滤器做第一轮筛选。常见起手式# 只看 HTTP 请求 http.request # 只看含有关键字的 TCP 流 tcp contains flag # 只看某个 IP 的通信 ip.addr 192.168.10.12tcp contains flag这个过滤器在 CTF 流量题里命中率很高因为出题人往往会把 flag 明文或半明文藏在某个流的 payload 里。但注意它只匹配 ASCII 字符串如果 flag 被 base64 编码过就搜不到得换思路。2.3 用 Follow TCP Stream 还原一次完整会话Wireshark 里最核心的取证动作是 Follow TCP Stream。右键任意一个包 → Follow → TCP Stream就能看到这条 TCP 连接双方发送的完整字节流。B.pcapng 里的六个任务至少有四个要靠这个功能。操作步骤在过滤栏输入tcp.stream eq 0定位到第一条流。右键 → Follow → TCP Stream。弹出的窗口里红色是客户端发往服务器的数据蓝色是服务器返回的。底部有 Show data as 下拉框可以在 ASCII、Hex Dump、C Arrays 之间切换。# 快速列出所有 TCP 流编号 tshark -r B.pcapng -T fields -e tcp.stream | sort -n | uniqtshark是 Wireshark 的命令行版本-T fields -e tcp.stream表示只输出 tcp.stream 这个字段配合 sort 和 uniq 就能得到所有流的编号列表。知道一共有多少条流心里就有底了——比赛包通常不会超过几十条流逐条 Follow 是可行的。注意Follow TCP Stream 窗口里显示的内容是原始字节如果遇到乱码先切到 Hex Dump 模式看十六进制再判断是不是压缩包或图片。3. 六个任务逐个拆从数据库字符到木马文件名3.1 任务一与任务二数据库 flag 末字符和扫描目标 IP任务一问的是数据库里的 flag 最后一个字符答案是}。这题在文档里直接写了这题谁都不会记住答案即可说明它依赖的是一个特定数据库环境里的 flag 值光靠流量包不一定能完整还原。但从取证角度思路是这样的先在 Wireshark 里过滤 MySQL 协议流量。# 过滤 MySQL 协议 mysql # 或者按端口过滤 tcp.port 3306如果 B.pcapng 里存在 MySQL 的查询流量Follow TCP Stream 之后能在 payload 里看到 SQL 语句和返回结果。flag 的最后一个字符是}说明完整的 flag 形如flag{...}而题目只要求提交最后一个字符。这种只取一个字符的设计通常是因为完整 flag 在流量里被分段传输或者被加密了出题人只让你证明你找到了那条记录。任务二找扫描到的主机 IP答案是 192.168.10.12。这题的线索在扫描流量里。黑客用 RASscan.py 做扫描扫描行为会在流量里产生大量 SYN 包或者特定模式的请求。过滤方法# 找 SYN 包密集的目标 tcp.flags.syn 1 tcp.flags.ack 0 # 按目标 IP 统计 tshark -r B.pcapng -T fields -e ip.dst | sort | uniq -c | sort -rn | head -20第二条命令统计了所有包的目标 IP 出现次数出现次数最多的那个 IP 大概率就是被扫描的主机。uniq -c做计数sort -rn按数字倒序排head -20只看前二十。这是流量分析里最实用的一把梭统计法不用逐包看就能定位热点。3.2 任务三与任务四内核版本与扫描命令的提取任务三要找服务器内核版本答案是3.10.0-123.e17.x86_64。这个信息通常出现在两种地方一是 HTTP 响应头里的 Server 字段二是 SSH 或系统命令执行的返回内容。过滤 HTTP 响应# 看所有 HTTP 响应头 http.response # 搜索含 kernel 或 uname 的流量 tcp contains uname tcp contains kernel如果黑客通过 webshell 执行了uname -a返回结果就会在 HTTP 响应的 body 里。Follow TCP Stream 之后直接能看到Linux ... 3.10.0-123.e17.x86_64 ...这样的字符串。注意e17很可能是el7Enterprise Linux 7的 OCR 误读实际提交时按题目给的答案为准。任务四的答案是RASscan.py 192.168.10.10 192.168.10.110 -t 20 log.txt。这是一条完整的扫描命令说明黑客在目标机器上执行了 RASscan.py扫描 192.168.10.10 到 192.168.10.110 这个网段线程数 20结果输出到 log.txt。这条命令大概率出现在 webshell 的请求参数里或者某个反弹 shell 的交互流量中。# 搜索含 RASscan 的流量 tcp contains RASscan # 搜索含 log.txt 的流量 tcp contains log.txt找到之后 Follow TCP Stream把命令完整复制出来。这里有个细节命令里的在 URL 编码里是%3E如果是在 HTTP GET 参数里传输的Wireshark 显示的可能还是编码后的形式需要手动解码。3.3 任务五与任务六一句话木马与文件内容还原任务五问的是通过一句话木马上传的第一个文件答案是socks.py。文档里给了一条关键线索Z1 参数传递了 B.zip 的数据包往下一行找到 z1 的 value复制出来用 base64 解码。这说明木马的通信参数用了 Z1 作为字段名值是 base64 编码的。操作流程# 先找到含 Z1 参数的 HTTP 请求 http contains Z1 # 或者直接搜 base64 特征 http.request.method POST找到 POST 请求后Follow TCP Stream在请求体里找到Z1后面的值复制出来做 base64 解码# 把复制出来的 base64 字符串解码 echo 你的base64字符串 | base64 -d output.bin # 如果是 zip 文件解码后直接解压 file output.bin unzip output.binbase64 -d是解码file命令用来判断解码后的文件类型。如果输出显示Zip archive data说明还原成功解压后就能看到 socks.py。这一步的坑在于base64 字符串里可能包含、/、这些字符在 URL 传输时会被编码成%2B、%2F、%3D复制的时候要先把 URL 编码还原回去否则解码会失败。任务六是从服务器上下载的文件将文件内容作为 FLAG。文档里给的操作说明很特别按 I 键进入编辑模式在行首加入 aaaa按 ESC 退出编辑模式。然后输入%! xxd按下回车键输入%!xxd -r保存。这是 vim 的十六进制编辑模式操作。说明下载的文件是一个二进制文件需要用 vim 的 xxd 功能来查看和修改。# 用 vim 打开下载的文件 vim downloaded_file # 在 vim 里执行 # 1. 按 ESC 确保在普通模式 # 2. 输入 :%!xxd 回车切换到十六进制视图 # 3. 按 I 进入插入模式在行首加入 aaaa # 4. 按 ESC 退出插入模式 # 5. 输入 :%!xxd -r 回车转回二进制 # 6. 输入 :wq 保存退出:%!xxd是把当前缓冲区的内容通过外部命令 xxd 转换成十六进制显示:%!xxd -r是反向转换。在行首加aaaa通常是为了修复文件头——很多 CTF 题会把文件的 magic bytes 改掉让你手动补回去。比如一个 PNG 文件被改成了别的格式你在十六进制视图里把开头的几个字节改回89 50 4E 47就能正常打开。提示vim 的 xxd 模式对新手不太友好如果操作失误导致文件损坏重新从流量包里提取一次即可不要在原文件上反复改。4. 避坑与排查流量分析里最容易翻车的五个点4.1 过滤器写对了但什么都没显示现象输入http.request之后包列表一片空白但明明知道有 HTTP 流量。原因B.pcapng 可能是在非标准端口上跑的 HTTPWireshark 的http过滤器默认只认 80、8080 等常见端口。如果服务跑在 8888 或 9999 上协议解析器不会自动识别。解决先用tcp.port 8888确认有流量然后右键任意包 → Decode As → 选择 HTTP强制让 Wireshark 按 HTTP 解析这个端口的流量。或者直接用tcp contains GET这种不依赖协议识别的过滤器。4.2 base64 解码出来是乱码现象从 Z1 参数里复制出来的字符串base64 解码后得到一堆乱码不是预期的 zip 文件。原因URL 编码没有还原。HTTP 请求里的参数值如果包含特殊字符会被 URL 编码比如变成%2B变成%3D。直接对编码后的字符串做 base64 解码结果当然不对。解决先把%2B替换回%2F替换回/%3D替换回然后再解码。在 BT5 下可以用 Python 一行搞定import urllib.parse encoded 你的URL编码字符串 decoded urllib.parse.unquote(encoded) print(decoded)urllib.parse.unquote会自动处理百分号编码比手动替换靠谱。4.3 Follow TCP Stream 里看到的命令不完整现象找到 RASscan.py 的流量但 Follow 出来的命令只有一半后面的参数没了。原因命令太长被分到了多个 TCP 段里而 Follow TCP Stream 默认只显示当前选中的那条流。如果命令跨了多条流或者中间有重传就会看起来不完整。解决在 Follow 窗口底部把 Show data as 切到 Hex Dump看原始字节确认是不是有截断。如果是跨流传输用tcp.stream eq N逐条看把内容拼起来。另外检查 Edit → Preferences → Protocols → TCP → Allow subdissector to reassemble TCP streams 是否勾选这个选项影响 Wireshark 是否自动重组分段的 TCP 数据。4.4 内核版本号里的字符看不清现象Follow 出来的内核版本是3.10.0-123.e17.x86_64但不确定是e17还是el7。原因字体渲染问题小写字母 l 和数字 1 在某些字体下几乎一样。el7是 Enterprise Linux 7 的标准写法e17不是任何已知的版本命名。解决切到 Hex Dump 模式看对应的 ASCII 码。l是 0x6C1是 0x31一看便知。但比赛提交时以题目给出的答案为准如果题目写的是e17就按e17提交。4.5 vim 的 xxd 模式改完文件打不开现象按文档步骤在 vim 里用 xxd 改了文件保存后文件无法打开提示格式错误。原因:%!xxd和:%!xxd -r必须成对使用。如果在十六进制视图下直接:wq保存保存的是十六进制文本而不是二进制文件就废了。另外在插入模式下加的字符如果位置不对会破坏文件头。解决记住顺序——先:%!xxd进入十六进制视图改完后必须先:%!xxd -r转回二进制再:wq保存。如果已经保存错了重新从流量包里提取原始文件不要在原文件上修。5. 进阶技巧用 tshark 批量提取与自动化验证当你把六个任务都手动做了一遍之后下一步要考虑的是如果换一个 pcapng 文件能不能用脚本快速定位同类线索。tshark 是 Wireshark 的命令行版适合做批量提取和自动化验证。5.1 用 tshark 一条命令导出所有 HTTP 对象# 导出所有 HTTP 请求的 URL 和 Host tshark -r B.pcapng -Y http.request -T fields -e http.host -e http.request.uri # 导出所有含 POST 的请求体 tshark -r B.pcapng -Y http.request.method POST -T fields -e http.file_data-Y是显示过滤器和 Wireshark 图形界面里的过滤栏语法完全一致。-T fields -e指定要输出的字段。第一条命令能快速列出所有访问过的 URL如果里面有upload.php、shell.php这类敏感路径一眼就能看到。第二条命令直接输出 POST 请求体适合找木马上传的数据。5.2 用 Python 脚本自动搜索 base64 特征import pyshark import base64 import re # 加载 pcapng 文件 cap pyshark.FileCapture(B.pcapng, display_filterhttp) # 正则匹配 base64 字符串长度大于 20 的连续 base64 字符 b64_pattern re.compile(r[A-Za-z0-9/]{20,}) for pkt in cap: try: if hasattr(pkt, http) and hasattr(pkt.http, file_data): data pkt.http.file_data matches b64_pattern.findall(data) for m in matches: try: decoded base64.b64decode(m) # 检查解码后是否是 zip 或 PE 文件 if decoded[:2] bPK or decoded[:2] bMZ: print(f发现可疑文件长度 {len(decoded)} 字节) with open(extracted.bin, wb) as f: f.write(decoded) except Exception: pass except AttributeError: passpyshark是 tshark 的 Python 封装FileCapture加载文件display_filter在加载时就过滤减少内存占用。正则[A-Za-z0-9/]{20,}匹配长度超过 20 的 base64 字符串因为太短的可能是普通文本。解码后检查文件头PK是 zipMZ是 Windows 可执行文件。这个脚本能自动把流量里的 base64 编码文件提取出来省去手动复制粘贴的功夫。5.3 验证提取结果的完整性提取出来的文件不一定完整可能因为 TCP 分段、丢包或者编码问题导致内容缺失。验证方法# 检查文件类型 file extracted.bin # 检查文件大小是否合理 ls -l extracted.bin # 如果是 zip测试完整性 unzip -t extracted.bin # 如果是图片用 identify 检查 identify extracted.binunzip -t会测试 zip 文件的 CRC 校验如果有损坏会报错。identify是 ImageMagick 的工具能读出图片的尺寸和格式如果文件头被改过它会直接报错这时候就需要回到 vim 的 xxd 模式手动修复。注意自动化脚本适合批量处理但比赛环境里时间有限手动 Follow TCP Stream 往往比写脚本更快。脚本的价值在于赛后复盘和日常练习。5.4 一个我踩过的坑有一次做类似的流量题我用 tshark 导出了所有 HTTP 对象但漏掉了 HTTPS 流量。后来才发现题目里的关键文件是通过 HTTPS 传输的虽然内容加密了但 TLS 握手阶段的 SNI 字段暴露了目标域名而证书里的 CN 字段又暴露了服务器信息。从那以后我每次分析 pcap 都强制走一遍协议分层统计先确认有没有非 HTTP 的协议再决定过滤策略。希望帮到你。本文还有配套的精品资源点击获取