Problem with importing a frame from hex dump…

Question

Hi guys,

I have a problem with importing a frame from hex dump. When I was trying to import a frame I followed this guide: https://www.wireshark.org/docs/wsug_html_chunked/ChIOImportSection.html But still it didn't work. I believe that solution is pretty simple and I am just stupid.

So I would like to import this frame: 00 04 76 a4 e4 8c 00 00 c0 d7 80 c2 08 00 45 00 01 b0 08 9f 40 00 80 06 2d 69 93 af 62 ee 45 38 87 6a 04 54 00 50 77 4d 60 d0 39 8e 41 a8 50 18 44 70 64 56 00 00 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 65 70 74 3a 20 69 6d 61 67 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65

I am aware that I have to put in every line of the frame so called offset. This are the numbers which you can see in the article on which I posted a link above. I think that is the problem why wireshark wont accept my frame.

So could you please tell how the offset should looks like for a frame like that ? I would also be very glad for a little guide which would told me how to apply the offsets on every frame, so I would be able to import other frames to the wireshark on my own.

Thanks

Answer 1

0

Paste the byte string as a single line of text into a text file, and put 0 (a zero and a space) in front of the text, so it will look like

0 00 04 76 a4 e4 8c ...

and save the file. The 0 is the offset you are looking for.

Then open the File -> Import from Hex Dump form, make sure that the field for date format is empty and make sure that the Direction indication field is not checked (if you use 1.x wireshark then also that the Date/time checkbox is not checked). Then use the Browse button to choose the file you've saved, and then press the Import button.

As your hex dump is of an Ethernet frame, you don't need to change the default choice of encapsulation.

Come back if it does not work.

answered 24 Jul '16, 11:44

sindy
6.0k●4●8●51
accept rate: 24%

thanks for you reply.

But if I may ask you, when I will analyze frames different then Ethernet II such as 802.3 what about encapsulation ?

thanks :-)

