Export the trace in hex format
- Capture your trace.
- Select the line(s) of interest
- File -> Export Packet Dissections -> As Plain Text
- On the next screen
- Select the directory and file name
- Select the Export as “Plain text” – it adds .txt to the file name you chose above, if required.
- Select the packet range
- Packet format: Bytes (and only bytes)
If you select Packet Format : Bytes you get output like
0000 00 d8 61 e9 31 2a 8c 16 45 36 f4 8a 08 00 45 10 ..a.1*..E6....E. 0010 00 78 39 c5 40 00 40 06 ec a4 0a 01 00 02 0a 01 .x9.@.@......... 0020 00 03 bc 3e 00 16 0d 5b 33 ab 44 ae 0b 8f 80 18 ...>...[3.D.....
If you select Packet Format: Details
No. Time Source Destination Dst port port Protocol Length Info 1 0.000000000 10.1.0.2 10.1.0.3 22 48190 SSH 134 Client: Encrypted packet (len=68) Frame 1: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface enp0s31f6, id 0 Ethernet II, Src: LCFCHeFe_36:f4:8a (8c:16:45:36:f4:8a), Dst: Micro-St_e9:31:2a (00:d8:61:e9:31:2a) Internet Protocol Version 4, Src: 10.1.0.2, Dst: 10.1.0.3 Transmission Control Protocol, Src Port: 48190, Dst Port: 22, Seq: 1, Ack: 1, Len: 68 SSH Protocol
If you specify If you select Packet Format: Details + Bytes you get both sets of output in the file.
If you try to import this files back into Wire Shark, it should work, as it will ignore lines which do not begin with a hexadecimal offset.
Import a hex dump file
Using the “bytes” file created above
- File -> Import from Hex Dump
- File /u/colin/aaa.txt
- Offsets: Hexadecimal
- Encapsulation type: Ethernet
The data is displayed as if it was real time capture.
The Wireshark documentation on importing data is here.
Information in the imported file.
Various bits of information are not in the hex dump file, and WireShark creates (fakes) them. For example
- The packet number is the data record number of the data in the file.
- The time between packets is an incrementing microsecond counter, 0.000000, 0.000001, 0.000002 etc
- The packet length is taken from the length of the data record.
- The “arrival time” is the time the data was read from the file.
- The encapsulation type is taken from the import page.
- However information such as source, destination, port, destination port are taken from the data.
Bodging a hex dump file
I had a AT-TLS trace from PAGENT which was a string of raw hex data, with no interpretation of the TLS data. AT-TLS does not provide any way of formatting this data.
I was partially successful in using WireShark to process this data, and decode the TLS fields.
The first part of the data is the IP and TCP header info, followed by the TLS data.
I obtained a hex dump of a TLS handshake and took the first x42 bytes.
0000 8c 16 45 36 f4 8a 00 d8 61 e9 31 2a 08 00 45 00 0010 xx xx 01 3d 00 00 3f 06 5c ef 0a 01 01 02 0a 01 0020 00 02 05 86 b8 dc 34 b1 03 17 57 c4 a5 0c 80 18 0030 0f fc 1d bf 00 00 01 01 08 0a 9d cf 5c b7 db 69 0040 e9 0d
I then wrote an ISPF editor rexx program to take the TLS trace and convert into the similar format, such as
0042 16 03 03 08 8E 02 00 00 4D 03 03 62 A8 75 18 C9 0052 5D 61 E1 1B 71 40 6A 6B 95 A8 F9 E5 E8 3A 83 AB .... 07E2 F0 61 98 51 92 4B 2E 0A 29
Then changed the xx xx to the length of the data – 12. So xx xx becomes (x7ea – 12) = x07dd.
The data could sometimes be imported.
If anyone is interested I can send them the ISPF rexx exec.
The trace from PAGENT is some times incomplete or wrong. I had long records with
0A29C..TRC at the end, which is clearly not hex data.
Hints on bodging.
It took me several hours to get the first successful import of TLS data. Some of the problems I had were
- The offsets were wrong. I sometimes had the wrong offset, or the same offset more than once
- The xx xx needs to be correct.
- In the PAGENT trace file I had data like 160303007B which is of length 10 – but only length 5 hex characters. The length would be 00 47 ( 00 42 + 5)