流量分析与协议逆向

引言

流量分析方向的题目给你一份 pcap（或 pcapng）文件，要求你从中还原出被隐藏的信息、被传输的文件、或者某个协议的通信内容。它看起来门槛最低——Wireshark 打开就能看——但真正的题目往往把信息藏在三层以上的嵌套里：一段自定义二进制协议的载荷里，套着一层加密，加密的密钥藏在另一条流的某个字段里。

工程上的难点集中在三处。第一是**「看什么」的问题**：一份 pcap 可能包含几十万条包，漫无目的地滚动是纯粹的浪费，必须先做统计把范围缩到几条可疑的流。第二是**「字段是什么」的问题**：自定义协议的载荷是裸字节，没有语义标注，必须靠对比多条同类型报文来推断字段边界与含义。第三是**「解不开」的问题**：TLS 流量在默认情况下是完全不可读的，能否解密取决于题目有没有留下密钥材料或导出方式。

本文按「流程 → pcap 与过滤 → 统计定位 → 协议逆向 → TLS 解密 → 自定义协议 → 隐写与隧道 → 恶意流量 → 检测防御」的顺序组织。它比 Misc 方向隐写与取证 里对 pcap 的入门介绍更深入一层，专注于「协议语义的还原」；网络协议栈本身的原理可参考 网络协议基础 与 TCP 深入解析 ，生产环境的流量可观测性建设可见 NetFlow 与流量可观测性 。

目录

1. 流量题的形态与分析流程
2. pcap 格式与 Wireshark 过滤表达式
3. 统计与追踪：从海量流量中定位异常
4. 协议逆向与字段推断
5. TLS 解密的可行路径
6. 自定义二进制协议解析
7. 流量中的隐写与隧道
8. 恶意流量特征提取
9. 解题流程与检测防御

1. 流量题的形态与分析流程

CTF 流量题按「信息藏在哪里」可以分成四类，识别题型就能立刻确定工具与顺序：

标准分析流程是固定的五步，按这个顺序走能省掉大量时间：

1 概览      文件有多大、包数多少、时间跨度多长
2 统计      协议分层、会话列表、端点排行 -> 找到占比异常的那几条流
3 追踪      对可疑流做 Follow Stream，看有无可读内容
4 导出      尝试导出对象（HTTP/SMB/TFTP），拿到原始文件
5 深挖      前四步无果才进入协议逆向或解密

绝大多数题目前三步就能解决，因为出题人通常会给一条明显的线索流。真正的难题在第 5 步，那时才需要协议逆向与密码学手段。

一条重要的经验是先看元数据再看内容：capinfos 会告诉你文件的包数、时间范围、平均包长、捕获系统；这些元数据本身常常就是提示（例如「时间跨度恰好 60 秒」暗示按秒对齐的编码，「平均包长异常小」暗示分片隐藏）。这一步几乎零成本，却能确定后续方向。

# 本地教学：pcap 元数据概览（对自建与题目附件）
capinfos capture.pcap
# 输出含：文件类型、包数、时间范围、数据量、平均包长、链路层类型
tshark -r capture.pcap -q -z io,phs      # 协议分层统计

2. pcap 格式与 Wireshark 过滤表达式

pcap 的结构极其简单，理解它能让你在工具失灵时手工解析：

全局头（24 字节）
  magic number   0xa1b2c3d4（微秒）/ 0xa1b23c4d（纳秒），字节序由此判断
  version        通常 2.4
  snaplen        每个包最多捕获的字节数
  network        链路层类型（1 = Ethernet，113 = Linux cooked）

每个包的记录头（16 字节）
  ts_sec / ts_usec   时间戳
  incl_len           实际捕获长度
  orig_len           原始长度（若小于 incl_len 说明被截断）

pcapng 是新一代格式，支持多接口、注释与更精细的时间戳，用 editcap -F pcap 可转回 pcap。包被截断（incl_len < orig_len）是常见陷阱：题目可能故意只保留每个包的前 64 字节，导致载荷不完整，需要从其他包拼接。

Wireshark 的显示过滤器是效率的核心，必须熟练到不用查文档：

