[Ulf Lamping <ulf.lamping@xxxxxx>]

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