当前位置：首页 > 编程日记 > 正文

使用WinPcap和libpcap类库读写pcap文件（002）PCAP文件格式

编程日记 2024-06-12 00:00:00

本文基本翻译自https://wiki.wireshark.org/Development/LibpcapFileFormat，主要分析pcap文件的格式。

其中一些字段可能和现在的WinPcap类库里的字段不同，请结合当前WinPcap库分析。

libpcap文件格式

libpcap文件格式是TcpDump/WinDump，Wireshark/TShark，snort和许多其他网络工具中的主要抓包文件格式。

1 综述

这种文件格式是保存捕获网络数据的一个非常基础的格式。随着libpcap库成为了UN*X平台上“事实上的”网络捕获标准，它变成了开源世界里网络捕获文件的“普遍标准”（在商业网络捕获世界里似乎压根就没有像“普遍标准”这样的东西）。

Libpcap和libpcap的Windows接口“WinPcap”，使用同样的文件格式。

虽然有时候假设这种文件格式只适用于以太网（Ethernet），它可以用在许多不同的网络类型里面，在Wireshark支持的捕获媒体页面可以找到这样的例子；所有列出的类型都可以被libpcap文件格式处理。

基于libpcap的文件建议使用的文件扩展名是pcap。

Wireshark在wiretap库里处理所有捕获文件的I/O。你可以在wiretap/libpcap.c和.h文件里找到关于libpcap文件格式的更多细节。

2 文件格式

“在非官方的世界里”，存在有一些格式上的变化。下面将只说明在当前2.4版本里通用的格式。这个格式的版本已经很长时间没有改变过了（至少从1998年libpcap0.4开始），所以它的格式也不太可能发生改变，除了下面提到的PCAPng文件格式。

文件的一个官方变更版本是支持纳秒级精度时间戳的版本。当前libpcap和WinPcap的发行版不支持这种方式读取文件；只有在git trunk上的libpcap版本才支持这种读取。旧版本的Wireshark不能读取；当前版本的Wireshark可以读取并能显示完整的纳秒级分辨率时间戳。

文件有一个包含全局信息的全局头，后面跟着0个或多个捕获的包的记录，看起来就像这样：

Global Header

Packet Header

Packet Data

Packet Header

Packet Data

Packet Header

Packet Data

...

在捕获文件里的被捕获的包不需要像在网络上那样包含包中所有的数据；捕获文件可能只包含每个包的前N个字节。在这种捕获的形式里，这个N值叫做“snapshot length”或者捕获的“snaplen”。N可以是一个比包可能的最大长度还要大的值，这样可以确保捕获到的包没有被“切片”；在这种情况可以把这个值设为65535。

2.1 全局头

这个头是libpcap文件的开始，后面跟着第一个包头。

typedef struct pcap_hdr_s {guint32 magic_number;   /* magic number */guint16 version_major;  /* major version number */guint16 version_minor;  /* minor version number */gint32  thiszone;       /* GMT to local correction */guint32 sigfigs;        /* accuracy of timestamps */guint32 snaplen;        /* max length of captured packets, in octets */guint32 network;        /* data link type */
} pcap_hdr_t;

magic_number：用来检测自身文件格式和字节序。写文件程序写入0xa1b2c3d4时，以本地的字节序格式写入这个字段。读文件程序可以读出0xa1b2c3d4（同样的字节序）或0xd4c3b2a1（相反的字节序）。如果读文件程序读出相反的0xd4c3b2a1值，它就知道后面的字段也需要反过来。对于纳秒级分辨率文件，写文件程序写入0xa1b23c4d，与原来不同两个低位字节内部交换高低4位，而读文件程序将会读出0xa1b23c4d（同样的字节序）或0x4d3cb2a1（相反的字节序）。

version_major, version_minor：文件格式的版本号（当前版本号是2.4）

thiszone：后面包头的时间戳的GMT（UTC）和本地时区之间的修正，以秒为单位。例如如果时间戳在GMT（UTC），thiszone就是0。如果时间戳在中欧时区（阿姆斯特丹，柏林，……），时间是GMT+1:00，thiszone必须是-3600。实际上，时间戳一直在GMT，所以thiszone一直是0。

sigfigs：理论上，时间戳在捕获中的精确度；实际上，所有的工具设置这一字段为0。

snaplen：捕获的“snapshot length”（典型值是65535或更多，但是可能被用户限制），参看下面的incl_len vs. orig_len。

network：链路层头类型，指定包开始的头的类型（例如1表示Ethernet以太网，参看tcpdump.org's link-layer header typespage后获取更多细节）；这可以是各种各样的类型，例如802.11，带有多种无线电信息的802.11，PPP，令牌环网，光纤分布式数据接口等等。

注意：如果你需要一个用于libpcap文件的新的封装类型（network字段值），不要使用任何已经存在的值！也就是不要通过改变一个已经存在的条目来添加新的封装类型;避开已经存在的条目。另外，给tcpdump-workers@lists.tcpdump.org发邮件，申请一个新的链路层头类型值，并指定新值的用途。