ip.addr == 10.0.0.5                按 IP 过滤（双向）
tcp.port == 8080                   按端口
http.request.method == "POST"      只看 POST 请求
tcp contains "flag"                载荷里含指定字符串
frame contains 66:6c:61:67         载荷里含指定字节序列
dns.qry.name contains "exfil"      按 DNS 查询名过滤
tcp.flags.syn == 1 && tcp.flags.ack == 0   只看 SYN
tcp.stream == 3                    只看第 3 条 TCP 流
!(arp || icmp || dns)              排除常见噪声

几个高价值技巧：用 contains 直接搜字符串比逐个流看快得多；tcp.stream 是流级别的钥匙，定位到可疑流后所有后续分析都围绕它展开；过滤器支持正则（matches），适合匹配有规律的自定义格式；导出过滤器命中的包（File > Export Specified Packets）能把大文件裁成小文件，加速后续处理。

# 本地教学：命令行过滤与裁剪（等价于 Wireshark 的显示过滤器）
tshark -r a.pcap -Y 'http.request.method == "POST"' -T fields \
       -e ip.src -e http.host -e http.request.uri
tshark -r a.pcap -Y 'tcp contains "flag"' -w hit.pcap
editcap -r a.pcap small.pcap 1-100        # 只保留前 100 个包

3. 统计与追踪：从海量流量中定位异常

统计的作用是「把注意力从 10 万个包缩到 3 条流」。Wireshark 的 Statistics 菜单与 tshark 的 -z 参数提供同一批数据：

# 本地教学：四类统计（覆盖绝大多数定位需求）
tshark -r a.pcap -q -z io,phs              # 协议分层：看哪些协议占比异常
tshark -r a.pcap -q -z conv,tcp            # TCP 会话表：看哪些会话数据量大
tshark -r a.pcap -q -z endpoints,ip        # 端点排行：看哪些 IP 最活跃
tshark -r a.pcap -q -z io,stat,1           # 按秒统计吞吐：看流量是否周期性

四个统计各自的用途：

• 协议分层揭示「有没有不该出现的协议」。一份看起来是 HTTP 的流量里出现大量 DNS 或 ICMP，往往就是隧道。
• 会话表按数据量排序，最大的那条通常是文件传输，最小的那条可能藏着单包指令。
• 端点排行找「只有一个外部 IP」的异常——内网主机集体访问某个陌生外网 IP 是典型的 C2 特征。
• 按秒统计能看出周期性，这对「定时外发」类隐蔽信道特别有效。

Follow TCP/UDP Stream（tshark 里用 -z follow,tcp,ascii,3）是第二步：把一条流的载荷按方向拼接成可读文本。多数题目的答案在 Follow Stream 的窗口里就能直接看到。

# 本地教学：追踪指定流并导出为文本
tshark -r a.pcap -q -z follow,tcp,ascii,3
tshark -r a.pcap -q -z follow,tcp,raw,3     # 原始十六进制形式

当 Follow Stream 出现大量不可读字节时，就进入「载荷是二进制」的情形：先确认流的端口与协议（-z conv,tcp 给出端口），再判断「是已知协议还是自定义协议」。已知协议（如 HTTP/2、Redis、MySQL）可以直接用 Wireshark 的解析器或 -d 参数强制指定解码；自定义协议才需要下一节的字段推断。

4. 协议逆向与字段推断

协议逆向的目标是回答三个问题：报文边界在哪、每个字段多少字节、字段的语义是什么。

边界识别是第一步。TCP 是字节流，报文的边界只能靠协议自身的结构判断，常见三种设计：

方式一：固定长度      每个报文长度固定（如 64 字节），按长度切分
方式二：长度前缀      报文开头 N 字节存「后续长度」，先读长度再读内容
方式三：分隔符        用特定字节序列（如 0x0A 或 0xFF 0xFF）分隔

长度前缀是最常见的，因为它在流式解析里最高效。判断方式很简单：取若干个报文的开头几个字节，看它们是否与「该报文的总长度」成固定关系。

