In diesem Dokument wird beschrieben, wie man ein PCAP File manuell reparieren kann bzw. wie man an solch ein Problem heran geht. Wer seine Datei nicht manuell raparieren möchte, kann auch das Werkzeug “pcapfix” verwenden.

1.    Fehlerhaftes PCAP öffnen und Fehlercode analysieren

In diesem Beispiel wird die Datei “file1.pcap” verwendet.

Bei diesem PCAP File wird das Format nicht erkannt, was auf ersten Anblick einen fehlerhaften File Header vermuten lässt.

2.    Eigenes PCAP erstellen und mit dem fehlerhaften vergleichen

Man erzeugt als erstes ein eigenes, neues PCAP File “file2.pcap”, z.B. mit tcpdump.
Als nächstes springt man an den Anfang der Datei und untersucht das erste Paket.

Der Anfang ist hier HEX: FF FF FF FF FF FF 00 30 05 7C D2 4A 08 06
Dabei handelt es sich um die MAC Adressen im Ethernet Header.
Davor würden sich noch 16 Bytes für den Packet Header ergeben, welche man in Wireshark nicht angezeigt bekommt. Jedoch sollte man diese im Hinterkopf behalten!!!
Als nächstes vergleicht bzw. sucht man diese HEX Werte im file2.pcap im Hex Editor. Diese Werte findet man relativ am Anfang des Files wieder.
Lediglich 40 Bytes sind noch voran gestellt. Dabei bestimmen 16 Bytes den Packet Header des ersten Paketes und 24 Bytes umfassen den Global Header des Files.

Global Header:    D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 FF FF 00 00
                            01 00 00 00 E9 80 4C 4F F7 34 03 00 2A 00 00 00 2A 00 00 00

Den kompletten Schritt wiederholt man nun mit dem fehlerhaften File  “file1.pcap “.

Die vielen FF deuten wohl auf die MAC Adressen des ersten Paketes. Die vorangestellten 16 Bytes bestimmen somit den Packet Header und der Globale Header fehlt komplett.

3.    Global Header im fehlerhaften PCAP File einfügen

Um den Global Header zu reparieren, fügen wir nun einfach die 24 Bytes des Header aus unserem funktionstüchtigen PCAP File in die beschädigte Datei ein. Dabei nehmen wir hier in Kauf, dass Angaben wie zum Beispiel die maximale Paketlänge aus unserem kopierten Global Header mit übernommen werden.

Wenn man diesen Schritt getan hat, speichert man das File als “file3.pcap” ab.
Bingo, nun wird das file3.pcap von Wireshark erkannt und kann geöffnet werden.
Was geschieht jedoch wenn dabei noch weitere Fehlermeldungen auftauchen?

4.    Weitere Fehlermeldungen analysieren

Bei diesem Fehler ist erkenntlich, dass Wireshark ein bestimmtes Paket nicht erkannt hat, da es größer ist als die zulässigen 65535 Bytes. Demzufolge öffnet Wireshark zwar das PCAP File, jedoch nicht vollständig, da bei dem korrupten Paket gestoppt wird.
Dieses Paket muss man nun untersuchen.

5.    Fehlerhaftes Paket suchen

Dazu springt man an das letzte Paket in Wireshark.

Die letzten 8 Bytes (02 04 05 B4 01 01 CA BC) merkt man sich und sucht diese im file3.pcap im Hex-Editor.

Direkt nach dem letzten erkannten Paket (SYN/ACK) beginnt der nächste Header.
Bei: 3E 3C 60 50 …..

6.    Fehlerhaftes Paket reparieren

In diesem Beispiel handelt es sich bei dem fehlerhaften Paket um ein HTTP Paket, erkenntlich an einem GET Request. Nun hat man mehrere Möglichkeiten wie man mit diesem fehlerhaften Paket umgeht.

6.1.    Paket löschen

Dazu guckt man sich einfach an auf welchen HTTP Header der Request endet.

=> Accept-Charset: windows-949,utf-8;q=0.7,*;q=0.3\r\n\r\n

41 63 63 65 70 74 2D 43 68 61 72 73 65 74 3A 20 77 69 6E 64 6F 77 73 2D 39 34
39 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A 3B 71 3D 30 2E 33 0D 0A 0D 0A

Somit hat man den Anfang und das Ende des Pakets welches man daraufhin einfach löschen kann.

6.2.    Paket in vorhergehendes hinein schieben

Dazu wird die Paket-Länge des letzten funktionierenden Pakets SYN/ACK geändert und somit der Inhalt des GET-Request in das SYN/ACK mit hinein geschoben. Hierzu muss man die Länge des GET Pakets (0x01E7 = 487) zur Länge des SYN/ACK (0x3E = 62) hinzuzählen und an der Position D24-D28 bzw. D29-D0B die Packet Length bzw. Capture Length (des Packet Headers) ersetzen.

Streiche:    0x3E        (62)                     =   original Länge des SYN/ACK
Setze:        0x0225    (549 = 62+487)   =   Länge SYN/ACK + GET Request

Das ganze wird in Network Byte Order angegeben, also so:

6.3.    Packet Header des Paketes vortäuschen

In der dritten Möglichkeit wird der Header des GET Request einfach nachgebaut und hinter das letzte vollwertige Paket (SYN/ACK) eingefügt. Wie zuvor bereits erwähnt besteht der Packet Header aus 16 Bytes (Angaben jeweils in Network Byte Order):

4 Bytes für den Timestamp in sec     F4 8D 3B 4F
4 Bytes für den Timestamp in nsec   1C 9E 00 00
4 Bytes für die Capture Length           3E 00 00 00
4 Bytes für die Original Length           3E 00 00 00

In diesem Beispiel wird einfach der Packet Header des SYN/ACK kopiert und lediglich die Packet Length bzw. Capture Length zum GET Paket angepasst.
Dann hat das GET Paket zwar denselben Timestamp, aber das tut nichts zur Sache.

In Schritt 6.2. wurde bereits die Länge des GET Pakets erwähnt (0x01E7 = 487).
Sodass man folgenden Packet Header erhält:

F4 8D 3B 4F 1C 9E 00 00 E7 01 00 00 E7 01 00 00

7.    Vollständiges PCAP File neu abspeichern

Mit einer der drei zuvor beschriebenen Möglichkeiten kann man nun ein “file4.pcap” abspeichern und danach in Wireshark einlesen. Dieses File ist nun voll funktionstüchtig und kann reibungslos in Wireshark analysiert werden.