For some reason, compiling dissector plug-ins with Visual Studio prevents their use in the mainstream release of Wireshark. If you are using a different compiler, you may not have to use the compiled version of Wireshark.
His code uses a very simple protocol to transmit data via TCP. The file transfer messages are a tad more complex, so we will ignore those for now. All of Amin's packets are prefixed with a four 4 byte long value which indicates the size of the package. This value is presented in network order over the wire, or, MSB.
Network order means that the bytes are ordered in such a way that the most significant bytes are first. For example, let's say your length is 12 decimal. This would be 0xc in hex if you are storing the value in a long. If you read this value off the "wire", it would appear as 0c 00 00 00; this is "Network" order. You may be wondering why the bytes are reversed. If you think about it as an array of bytes, instead of a long, each byte is written in order.
In this case, byte[0] is 0x0c, so it's written first. This is an important concept to understand. When we use Wireshark to dissect the packet, it is important to understand that 2 and 4 byte integer values are always written in "Network" order, or LSB. In other protocols, the order may be Host — which would be LSB. Note: The length accounts for the bytes to follow, meaning that the four 4 bytes which represent the length value are not included. Amin follows the length prefix with a byte that indicates the "type" of the packet he is delivering.
We will only be dealing with type 0x00, which is text. Note: a single byte is not subject to byte order because it's a single byte. Note: This article does not discuss the basic use of Wireshark. This article assumes you have used it before and understand how to use it in a basic sense. Notice that we are simply given a field called "Data". Within the data portion, we can recognize our AMIN protocol based on the "1f 00 00 00 00" package length. The type follows, and after that is the "ABC..
The Wireshark source tree contains a directory called Plugins , which provides a reasonable amount of examples. However, it was impossible to find a really "simple" example to use. So, in combination with the H dissector, random examples from the internet, and the developer guide, I have prepared a simple example and placed it in the source zip file. In order to compile your own protocol, you must create a set of files to compile your dissector. You can use a text editor of your choice to open packet-yourprotocol.
Let's take it line by line:. All dissectors use some standard headers. You need the config. This is a forward declaration of our dissection function. As you can see, a field foo. As mentioned earlier, the foo protocol begins with an 8-bit packet type which can have three possible values: 1 - initialisation, 2 - terminate, 3 - data. This remembers if the node should be expanded or not as you move between packets. All subsequent dissection will be added to this tree, as you can see from the next call.
The pdu type is one byte of data, starting at 0. For a 1-byte quantity, there is no order issue, but it is good practice to make this the same as any multibyte fields that may be present, and as we will see in the next section, this particular protocol uses network order.
We need to add a few more variables to the hfarray, and a couple more procedure calls. This dissects all the bits of this simple hypothetical protocol. With these extra bits in place, the whole protocol is now dissected. We can certainly improve the display of the protocol with a bit of extra data.
The first step is to add some text labels. There is some useful support for this sort of thing by adding a couple of extra things. First we add a simple table of type to name. This is a handy data structure that can be used to look up a name for a value. We just have to give these details to the appropriate part of the data, using the VALS macro. This helps in deciphering the packets, and we can do a similar thing for the flags structure.
For this we need to add some more data to the table though. Some things to note here. Second, we include the flag mask in the 7th field of the data, which allows the system to mask the relevant bit. Then finally we add the extra constructs to the dissection routine. We can add them just like the we did with the message length field.
The final script for this part will therefore look like this:. We have to increase the offset by 4 in the call to the range function buffer offset,length in order to read 4 new bytes for every field. If we were dealing with something else than int32s we would of course have to increase by something else.
Right now, we only see the numeric values of the opcodes, but the opcode name would be more interesting. The downside of using Lua is that the dissector will be slower than a dissector written in C. Lua crash course Lua is multi-paradigm, and supports procedural style, functional programming to some degree, and it also has some object-oriented programming features.
Scope is either local or global. Semicolons are not needed. Whitespace is not important like in Python. Lines that start with -- are comments. Its types are: string, number, boolean, nil, function, userdata, thread and table. Number represents all numbers, both floating points and integers. Booleans are either true or false. Strings are either single-quote or double-quote. You can forget about thread and userdata. In conditionals: nil and false are falsy, the rest are thruthy. Lua has a type called table , which is also the only data structure it has.
Tables implements associative arrays. Associative arrays can be indexed by both numbers and other types, such as strings.
They have no fixed size and elements can be added dynamically.
0コメント