Was ist der Unterschied zwischen einer PCAP-Datei mit einer magischen Zahl von "0x4d3cb2a1" und "0xd4c3b2a1"?

Question

Ich habe zwei PCAP-Dateien, A und B.

A hat eine ‚magische Zahl‘ in der Kopfzeile d4 c3 b2 a1, hat B eine ‚magische Zahl‘ in der Kopfzeile 4d 3c b2 a1. Laut der wireshark-Dokumentation (http://wiki.wireshark.org/Development/LibpcapFileFormat) sind nur 0xd4c3b2a1 und 0xa1b2c3d4 gültige magische Zahlen, was zu der Annahme führt, dass B keine gültige magische Zahl ist.

Lauf file auf Linux unterstützt diese nach oben, mit dem Ausgang des file A Seins:

tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535) 

file B einfach gibt:

data 

Es sieht so aus, dass, was auch immer B schrieb schrieb er in einem ‚ausgelagert '(Little-Endian) -Format, schrieb aber die ersten twp Bytes mit den Nibbles falsch herum. Vorausgesetzt, ich würde erwarten, dass ein Big-Endian-System das ganze int32 anders herum schreibt und nicht die einzelnen Bytes, sondern eine magische Zahl von 1a 2b 3c 4d.

Ist B eine gültige Datei? Wenn ja warum? Können verschiedene Systeme sowohl 32-Bit-Ints als auch die einzelnen Nibbles in einem Byte in beliebiger Reihenfolge schreiben?

Answer 1

Was ist der Unterschied zwischen einer PCAP-Datei mit einer magischen Zahl von "0x4d3cb2a1" und "0xd4c3b2a1"?

A pcap Datei mit einer Anzahl von magischen 0xa1b23c4d oder 0x4d3cb2a1 ist eine pcap Datei, in der die Paketzeitstempel in Sekunden und ns.

A pcap Datei mit einer Anzahl von magischer 0xa1b2c3d4 oder 0xd4c3b2a1 ist eine „normale“ pcap Datei, in der die Paketzeitstempel in Sekunden und Mikrosekunden.

Woher haben Sie Datei B? Die einzige Standardversion von libpcap, die Dateien im "Nanosekunden-Auflösungs" -Format schreibt, ist die Version auf dem Stamm des libpcap-Git-Baums, und das würde nur passieren, wenn das Programm libpcap ein anderes "Nanosekunden-Auflösungs" -Format liest oder explizit anfordert Zeitstempel in Nanosekundenauflösung vom Netzwerkadapter (wird derzeit nur unter Linux unterstützt und benötigt wahrscheinlich einen ausreichend neuen Kernel). Das ist auch die einzige Version, die sie lesen kann. Wireshark wird sie nicht standardmäßig erzeugen, obwohl neuere Versionen von Wireshark sie lesen können.