(24 Jul '16, 12:57) snakehead28

The pcap file must contain information about encapsulation type so that Wireshark would know which dissector to use for each frame as the first one. So if importing a hex dump, you must provide this information manually: in the GUI, there is a drop-down menu for that, if you use the command-line utility text2pcap, you have to use a -l n command line parameter where n is a number representing the encapsulation type. The list of supported encapsulation types is here. Of course the encapsulation type specified must match the actual contents of the packets.

If none of the available encapsulation types matches the one you need, you may use a custom encapsulation type, for which you'll have to specify the dissector through configuration, or you may prefix the packet data with a manually created bytes representing a protocol for which encapsulation exists (such as Ethernet). These may be the same for all packets or you may e.g. want to express transmission direction of the hex-dumped packets by swapping the sender and recipient address in your handcrafted headers.

As for Ethernet II and 802.3 in particular, these two can even peacefully coexist on the same wire, which means that they have to be easily discriminated from one another. In particular, if the binary value of the first two bytes following the two MAC addresses is higher than 1536 (0x600), these whole frame is an Ethernet II one (where these two bytes contain an "ethertype", otherwise as an 802.3 frame (where these two bytes contain the length of the frame). So the pcap (and pcapng) file format uses the same encapsulation type for both and it is up to the application processing the file (Wireshark's "ethernet" dissector in our case) to tell apples from pears.

(25 Jul '16, 00:15) sindy

Answer 2

0

The offset, is the count of bytes since the start of the file. As you can see from the example in your link, that has 8 bytes per line so the offset is incremented by 8 on each line.

Converting your sample data to this format gives:

0000 00 04 76 a4 e4 8c 00 00
0008 c0 d7 80 c2 08 00 45 00
0010 01 b0 08 9f 40 00 80 06
0018 2d 69 93 af 62 ee 45 38
0020 87 6a 04 54 00 50 77 4d
0028 60 d0 39 8e 41 a8 50 18
0030 44 70 64 56 00 00 47 45
0038 54 20 2f 20 48 54 54 50
0040 2f 31 2e 31 0d 0a 41 63
0048 63 65 70 74 3a 20 69 6d
0050 61 67 65 2f 67 69 66 2c
0058 20 69 6d 61 67 65 2f 78
0060 2d 78 62 69 74 6d 61 70
0068 2c 20 69 6d 61 67 65 2f
0070 6a 70 65 67 2c 20 69 6d
0078 61 67 65 2f 70 6a 70 65

And converting it to a pcap after saving it to a text file using text2pcap inputfile.txt output.pcap shows the packet is malformed, missing some data.

Note that you aren't limited to 8 bytes per line, you can use whatever size you like, I was just keeping it the same as the example.

answered 24 Jul '16, 11:53

grahamb ♦
19.8k●3●30●206
accept rate: 22%

@grahamb, I would dare to slightly correct you - the offset is not from the beginning of the file but of each packet. And I think there is a bug in the import from hex dump - the last byte of (at least) the last packet is not imported. I even think I have filed that bug some months ago.

(24 Jul '16, 12:04) sindy

thank you, guys very much. You really helped me :-)

I would like to ask you another question. It's really stupid but I do not know how to convert .txt to .pcap. You said that I should use "text2pcap inputfile.txt output.pcap", but I do not know if you meant some online tool for converting files or something else. I tried to search for in on the web bud I did not found specific answer. So I don't know how can I do that, perhaps from within a wire shark ?

I would be grateful if you tell me also this.

And sorry for the noobish question :/

btw, I have the frame now in the very exact format you posted above in the .txt file.

Thanks

(24 Jul '16, 12:48) snakehead28

EDIT: I would like to add that I did it as grahamb told me. About converting a .txt to .pcap I just changed the file extension from .txt to .pcap and I think it worked.

Than I imported it in the wireshark ad frame lenght was only 127 insted of 128. One last byte was missing (but it was written in the orixinal .txt/pcap). It may be the bug that "sindy" mentioned.

Do you, guys, have any idea what to do about it ?

thanks :-)

(24 Jul '16, 12:57) snakehead28

@sindy, your observation about the offset being per packet is correct, any offset of 0 indicates a new packet. I think the docs needs an update here as they do state it's per file.

@snakehead28,

text2pcap was the original Wireshark utility for converting hex dumps to capture files, I have a long memory. text2pcap would be used from the command line and is usually installed alongside Wireshark.

Wireshark at some point also learnt this behaviour possibly in 2.x, as described in the answer from @sindy.

(24 Jul '16, 13:01) grahamb ♦

@snakehead, to get that last byte, I simply added an extra byte to the text file, e.g.

0080 00

(24 Jul '16, 14:30) grahamb ♦

@snakehead, two options:

after the hexdump of your last (or only) frame, put one more line like this:
0 00
This will add one more frame (of zero size thanks to the bug so not actually imported), making the actual last frame not the last one in the file, so if you then copy-paste more frames into the file, you will not have to think about which one of them was the last one before and thus which one needs to be modified
simply place 00 to the end of the last frame. This is easier if you import a single one but may cause confusion if you edit the same file multiple times, adding frames to be imported.

BTW, as @grahamb has stated somewhere above, much more than a single byte is missing in you hex dump - the IP header says the total size of the IP portion of the frame is 432 bytes whereas the hex dump only contains the first 114 bytes of them.

(25 Jul '16, 00:28) sindy

@grahamb, you are right that the offset is described in quite a confusing way at the text2pcap man page:

first, there is an unambiguous statement "Each line begins with an offset describing the position in the file" (so any diagonal reading stops right here)
further in the text, there is another statement, "An offset of zero is indicative of starting a new packet, so a single text file with a series of hexdumps can be converted into a packet capture with multiple packets".

So if you have the power and will, please fix the first statement.

(03 Aug '16, 04:25) sindy

@sindy, I think the first statement should be changed to:

Each line begins with an offset describing the position in the packet, each new packet starts with an offset of 0 and there is a space separating the offset from the following bytes.

(03 Aug '16, 05:19) grahamb ♦

Change 16856 submitted and merged.

(03 Aug '16, 05:51) grahamb ♦

If I may,

Each line begins with an offset describing the position of its first data byte in the packet, followed by a space separating it from the data bytes.

This already implicitly says that the offsets are valid within a single packet, and an explicit confirmation follows in the next paragraphs. But you are the native speaker, so feel free to make it sound more English ;-)

It would be also nice if you could express somehow that the last byte of the last line must be followed by at least a <lf> character because <eof> is not enough to make text2pcap interpret the last two hex characters before the <eof> as a data byte (which @Pascal Quantin considers a feature as per his comment to Bug 12674).

(03 Aug '16, 05:54) sindy

I tried to pack the relevant info into the first paragraph as no one reads the ones after the diagram!

I'll add another change for the trailing character, on Windows it seems a space or a line-ending (\r\n) will suffice.

(03 Aug '16, 07:27) grahamb ♦

showing 5 of 11 show 6 more comments