2.2 Header记录（包）头

Each captured packet starts with (anybyte alignment possible):

每个捕获的包以下面的格式开始（所以字节尽可能对齐）：

typedef struct pcaprec_hdr_s {guint32 ts_sec;         /* timestamp seconds */guint32 ts_usec;        /* timestamp microseconds */guint32 incl_len;       /* number of octets of packet saved in file */guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

typedef struct pcaprec_hdr_s {

guint32ts_sec; /* timestamp seconds */

guint32ts_usec; /* timestamp microseconds*/

guint32incl_len; /* number of octets ofpacket saved in file */

guint32orig_len; /* actual length ofpacket */

} pcaprec_hdr_t;

ts_sec：包被捕获的日期和时间。这个值是距离1970年1月1日00:00:00GMT的秒数；这也被称作UN*X时间戳。你可以使用ANSI C标准中time.h里的time()函数来获取这个值，但是你也可以用更好的办法来获取这个时间戳的值。如果这个时间戳不是以GTM（UTC）为基准的，使用全局头中的thiszone字段来调整。

ts_usec：在常规的pcap文件中，这个字段表示包被捕获时的毫秒值，以ts_sec为基准偏移。在纳秒级分辨率文件中，这个值被捕获时的纳秒数取代，以ts_sec为基准偏移。要知道：这个值不能达到1秒（也就是1 000 000在常规的pcap文件；在纳秒级分辨率文件中这个值不能达到1 000 000 000）；达到这个值时，必须增长ts_sec来避免这种情况。

incl_len：实际捕获的和保存在文件中的包数据的字节数。这个值不应该比orig_len或全局头的snaplen值大。

orig_len：包被捕获时，在网络中显示的包的长度。如果incl_len和orig_len不同，实际保存的包大小被snaplen限制。

2.3 包数据

实际的包数据，以incl_len个字节的数据团形式紧跟在包头后面，没有明确的字节队列。

3 库

应该很容易实现读写libpcap文件的函数，这实在是一种简单的文件格式。然而，如果你想用一个库来达到这个目的，或者如果你真的需要从一个实时的网络中捕获包，可以用下面这些库来做这些事：

libpcap：原始的这种文件格式（适用于基于UN*X的系统）

WinPcap：基于Windows的libpcap版本

还有适用于许多编程语言的封装可用（但是你必须已经安装了上面库中的一个）：

Net::Pcap：基于Perl语言的libpcap封装

Jpcap：基于JAVA语言的libpcap封装

python-libpcap：基于Python语言的libpcap封装

Ruby/Pcap：基于Ruby的libpcap封装

你可以给你最喜欢的编程语言添加一个libpcap封装，或者如果缺少这种封装就Google……

注意，如果你编写你自己的代码来读文件，在下面提到的“下一代libpcap”格式里读取任何捕获的文件都将失败。然而，如果你使用libpcap，当链接（在构建或运行时）到一个可以读取这些文件的libpcap/WinPcap的版本时，程序能够读取“下一代libpcap”文件，这些文件不使用当前libpcap API不支持的特性（比如来自多个接口带有不同的链路层数据类型的包），也不使用读取当前libpcap格式。由此观之，如果可能你应该使用libpcap/WinPcap，而不是自己编写代码来读这些文件。

4 缺陷

libpcap格式是非常简单的，这是它得到如此广泛应用的一个原因。不幸的是，它漏掉了一些有用的事情：

纳秒时间分辨率

用户评论：“从1432包开始显示连接故障”

接口信息（比如网卡制造商）

丢包计数（以及其他可能的计数）

…….

5 未来

libpcap文件格式达到了它的目的，这一点获得了广泛接受，但是这个格式缺少有用的特性。有一个下一代pcap文件格式的提议，可以在http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html获取到。新格式提供了许多在上面“缺陷”一节中提及的能力。

在现在和相当长的一段时间里，这仍然只是一个提议。Wireshark目前至少有能力读取一些pcap-NG文件，虽然它并不支持读取所有文件的能力，libpcap1.1.0和后续版本也只有有限的读取能力。NTAR - Network TraceArchival and Retrieval库仍在开发中。完成开发后，它能读写这种格式的记录，但是不能解释他们（像Wireshark那样解释）；在将来，libpcap和Wireshark将使用这个库并解释里面的记录。

更多关于pcapng文件格式的细节参看WiresharkDevelopment/PcapNg。

6 讨论

更好的，将来可能使用单词“数据块”或“块”或其他词汇取代“包”。

https://www.dkcj.cn/info/10311.html

libpcap文件格式

1 综述

2 文件格式

2.1 全局头

2.2 Header记录（包）头

2.3 包数据

3 库

4 缺陷

5 未来

6 讨论

相关文章：