# 教学片段：从载荷里推断「长度前缀」的位置（本地靶场流量）
payloads = load_payloads("custom.pcap")     # 每条流的载荷（bytes）
for i in range(4):
    # 假设第 i 到 i+2 字节是长度前缀，检查它是否等于剩余长度
    ok = sum(1 for p in payloads if len(p) >= i + 3 and int.from_bytes(p[i:i+2], "big") == len(p) - i - 2)
    print(f"offset {i}: 匹配率 {ok}/{len(payloads)}")

字段语义推断靠「控制变量法」：把同类型的多个报文对齐，看哪些字节恒定（魔数、版本、类型）、哪些随操作变化（命令码、参数）、哪些随内容长度变化（长度字段、序号）。恒定的字节是协议头，变化的字节是载荷。

对齐对比法（教学示例，同一命令的多个报文）
  报文1: 55 AA 01 00 05 68 65 6C 6C 6F
  报文2: 55 AA 01 00 0B 77 6F 72 6C 64 ...
  报文3: 55 AA 02 01 03 61 62 63
  -----  ------ -- -- -- -----------
  魔数   版本 类型 标志 长度 载荷
  55AA 恒定；01/02 是命令类型；第 5 字节是载荷长度

时序分析是容易被忽略的一维：有些协议把信息编码在「包的顺序」或「包之间的时间间隔」里。若载荷内容看起来毫无意义，检查时间间隔是否呈离散的几档（例如恰好是 0.1s 与 0.2s 两种），那可能是二进制编码。这与 Misc 方向隐写与取证 里提到的「帧间延迟隐写」是同一思路。

校验字段的处理：很多协议尾部有校验和（CRC16、CRC32、异或校验）。识别方法是最后几个字节与前面内容存在确定关系；确定算法后即可用它验证「你切分的报文边界是否正确」——如果按你的切分算出的校验与报文里的不符，说明边界错了。

5. TLS 解密的可行路径

TLS 流量默认不可读，解密能力取决于题目留下的材料。三条路径按可行性排序：

路径一：拿到会话密钥（SSLKEYLOGFILE）。TLS 1.3 及支持前向保密的 TLS 1.2，其密钥由 ECDHE 协商，抓包本身无法解密，但客户端可以把「每个会话的密钥」写到日志文件（浏览器与 curl 都支持 SSLKEYLOGFILE 环境变量）。题目若提供这样的密钥日志，Wireshark 里配置 Preferences > Protocols > TLS > (Pre)-Master-Secret log filename 即可解密全部流量。

# 本地教学：生成密钥日志并解密（自建客户端与服务端）
export SSLKEYLOGFILE=/tmp/keys.log
curl -v "$TARGET" -o /dev/null       # TARGET 为自建服务端的地址
# 之后在 Wireshark 里指定 /tmp/keys.log，HTTP/2 与 TLS 载荷即可解密
tshark -r tls.pcap -o tls.keylog_file:/tmp/keys.log -Y http2 -T fields -e http2.data.data

路径二：拿到服务器私钥（仅限 RSA 密钥交换）。若 TLS 使用 RSA 密钥交换（而非 ECDHE），且题目给出服务器私钥，可以直接解密。配置方式是在 Wireshark 的 RSA keys list 里填 IP、端口与私钥文件。TLS 1.3 与启用 ECDHE 的 TLS 1.2 不适用——前向保密正是为了防这一类解密。

路径三：中间人（仅限自建环境）。在授权靶场中部署代理（如 mitmproxy）并让客户端信任代理的根证书，可以实时看到明文。这条路径在真实场景里需要客户端信任代理证书，属于可控环境下的手段，不适用于任意抓包。

判断一份 TLS 流量属于哪种情形，看握手报文：

# 本地教学：判断密钥交换方式与 TLS 版本
tshark -r tls.pcap -Y 'tls.handshake.type == 2' -T fields \
       -e tls.handshake.version -e tls.handshake.extensions_supported_group
# 若出现 x25519 / secp256r1 等 ECDHE 组，则必须有会话密钥才能解密

