打开pcap文件的流量那一刻，我习惯性地先看协议分布。分析TCP占了八成，流量HTTP请求稀稀拉拉，分析DNS查询倒是流量不少。这种流量包十有八九是分析精心构造的——攻击者不会傻到把flag明文放在HTTP头里，但也不会完全不留痕迹。流量真正的分析线索往往藏在那些看似无害的请求里。

我按时间轴排序，流量发现每隔三秒就有一个对`/images/logo.png`的分析请求。频率太规整了，流量不像真人浏览。分析随手点开一个，流量UA字符串末尾多了个`;base64`标记。分析解码出来是流量个数字，连起来是`115,101,99,117,114,101`——ASCII码。转成字符就是“secure”，但这只是开头。流量分析的精髓在于你要区分哪些是噪音，哪些是信号。这种周期性请求就是典型的隐蔽信道，每个请求的URL参数里可能都藏着半个字节。

继续往下翻，看到一个异常大的POST请求，足足有2MB。正常表单提交不会这么大。导出body一看，是个加密的zip压缩包。密码？我注意到DNS查询里有个子域名是`key.dnslog.cn`，响应报文里TXT记录的值是`p@ssw0rd`。这种把密钥藏在DNS解析记录里的做法，在真实攻击中很常见，因为DNS流量通常被防火墙放行。

解压出来是个图片文件。用binwalk扫一下，尾部有附加数据。提取出来是个文本文件，内容是`flag{ traffic_analysis_is_art}`。到这里本该结束了，但我总觉得太顺利。回头检查那个图片的EXIF信息，发现GPS坐标指向本地一家咖啡馆。这可能是干扰项，也可能是攻击者留下的真实物理位置线索——CTF出题人有时候就爱玩这种双关。

最后提醒一句：别只盯着HTTP看。DNS、ICMP、甚至TCP的seq号都能藏数据。上次遇到个题，flag被拆成比特位放在TCP窗口大小字段里，每包一个bit，要重组几百个包才能还原。那种题真考验耐心，但解出来那刻的爽感也是真高。流量分析的本质就是跟出题人玩捉迷藏，他藏得越深，你就越要跳出惯性思维去猜他下一步想藏哪。