1
votes

I have written a program that can make a named pipe and then write the packets to it, and later read from it using wireshark(making the named pipe as the interface -> wireshark -k -i tmp/myfifo). The following is the byte list which has been sent to the pipe.

D4 C3 B2 A104 0008 0000 00 00 0000 00 00 00FF FF 00 0001 00 00 00AA 77 9F 4790 A2 04 004d000000 4d00000000 00 00 00 00 0000 00 00 00 00 0008 004500003f00 0040 00 403A3c837f 00 00 017f 00 00 01A0 0100 0148 69 20 74 68 69 73 20 69 73 20 5061 72 76 61 74 68 69 20 66 72 6f 6d20 56 49 54 20 55 6e 69 76 65 72 7369 74 79

D4C3B2A1 0400 0800 00000000 00000000 FFFF0000 01000000 -Global header
AA779F47 90A20400 4d000000 4d000000 -packet header
00 00 00 00 00 0000 00 00 00 00 00 08 00 -ethernet header
4500 003f 00 00 40 00 40 3A3c837f 00 00 017f 00 00 01 -ip header
9B 01 00 01 -icmp header
48 69 20 74 68 69 73 20 69 73 20 5061 72 76 61 74 68 69 20 66 72 6f 6d20 56 49 54 20 55 6e 69 76 65 72 7369 74 79 -and finally the message

I have tried opening wireshark by sending its hex format as well as its ASCII string code to the interface(pipe). But in both the cases, once I open wireshark, it is prompting that it is "Unrecognized libpcap format". As per the libpcap format in the below links the bytes were framed

[1]Libpcap file format by Wireshark: https://wiki.wireshark.org/Development/LibpcapFileFormat [2]An example python code for generating pcap file: http://www.codeproject.com/Tips/612847/Generate-a-quick-and-easy-custom-pcap-file-using-P

What exactly should I send so that the wireshark can sniff?

1

1 Answers

2
votes

If we look at the man page for the pcap file format, we see that you need to send, as the byte sequence, with all multi-byte integer values being in the byte order of the machine writing out the byte stream:

  • a 4-byte magic number with a value of 0xA1B2C3D4 for microsecond time-stamp resolution or A1B23CD4 for nanosecond time-stamp resolution;
  • a 2-byte major version number with a value of 2;
  • a 2-byte minor version number with a value of 4;
  • a 4-byte time zone offset with a value of 0;
  • a 4-byte time stamp accuracy indicator with a value of 0;
  • a 4-byte snapshot length value - if you haven't explicitly cut off packets at an arbitrary fixed length, put a large value in here, such as 262144;
  • a 4-byte link-layer header type value, from the list of LINKTYPE_ values.

So, if your machine is little-endian - as any machine with an x86-compatible processor will be (i.e., 32-bit IA-32 or 64-bit x86-64, AMD or Intel or...), so if you're doing this on a PC or Intel-based Mac, your machine is little-endian - the byte sequence will, for a capture with microsecond-resolution time stamps, and with packets being Ethernet packets with each packet beginning with an Ethernet header, begin with:

D4 C3 B2 A1 (magic number)
00 02 (major version number)
00 04 (minor version number)
00 00 00 00 (time zone offset)
00 00 00 00 (time stamp accuracy)
00 04 00 00 (snapshot length = 262144)
00 00 00 01 (link-layer header type value, LINKTYPE_ETHERNET)

Then, after that, you'd write out, for each packet, a byte stream for a header containing, with all multi-byte integer values being in the byte order of the machine writing out the byte stream, a per-packet header with:

  • a 4-byte time stamp "seconds" value, representing the number of seconds since January 1, 1970, 00:00:00 UTC (a standard UN*X time stamp);
  • a 4-byte time stamp "microseconds" value, representing the number of microseconds since that second;
  • a 4-byte value giving the number of bytes of packet data, for that packet, in the stream;
  • a 4-byte value giving the number of bytes the packet had before it was arbitrarily cut off at the snapshot length - if it wasn't cut off, that will be the same as the number of bytes of packet data;

and then will contain the raw bytes of packet data, with no padding.