Custom Packet Parsing and Capture File in Wireshark/TCPDUMP”

Currently, all of my work involves designing some communication protocols, so I often need to observe the contents of packet transmission and reception. However, I have always used printk/printf methods to do this. I have also considered whether to make it more advanced and compatible with tcpdump/wireshark format, and then write a parser that looks cool. But the company’s cases come and go, many of which are one-time projects, so writing such things is not very cost-effective.

Recently, there is finally a case that has been going on for a long time to get, and the client will also need customization in the future, so I spent some time researching Wireshark parsing and capturing files, which will be more convenient to cooperate with customers.

Wireshark packet parsing

This article is based on this reference, but modified to suit your needs. It does not delve too deeply into the details, and focuses mainly on application. This article only uses some of the functions, if you have more complex requirements, you can refer to Wireshark’s documentation or search for “Wireshark dissector lua” on Google. The original reference article mentions bool field, which is also worth referring to.

Wireshark supports packet dissectors written in Lua scripting language. The following is my program.

In Wireshark, we use the built-in function “Proto()” to create an analysis object named “p_vxlan” to store other settings. The first parameter of Proto() is the filter name and the second parameter is the description.

“L4~L14”: Define field names and types in the protocol. The position is not specified here. After ProtoField.*, it follows the nature of the field, such as uint32, uint8. All lists can be referred to in the official document’s explanation of ProtoField at 11.3.7.2. For ProtoFile.*(), the first one is the sub-name of its filter, the second one is the description, and the third one is the display format (decimal, hexadecimal). L12,13 use masks at the end, indicating that they are bit fields. map1 and map2 take the upper and lower nibbles respectively.

“L16-L19: Define these fields in p_vxlan. They can be specified directly or by using the insert method. In actual use, not all of them need to be used, and their positions can also be specified separately.”

“L21~50”: Is the judgment function called when packets come in. The rest is declarations or registrations, which are longer and will be explained later.

Register this filter to perform filtering on UDP port 1234.

Field processing

The content above is preferring the type and processing target declaration, the next step is to process and judge the exact location. The so-called analysis is implemented on Wireshark by printing the fields. Therefore, what you see on Wireshark is an additional description field.。
The content above refers to parsing and determining the exact location. In Wireshark, parsing involves printing out fields. As a result, when using Wireshark, you will see an additional description field.

欄位

“L22: Generate a root node for this filter and all subsequent explanations will be attached under it.”

Get the length of the incoming buf to print out the undecoded content at the end.

“L24~32: Add fields defined in L4~L14. add_le() means to add the field in little endian format, followed by the specified data offset. L30 and L31 occupy the same position because they are both 4 bits. The last part of bytes is the remaining data fields listed as a list.”

“L34~37: This is to overwrite the display data of eth, but it is not needed here, so just comment it out.”

“L38~48: Display additional text next to the root node “t” based on the msgtype. If necessary, additional text can be displayed in a similar way next to each field.”

Generate PCAP capture file

The above explains how to parse and extract packets. How can we generate files that comply with the format? One way is to actually generate entities like the ones described above, and another way is to generate fake packets and write them into files for parsing. This article describes the pcap file format and refers to LibpcapFileFormat.

The content of PCAP can be divided into three parts, and the last two packet headers and contents will keep repeating.

• Global header
• Packet header
• Package content.

Global header

Please refer to the official WiKi page here. The format is the same as before and the initialization can be done with the following content.

The variable “magic_number” is responsible for both the functionality of a magic number and determining the endianness. If Wireshark detects that it is reversed, it means that the system captured and the system being parsed have opposite endianness. The remaining items should be filled in as shown in the table above, where network (1) refers to Ethernet, which currently does not seem to have many other practical options.

Packet header

The first two fields of the packet header are about the time of capture. The time of the first packet is 0, and the difference between consecutive packets needs to be calculated using gettimeofday() to get a time with usec included for more accurate representation.

The variable “incl_len” represents the actual length of the file contained in the packet, while “orig_len” represents the expected length of the packet. This distinction is made because sometimes we only want to capture the header and not the entire contents of the packet.

Package content

The packet content is just plain data and needs to be parsed by the parser.

Creating packet examples

The above code is an incomplete ARP packet generation program, but it is sufficient for Wireshark to parse its contents. Below is a more complete Linux program that can encapsulate at the UDP layer.

Conclusion

A topic that is useful but not very useful, depending on whether your need is long-lasting enough.

相關文章:

Wireshark / TCPDUMP 自訂封包解析與截取檔