三个实践要点。第一，解密失败的常见原因是密钥日志不完整——它必须覆盖「建立该会话的那个进程」的完整运行期。第二，TLS 1.3 的密钥日志格式与 1.2 不同，需要较新版本的 Wireshark 才能解析。第三，若题目是自研的加密协议而非标准 TLS，那么解密密钥通常硬编码在某个客户端二进制里，此时「流量分析」就变成了「逆向 + 解密」的联合题。

6. 自定义二进制协议解析

当协议完全自定义时，解析工作需要「先聚类、再对齐、后建模」。

聚类是按「报文长度」与「开头几字节」把载荷分组，同组内大概率是同一种报文类型：

# 教学片段：按长度与前缀聚类（本地靶场流量）
from collections import Counter, defaultdict
groups = defaultdict(list)
for p in payloads:
    key = (len(p), p[:2])          # 长度 + 魔数/命令码前缀
    groups[key].append(p)
for key, items in sorted(groups.items(), key=lambda kv: -len(kv[1])):
    print(f"len={key[0]} prefix={key[1].hex()} count={len(items)}")

聚类之后对每一组做逐字节对齐，输出「每个位置上的取值分布」——恒定位置是头部字段，多值位置是类型码，随机位置是载荷。

# 教学片段：逐字节对齐，找出恒定字节与可变字节
def align(group):
    width = max(len(p) for p in group)
    for i in range(width):
        vals = {p[i] for p in group if i < len(p)}
        kind = "CONST" if len(vals) == 1 else ("VAR" if len(vals) < 8 else "DATA")
        sample = sorted(vals)[:4]
        print(f"byte {i:2d}: {kind:5s} {[hex(v) for v in sample]}")

输出的形态大致是这样，一眼就能读出结构：

byte  0: CONST 0x55        魔数高字节
byte  1: CONST 0xaa        魔数低字节
byte  2: VAR   [0x1, 0x2, 0x3]   命令码
byte  3: CONST 0x0         保留位
byte  4: VAR   [0x5, 0xb, 0x3]   长度字段（与载荷长度相关）
byte  5: DATA                    载荷起点

建模是把推断出的结构写成解析器，然后用「往返验证」检验：把解析出来的字段重新拼回去，看是否与原载荷逐字节一致。一致说明模型正确，不一致说明某个字段的边界或端序判断错了。端序（大端/小端）的判断方法是看长度字段：若某条报文的长度字段是 0x0005，大概率大端；若是 0x0500，大概率小端。

# 教学片段：自定义协议的解析器骨架（往返验证）
import struct
def parse(p):
    magic, cmd, flag, length = struct.unpack(">HBBH", p[:6])
    assert magic == 0x55AA, "魔数不匹配"
    body = p[6:6 + length]
    return {"cmd": cmd, "flag": flag, "body": body}

def build(msg):
    return struct.pack(">HBBH", 0x55AA, msg["cmd"], msg["flag"], len(msg["body"])) + msg["body"]

for p in payloads:
    assert build(parse(p)) == p, "往返验证失败，字段边界有误"

协议逆向的完整案例可以这样串联：先聚类发现「长度 12、前缀 55AA」的一类报文；逐字节对齐后发现第 2 字节是三值命令码、第 4 字节是长度；解析载荷发现是 ASCII 文本；把所有同类报文的载荷按命令码拼接，得到完整的传输内容。

7. 流量中的隐写与隧道

流量隐写与隧道的共同点是「用看似正常的协议传不该传的数据」，区别在于隐写追求不可见、隧道追求可用带宽。

DNS 隧道是最常见的一类：把数据编码进域名标签（data.chunk1.evil.com），或用 TXT 记录承载载荷。识别信号有三条：子域名极长或熵极高；同一域名下的子域数量巨大；查询类型异常（大量 TXT 或 NULL 记录）。DNS 协议的基础可见 DNS 协议解析 。

# 本地教学：DNS 隧道特征提取（自建靶场流量）
tshark -r dns.pcap -Y 'dns.flags.response == 0' -T fields -e dns.qry.name \
  | awk -F. '{ print length($1), $0 }' | sort -rn | head
# 超长子域、高熵标签是隧道的第一信号

