PCAP 文件格式详解从字节布局到逐层解析一.前言pcap 有两种常见格式一个是经典 pcap.pcaplibpcap/tcpdump 的老格式另一个是pcapng.pcapngWireshark 默认的新格式本文章描述的是经典 pcap为后面的pcap 解析器——网络抓包项目打下基础但我们还是简单的说一下这两种格式的背景。为什么会有两种格式pcap经典格式由 libpcap / tcpdump 在 1990 年代定义长期是事实标准。结构极简一个文件只能记录一种链路类型。pcapngPCAP Next Generation为弥补 pcap 的局限而生——支持多网卡接口、每接口独立的时间戳精度、注释与元数据、多段拼接。Wireshark 现在默认存 pcapng但 libpcap 也早已能读写1.8 读、1.9 写。所以拿到一个抓包文件第一步永远是看前 4 字节前 4 字节格式a1 b2 c3 d4pcap微秒时间戳a1 b2 3c 4dpcap纳秒时间戳0a 0d 0d 0apcapngSHB 块1f 8bgzip 压缩过的抓包文件先解压其他不是抓包文件二.pcap概念pcap 文件就是一串抓到的原始链路层字节每条前面加 16 字节的什么时候抓的、抓了多少的小标头整份文件开头再加 24 字节的这份文件是哪种链路、什么精度的说明。它没有任何压缩和加密文件大小 ≈24 16 × 包数 所有包字节数。三、pcap整体结构┌──────────────────────────────────────────┐ │ 全局头 Global Header 固定 24 字节 │ ← 整份文件只有 1 个 ├──────────────────────────────────────────┤ │ 记录头 Packet Header 固定 16 字节 │ │ 包数据 Packet Data incl_len 字节 │ ← 第 1 个包 ├──────────────────────────────────────────┤ │ 记录头 16 字节 包数据 … │ ← 第 2 个包 ├──────────────────────────────────────────┤ │ … 一直到文件末尾EOF │ └──────────────────────────────────────────┘注意文件里没有包总数字段也没有文件总长字段。只能一条一条顺序往下读靠读不下去来判断结束所以文件尾部被截断是常见现象解析器必须容忍。四、全局头24 字节偏移长度字段类型含义04magic_numberu32魔数同时用来说明字节序和时间戳精度42version_majoru16主版本号通常262version_minoru16次版本号通常484thiszonei32GMT 与本地时间差历史遗留恒为 0124sigfigsu32时间戳有效位数历史遗留恒为 0164snaplenu32抓包时最多截取多少字节常见 65535 / 262144204networku32链路层类型LinkType1 以太网4.1 魔数同时表示字节序和时间戳精度它的首要职责是判断字节序但同一个 32 位值还兼任时间戳精度标记。原因是纳秒版是在原始格式上改了一位扩展出来的——把0xa1b2c3d4改成0xa1b23c4dc3d4→3c4d既和其他格式区分得开翻转后的形态0x4d3cb2a1也唯一可辨。下面这张表以我现在的 x86小端机器为前提文件开头 4 字节写入方字节序时间戳精度我这台机器要翻转吗d4 c3 b2 a1小端微秒不用a1 b2 c3 d4大端微秒要4d 3c b2 a1小端纳秒libpcap 1.5 支持不用a1 b2 3c 4d大端纳秒要翻转与否只取决于文件字节序和读取方字节序是否相同。读取方是 x86小端所以规则就是小端文件不翻、大端文件翻。4.2 snaplen截断从哪来抓包时如果每个包都完整保存磁盘和内存会吃不消尤其大包和突发流量。snaplen就是每个包最多存这么多字节超出部分直接丢弃。于是记录头里的incl_len实际存了多少可能小于orig_len网线上真实长度分析时这个包有多少有效数据要用incl_len这个包在线路上多大要用orig_len一个 TCP 报文只抓到前 54 字节以太网 14 IP 20 TCP 20时应用层数据就是永远看不到的——这不是 bug是截断4.3 network决定从哪里开始解析这个字段是整份文件共享的它告诉我们包数据的第一个字节是什么协议的头。常见值值LinkType说明0NULLBSD 回环开头是 4 字节地址族主机字节序1ETHERNET以太网绝大多数文件9PPP点对点101RAW裸 IP包数据直接就是 IPv4 / IPv6 头105IEEE802_11Wi-Fi 帧113LINUX_SLLLinux “any” 抓包16 字节 SLL 头127IEEE802_11_RADIOTAPWi-Fi Radiotap228 / 229IPV4 / IPV6纯 IP276LINUX_SLL2新版 SLL20 字节头五、数据包记录5.1 包头记录头16 字节同一个东西有两个叫法包头和记录头指的都是这 16 字节。别和后面包的以太网头 14 字节混了包头是 pcap 文件加的以太网头是网络包自带的两者毫无关系只是都叫头。偏移长度字段含义04ts_sec秒部分Unix 时间戳44ts_usec微秒部分纳秒版 magic 时这里是纳秒84incl_len本条记录里实际存了多少字节124orig_len该包在网线上的原始长度紧接着就是incl_len字节的包数据没有任何对齐填充下一条记录紧跟在后面。5.2 两个长度字段为什么要分开orig_len ────────────────► 网线上真实长度比如 1514 字节 snaplen 65535 时 incl_len ────────────────► 文件里存了 1514 字节没截断两者相等 snaplen 96 时 orig_len ────────────────► 1514 incl_len ──────────────► 96只留了头部载荷被砍掉判断数据完整性、计算这条流一共传了多少字节靠的就是这两个字段的区别。六、包数据里面套娃式分层链路 → 网络 → 传输 → 应用包数据的起点由network决定下文按最常见的以太网讲。每层都在自己头部里声明我的载荷是什么解析就是一个不断推进偏移、递减剩余长度的循环。6.0 每一层的数据部分就是下一层的整体。包数据 以太网帧 └─ [以太网头 14B] IP 数据报 └─ [IPv4 头 20B] TCP 段 └─ [TCP 头 20B] 应用数据 18B“头多大”“下一层是谁”都是每层自己告诉你的层头多大谁说的下一层是谁谁说的数据部分从哪开始记录层容器固定 16 字节不适用它不是协议上一条记录结束处 16链路层 · 以太网固定 14 字节有 VLAN 就是 18偏移 12 的Type0x0800 IPv4帧内偏移 14网络层 · IPv4IHL × 4典型 20偏移 9 的Protocol6 TCPIP 头内偏移IHL × 4传输层 · TCPDataOffset × 4典型 20没有这个字段 → 靠端口号认应用协议80 HTTPTCP 头内偏移DataOffset × 4应用层没有头——剩下的全是它最上面应用层没有下一层是谁的字段——TCP / UDP 只有端口号所以这是不是 HTTP往往是猜出来的这也是 Wireshark 会猜协议的原因。读下面的字段表之前先记住每张表里的偏移都是相对本层起点的不是相对文件、也不是相对整个包。IP 头那张表的偏移 0指的是 IP 头的第一个字节。6.1 数据链路层以太网 II14 字节头偏移长度字段06目的 MAC66源 MAC122类型 EtherType14—载荷末尾 4 字节4FCS 帧校验libpcap 通常不保存常见 EtherType值协议0x0800IPv40x0806ARP0x86DDIPv60x8100VLAN802.1Q0x88A8QinQ802.1ad0x8847MPLS0x8864PPPoE 会话0x88CCLLDPVLAN 会改变偏移0x8100后面是 2 字节 TCI 2 字节真正的 EtherType于是头从 14 变成 18 字节还能叠两层QinQ。正确写法是循环读 EtherType直到不是 VLAN 为止而不是写死 14。6.2 网络层IPv420 ~ 60 字节头IPv4 头紧跟在 14 字节以太网头之后所以它的起点 以太网头起点 14。完整字段表IPv4 头 20 ~ 60 字节下表偏移都相对 IP 头起点偏移长度字段说明01版本 首部长度高 4 位 版本4低 4 位 IHL头长 IHL × 4最小 5 → 20 字节11DSCP ECN服务质量与拥塞标记一般忽略22总长度头 载荷的总字节数可能大于实际捕获到的字节被 snaplen 截断时42标识同一份原始数据切出来的所有分片共用这个编号62标志 分片偏移高 3 位R / DF / MF低 13 位是分片偏移单位 8 字节81TTL每过一跳减 1减到 0 就被丢弃防止包永远打转91协议载荷类型 → 决定下一层是谁102头校验和只校验 IP 头不含数据124源 IP164目的 IP20IHL×4 − 20选项少见记录路由、时间戳等有选项时头会长于 20 字节协议字段 → 下一层值下一层值下一层1ICMP47GRE隧道2IGMP50ESPIPsec 加密4IP-in-IP隧道51AHIPsec 认证6TCP58ICMPv617UDP89OSPF路由协议41IPv6 封装132SCTP偏移怎么推进传输层起点 IP 头起点 首部长度。注意不能写死 20——首部长度写在 IP 头第 1 个字节的低 4 位里要用第 1 个字节 0x0F再乘以 4 算出来。进这一层前的防御这一条记录至少要有34字节——34 以太网头 14 IP 头最小 20 不足 34 字节 → 连一个完整 IPv4 头都放不下 → 不解析分片是这里最大的陷阱分片偏移 ≠ 0的包后续分片里装的是纯数据片段没有 TCP / UDP 头MF1的首片虽有传输层头但载荷不完整。想正确解析就得先做重组否则只能跳过。分片IPv4 会把一份大数据切成多片每片单独成一个包发出MF 1后面还有分片MF 0这是最后一片DF 1不许分片分片会被丢弃分片偏移 ≠ 0这不是第一片里面没有 TCP / UDP 头只有一段裸数据想还原完整报文得按标识 分片偏移把同一组的片拼起来重组日常上网网页、ping、下载里基本见不到分片等真遇到再处理。6.3 网络层IPv6固定 40 字节头怎么认出来以太网类型是0x86DD而不是0x0800说明这一层装的不是 IPv4。固定 40 字节头偏移长度字段说明04版本(4b) 流量类别(8b) 流标签(20b)版本恒为 642载荷长度只算 40 字节固定头之后的部分61下一头部载荷类型但不一定是 TCP / UDP71跳数限制等价于 IPv4 的 TTL816源地址128 位2416目的地址128 位与 IPv4 的三个关键差别头是定长 40 字节没有 IHL不用算头长地址是16 字节128 位不是 4 字节下一层是谁写在一连串扩展头里要走一遍链才能找到 TCP / UDP值扩展头值扩展头0逐跳选项51AH43路由59无下一头部44分片60目的选项50ESP6 / 17 / 58TCP / UDP / ICMPv6所以 IPv6 的解析本质是个循环读下一头部 → 是扩展头就按它自己的长度往下跳 → 直到遇到 6 / 17 / 58 为止。6.4 传输层TCP典型 20 字节头这一层的任务读出端口号认出应用TCP 还多几个字段值得看。TCP 头紧跟在 IP 头之后起点 IP 头起点 首部长度。偏移长度字段用途0 / 22 / 2源端口 / 目的端口认应用53 DNS、80 HTTP、443 HTTPS44序号本报文第一个数据字节的编号把同一条连接的数据按顺序拼起来要靠它84确认号期望下次收到对方哪个序号ACK 置位时有效121数据偏移(高 4 位) 保留(3) NS(1)头长 高 4 位 × 4最小 5 → 20 字节131标志位8 个经典标志见下表142窗口大小对方还能接收多少字节流量控制162校验和覆盖 TCP 头 数据 伪首部182紧急指针只有 URG 置位时才有意义20数据偏移×4 − 20选项MSS、窗口扩大、SACK、时间戳等常见 12 字节 → 头变成 32 字节标志位(偏移13)怎么读把偏移 12 那 2 字节的低 8 位取出来用 0x00FF把高 8 位掩掉一位一个标志bit值标志含义00x01FIN断开连接10x02SYN请求建立连接20x04RST强制复位30x08PSH尽快交给应用层40x10ACK确认号有效50x20URG紧急指针有效60x40ECE显式拥塞通知ECN回显70x80CWR拥塞窗口已减小所以你看到的SYN, ACK就是这两位同时为 1——TCP 三次握手的第二步。6.5 传输层UDP固定 8 字节固定8 字节字段一览偏移长度字段说明0 / 22 / 2源端口 / 目的端口认应用53 DNS、67 / 68 DHCP42长度UDP 头 数据的总字节数最小 8即空数据62校验和可选IPv4 里允许填 0 表示没算关键结论UDP 头后面直接就是应用数据——应用层报文的起点 UDP 头起点 8。小坑长度字段在实际抓包里不一定可靠有的实现不填、IPv6 巨型帧里甚至是 0稳妥做法是用IP 总长 − IP 头长 − 8推算应用数据长度。6.6 应用层传输层载荷就是应用层报文本身。pcap只保存原始字节流不会标记这一段是什么应用协议识别和解析完全靠我们自己写的解析器。识别依据传输层端口号约定俗成不是绝对可靠常用应用协议速览应用协议默认传输层端口说明HTTPTCP80 / 8080TCP头后的载荷就是HTTP报文GET/POST等请求HTTPS(TLS)TCP443TCP头后是TLS加密报文无法直接读出明文DNSUDP53UDP头后直接是DNS报文12B固定DNS头 域名查询/应答DNSTCP53TCP头后载荷最前面多2字节长度字段之后才是DNS报文触发场景UDP应答512BTC1截断、主从服务器区域传输DHCPUDP67(服务器) / 68(客户端)UDP载荷为DHCP报文局域网分配IP用SSHTCP22远程登录加密TCP载荷SMTPTCP25邮件发送协议七.解析通用逻辑抓包代码流程解析以太网帧 → 拿到IP报文解析IP头判断协议号TCP(6) / UDP(17)解析TCP/UDP头读取源端口、目的端口根据端口判断应用类型取出传输层载荷交给对应应用层解析函数UDP应用起点 以太网14 IP头长 8TCP应用起点 以太网14 IP头长 (TCP数据偏移 × 4)对载荷按照该应用协议的格式解析