在Mac上创建的字节序列0a 0d 0d 0a奇怪的pcap标头？ [英] Weird pcap header of byte sequence 0a 0d 0d 0a created on Mac?
问题描述
我有一个PCAP文件，该文件是在Mac上使用 mergecap 创建的，可以在具有Apple的libpcap的Mac上进行解析，但不能在Linux系统上进行解析。组合文件有一个额外的16字节标头，在 4d 3c 2b 1a 0a 0d 0d 0a 78 00 00 00 >介绍在pcap文件中很常见。这是一个十六进制转储：
I have a PCAP file that was created on a Mac with mergecap that can be parsed on a Mac with Apple's libpcap but cannot be parsed on a Linux system. combined file has an extra 16-byte header that contains 0a 0d 0d 0a 78 00 00 00 before the 4d 3c 2b 1a intro that's common in pcap files. Here is a hex dump:
0000000: 0a0d 0d0a 7800 0000 4d3c 2b1a 0100 0000 ....x...M<+.....
0000010: ffff ffff ffff ffff 0100 4700 4669 6c65 ..........G.File
0000020: 2063 7265 6174 6564 2062 7920 6d65 7267 created by merg
0000030: 696e 673a 200a 4669 6c65 313a 2037 2e70 ing: .File1: 7.p
0000040: 6361 7020 0a46 696c 6532 3a20 362e 7063 cap .File2: 6.pc
0000050: 6170 200a 4669 6c65 333a 2034 2e70 6361 ap .File3: 4.pca
0000060: 7020 0a00 0400 0800 6d65 7267 6563 6170 p ......mergecap
有人知道这是什么吗？或如何使用libpcap在Linux系统上读取它？
Does anybody know what this is? or how I can read it on a Linux system with libpcap?
推荐答案
我有一个PCAP文件
I have a PCAP file
不，您没有。您有一个 pcap-ng文件。
No, you don't. You have a pcap-ng file.
可以在带有Apple的libpcap的Mac上进行解析
that can be parsed on a Mac with Apple's libpcap
libpcap 1.1 .0及更高版本也可以读取某些pcap-ng文件（pcap API仅允许文件具有一种链接层头类型，一种快照长度和一种字节顺序，因此仅所有部分具有相同部分的pcap-ng文件字节顺序，并且所有接口都具有相同的链路层标头类型和快照长度），并且OS X Snow Leopard和更高版本具有基于1.1.x的libpcap，因此它们可以读取这些文件。
libpcap 1.1.0 and later can also read some pcap-ng files (the pcap API only allows a file to have one link-layer header type, one snapshot length, and one byte order, so only pcap-ng files where all sections have the same byte order and all interfaces have the same link-layer header type and snapshot length are supported), and OS X Snow Leopard and later have a libpcap based on 1.1.x, so they can read those files.
（OS X Mountain Lion和更高版本对libpcap进行了调整，使其也可以写入 pcap-ng文件； -P 标志使tcpdump写出pcap-ng文件，在一些传出数据包上附加文本注释，指示发送它们的进程的进程ID和进程名称-pcap-ng允许文本注释
(OS X Mountain Lion and later have tweaked libpcap to allow it to write pcap-ng files as well; the -P flag makes tcpdump write out pcap-ng files, with text comments attached to some outgoing packets indicating the process ID and process name of the process that sent them - pcap-ng allows text comments to be attached to packets.)
但不能在Linux系统上解析
but cannot be parsed on a Linux system
您的Linux系统可能具有较旧的libpcap版本。 （注意：请不要把Deem和Debian派生类的libemcap软件包称为 libpcap0.8来混淆它们-他们还没有使用libpcap 0.8。）
Your Linux system probably has an older libpcap version. (Note: do not be confused by Debian and Debian derivatives calling the libpcap package "libpcap0.8" - they're not still using libpcap 0.8.)
组合文件有一个额外的16字节的标头，包含0a 0d 0d 0a 78 00 00 00
combined file has an extra 16-byte header that contains 0a 0d 0d 0a 78 00 00 00
pcap-ng文件是一系列块，以4字节的块类型和4字节的长度开头，均以写入它们的主机的字节顺序开头。
A pcap-ng file is a sequence of "blocks" that start with a 4-byte block type and a 4-byte length, both in the byte order of the host that wrote them.
它们分为小节，每个小节均以 部分标题块（SHB）； SHB的块类型为0x0a0d0d0a，它与字节顺序无关（因此您不必知道字节顺序即可读取SHB），并且包含回车符和换行符（因此，如果文件为例如，通过一个工具在UN * X系统和Windows系统之间进行传输，该工具认为它正在传输文本文件，并且有帮助地尝试修复行尾，因此SHB幻数将被损坏，并且很明显该文件是通过以这种方式转移而损坏；将其视为休克指示器）。
They're divided into "sections", each one beginning with a "Section Header Block" (SHB); the block type for the SHB is 0x0a0d0d0a, which is byte-order-independent (so that you don't have to know the byte order to read the SHB) and contains carriage returns and line feeds (so that if the file is, for example, transferred between a UN*X system and a Windows system by a tool that thinks it's transferring a text file and that "helpfully" tries to fix line endings, the SHB magic number will be damaged and it will be obvious that the file was corrupted by being transferred in that fashion; think of it as the equivalent of a shock indicator).
0x78000000是长度；紧随其后的是字节顺序魔术字段，它是0x1A2B3C4D（与pcap文件的0xA1B2C3D4魔术数字不相同相同），其作用与pcap魔术数字相同，即：
The 0x78000000 is the length; what follows it is the "byte-order magic" field, which is 0x1A2B3C4D (which is not the same as the 0xA1B2C3D4 magic number for pcap files), and which serves the same purposes as the pcap magic number, namely:
- 它可以让代码识别该文件是pcap-ng文件
- it让代码确定节的字节顺序。
（不，在查找pcap之前不需要知道长度幻数；找到幻数后，请检查其长度以确保其长度至少为28，如果小于或等于28，则将其视为无效。）
(No, you don't need to know the length before looking for the pcap magic number; once you've found the magic number, you then check the length to make sure it's at least 28 and, if it's less than or equal to 28, you reject the block as not being valid.)
有人知道这是什么吗？
Does anybody know what this is?
A -endian）pcap-ng文件。
A (little-endian) pcap-ng file.
或如何在具有libpcap的Linux系统上读取它？
or how I can read it on a Linux system with libpcap?
在带有较新版本的libpcap的Linux系统上阅读它（可能意味着您正在使用的发行版的较新版本，或者如果您将得到1.1.0或更高版本的libpcap，则可能仅意味着进行更新），请使用Wireshark或TShark（具有自己的库来读取捕获文件）进行读取，它支持本机pcap和pcap-ng格式以及许多其他格式），或从 tcpdump.org ，进行构建，安装，然后构建使用该版本的libpcap而非系统随附的pcap-ng文件读取pcap-ng文件所需的任何其他工具。
Either read it on a Linux system with a newer version of libpcap (which may mean a newer version of whatever distribution you're using, or may just mean doing an update if that will get you a 1.1.0 or later version of libpcap), read it with Wireshark or TShark (which have their own library for reading capture files, which supports the native pcap and pcap-ng formats, as well as a lot of other formats), or download a newer version of libpcap from tcpdump.org, build it, install it, and then build whatever other tools need to read pcap-ng files with that version of libpcap rather than the one that comes with the system.
较新版本的Wireshark默认情况下会写入pcap-ng文件，包括在诸如mergecap之类的工具中；您可以让他们编写带有 -F pcap 标记参数的pcap文件。
Newer versions of Wireshark write pcap-ng files by default, including in tools such as mergecap; you can get them to write pcap files with a flag argument of -F pcap.
这篇关于在Mac上创建的字节序列0a 0d 0d 0a奇怪的pcap标头？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