ICMP 隧道把数据放进 ICMP 的载荷里。识别信号是「ICMP 包数异常多」且「每个包的载荷长度恒定且较大」——正常的 ping 载荷是固定的小值（Linux 默认 56 字节、Windows 默认 32 字节），隧道会显著偏离这个模式。

HTTP 隧道更隐蔽，常见形态有：把数据放进 Cookie、User-Agent 等头部字段（体积远超正常值）；用自定义 HTTP 方法或 URL 路径传数据；在 HTTP/2 的 HEADERS 帧里塞 padding。识别方法是统计「同一字段在不同请求里的长度分布」，正常客户端的值高度重复，隧道的值则逐次变化。

时序与包序隐写是最难发现的一类：数据不在载荷里，而在「包之间的时间间隔」或「包的到达顺序」中编码。检测方法是对流做时间差直方图，若间隔呈现离散的少数几档（而非连续分布），就有编码嫌疑。

# 教学片段：时间间隔直方图（本地靶场流量）
import collections
deltas = [round(b - a, 3) for a, b in zip(times, times[1:])]
hist = collections.Counter(deltas)
for d, c in hist.most_common(10):
    print(f"间隔 {d}s 出现 {c} 次")     # 若只有 2~3 档且分布极不均匀，疑似时序编码

载荷内隐写是另一类：载荷本身是合法的协议报文，但其中某些「不重要的字段」（如 TCP 的保留位、IP 的 ID 字段、HTTP 头部的顺序）被用来承载数据。这类隐写需要知道协议规范里「哪些位是不影响语义的」，才能发现异常。

# 本地教学：检查 IP ID 字段是否被用作隐蔽信道
tshark -r a.pcap -T fields -e ip.id | sort | uniq -c | sort -rn | head
# 正常的 IP ID 在流内是递增的；若呈少数几个值循环，可能是编码

8. 恶意流量特征提取

CTF 里有一类题目给的是「疑似被入侵的主机流量」，要求你还原攻击链。这与真实的流量侧检测（IDS/NDR）方法一致。

按攻击链阶段组织特征：

# 本地教学：扫描与爆破的识别（自建靶场流量）
# SYN 扫描：大量 SYN 但无后续 ACK
tshark -r scan.pcap -Y 'tcp.flags.syn == 1 && tcp.flags.ack == 0' \
  -T fields -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn | head
# HTTP 爆破：同一 IP 对同一路径的大量 401/403
tshark -r brute.pcap -Y 'http.response.code == 401' \
  -T fields -e ip.src -e http.request.uri | sort | uniq -c | sort -rn | head

心跳检测是识别 C2 的核心方法：计算同一会话相邻包的时间差，若方差极小（如始终在 30s ± 0.5s），就是程序化心跳而非人类行为。

# 教学片段：用时间差方差识别心跳（本地靶场流量）
import statistics
for stream in streams:
    deltas = [b - a for a, b in zip(stream.times, stream.times[1:])]
    if len(deltas) >= 5 and statistics.pstdev(deltas) < 0.5:
        print(f"流 {stream.id} 疑似心跳，平均间隔 {statistics.mean(deltas):.2f}s")

文件还原与静态分析是链条的下一步：把 HTTP/SMB/TFTP 传输的对象导出，计算哈希（与威胁情报平台比对），再做静态分析（file、strings、PE 结构）。若拿到的是加密载荷，需要先提取密钥——这通常来自同一份流量里的另一条流（如首次通信的明文密钥交换），这也是 CTF 题目最常见的「跨流关联」设计。

特征提取的产物应当是一份结构化记录：时间线（谁在什么时候做了什么）、IOC 列表（域名、IP、文件哈希、User-Agent）、以及攻击链的阶段划分。这份记录既是 CTF 的答案形式，也是真实应急响应的交付物。

9. 解题流程与检测防御

把前面的方法固化成一份可复用的解题流程：

