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

["Peter Johansson" <peterjohansson73@xxxxxxxxx>]

Nicely put Ulf! This information is certainly a candidate for addition to the Wireshark Wiki.

 

Regards, Peter

2008/8/29 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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev