Nicely put Ulf! This information is certainly a candidate for addition to the Wireshark Wiki.
Regards, Peter 2008/8/29 Ulf Lamping <[EMAIL PROTECTED]> > 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 > [email protected] > https://wireshark.org/mailman/listinfo/wireshark-dev >
_______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