1 capinfos / io,phs        概览：包数、时间跨度、协议分层
2 conv + endpoints         定位异常会话与端点
3 Follow Stream            快速看可读内容，多数题目到此结束
4 导出对象                 还原 HTTP/SMB/TFTP 传输的文件
5 载荷聚类 + 字节对齐      自定义协议的字段推断
6 时间差直方图             排查时序隐写与心跳
7 找密钥材料               TLS 密钥日志、硬编码密钥、明文密钥交换
8 关联与还原               跨流关联，拼接完整信息

防御侧对应的是同一套能力，只是方向相反：

• 出口流量基线：为每个内网主机建立「正常外发体量与目的分布」的基线，偏离即告警。这是发现数据外发与 DNS 隧道最有效的手段。
• DNS 审计：记录并分析所有 DNS 查询，对超长子域、高熵标签、异常记录类型建立规则。DNS 是唯一「几乎不可能被完全封堵」的协议，因此也是隧道的第一选择。
• TLS 可见性：在企业出口部署 TLS 解密（需合规告知与策略）或至少采集 SNI 与证书信息，否则加密流量是不可见的盲区。
• 心跳与周期性检测：对会话的时间间隔做统计，周期性极强的长连接是 C2 的强特征。
• 对象还原与沙箱：对出口传输的可执行文件自动还原并送沙箱分析，切断「下载即执行」的链条。
• 元数据留存：NetFlow/IPFIX 的留存成本远低于全流量留存，能在事后回溯「谁和谁通信过」，是性价比最高的可观测性投入。具体建设方式见 NetFlow 与流量可观测性 。

一条常被忽略的原则是**「先留存，再分析」**：流量分析的能力上限由留存决定。事件发生后再想分析，若没有留存对应的元数据或全流量，任何技巧都无从施展。

权衡取舍

选择的核心是「信息在哪一层」：载荷层能读就读载荷，读不了就推断结构；结构也推不出就查密钥；都没有则考虑时序与字段隐写。按层推进，不要跳步。

常见坑清单

1. 包被截断（snaplen 太小）：incl_len < orig_len 说明载荷不完整，先确认能否从其他包拼接，别急着下结论。
2. 只在大文件里滚动而不做统计：几十万包靠手工翻看是纯粹的浪费，io,phs 与 conv,tcp 是第一步。
3. 忽略 TLS 1.3 的密钥日志差异：旧版 Wireshark 无法解析 TLS 1.3 的密钥日志格式，解密失败先升级工具。
4. 以为给了私钥就能解所有 TLS：ECDHE 前向保密使私钥解密失效，只有 RSA 密钥交换才可行。
5. 自定义协议端序判断错：长度字段读反会导致报文边界全错，用「多条报文交叉验证」确定端序。
6. 按固定长度切分却遇到变长报文：混合类型的协议要按类型码分别处理，不能假设全局定长。
7. 忽略时间维度：载荷看起来无意义时，检查时间间隔与包序，时序隐写只在这一维可见。
8. 把 DNS 隧道当成正常查询：超长子域与高熵标签是明确信号，先算标签长度分布。
9. 导出的对象不校验哈希：还原文件后应算哈希并与情报比对，避免在损坏文件上浪费时间。
10. 对未授权流量做分析：本文方法适用于 CTF 附件、自建靶场与书面授权范围内的流量；对他人网络流量的捕获与分析在多数司法辖区受法律限制。

小结

流量分析的核心是「分层定位 + 逐层剥离」。先做统计把范围缩小，再用 Follow Stream 看可读内容，读不到就聚类推断协议结构，结构也推不出就找密钥或排查时序隐写。这条路线的每一步都有明确的判断标准与工具，按顺序推进就不会迷路。

能力提升的关键在两处。一是对协议规范的熟悉度：知道 DNS 的标签长度上限、HTTP 头部的常见取值范围、TCP 的保留位有哪些，才能一眼看出「这里不正常」。二是脚本化能力：tshark 的字段导出配合几行 Python，能把人工需要几小时的对齐工作压缩到几分钟。

最后是视角的统一：CTF 里你在「还原别人藏起来的信息」，生产环境里你在「发现别人藏起来的流量」。两者的方法论完全相同，只是目的相反。把这份能力落到出口基线、DNS 审计、心跳检测与元数据留存上，就是流量侧最扎实的防御体系。