Wireshark-dev: Re: [Wireshark-dev] heuristic Dissector for Dummies

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Fri, 29 Aug 2008 20:42:40 +0200
Tom Stevens schrieb:
Hello!

Is there a simple tutorial on the web where i can find some information about how to write a heuristic dissector.

http://www.wireshark.org/docs/wsdg_html_chunked/ChapterDissection.html -> On this side i couldn't find anything about heuristic dissectors.

May you recommend a code snipet, where i can learn how to write a heuristic dissector by my own.

Where and how can i define the rules (pattern) that wireshark needs to find the corresponding dissector? To what points do I have to pay particular attention when i write such a dissector?


Ok, I'll try to give you some ideas about a heuristic dissector.


Why heuristic dissectors?
-------------------------
When Wireshark "receives" a packet, it has to find the right dissector to start decoding the packet data. Often this can be done by known conventions, e.g. the Ethernet type 0x800 means "IP on top of Ethernet" - an easy and reliable match for Wireshark.

Unfortunately, these conventions are not always available, or (accidentially or knowingly) some protocols don't care about those conventions and "reuse" existing "magic numbers / tokens".

For example TCP defines port 80 only for the use of HTTP traffic. But, this convention doesn't prevent anyone from using TCP port 80 for some different protocol, or on the other hand using HTTP on a port number different to 80.

To solve this problem, Wireshark introduced the so called heuristic dissector mechanism to try to deal with these problems.


How Wireshark uses heuristic dissectors?
----------------------------------------
While Wireshark starts, heuristic dissectors (HD) register themselves slightly different than "normal" dissectors, e.g. a HD can ask for any TCP packet, as it *may* contain interesting packet data for this dissector. In reality more than one HD will exist for e.g. TCP packet data.

So if Wireshark has to decode TCP packet data, it will first try to find a dissector registered directly for the TCP port used in that packet. If it finds such a registered dissector it will just hand over the packet data to it.

In case there is no such "normal" dissector, WS will hand over the packet data to the first matching HD. Now the HD will look into the data and decide if that data looks like the dissector "is interested in". The return value signals WS if the HD processed the data (so WS can stop working on that packet) or the heuristic didn't matched (so WS tries the next HD until one matches - or the data simply can't be processed).


How do these heuristics work?
-----------------------------
Difficult to give a general answer here. The usual heuristic works as follows:

A HD looks into the first few packet bytes and search for common patterns that are specific to the protocol in question. Most protocols starts with a specific header, so a specific pattern may look like (synthetic example):

1) first byte must be 0x42
2) second byte is a type field and only can contain values between 0x20 - 0x33 3) third byte is a flag field, where the lower 4 bits always contain the value 0 4) fourth and fifth bytes contains a 16 length field, where the value can't be longer than 10000 bytes


So the heuristic dissector will check incoming packet data for all of the 4 above conditions, and only if all of the four conditions are true there is a good chance that the packet really contains the expected protocol - and the dissector continues to decode the packet data. If one condition fails, it's very certainly not the protocol in question and the dissector returns to WS immediately "this is not my protocol" - maybe some other heuristic dissector is interested!


Obviously, this is *not* 100% bullet proof, but the best we can offer to our users here - and improving the heuristic is always possible if it turns out that it's not good enough to distinguish between two given protocols.


Regards, ULFL