Note that there are some explanatory texts on larger screens.

plurals
  1. POLooking For A Packet Description Language (Preferably With A C# Implementation)
    primarykey
    data
    text
    <p>I am in the process of developing a special-purpose network tool with some packet sniffing and decoding capabilities. I am looking for languages designed to assist in the dissection/decoding of arbitrary packet formats. Idealy, the solution should be based on open standards. There are related questions on SO, but most deal with the full lifecycle of packet sniffing (I don't care so much about the capture, there are other libraries that do that well).</p> <p>In general, what I'm looking for is a language and supporting framework for the declaritive definition of packet formats and corresponding run-time decoding. Because this problem can be generalized to any non-network binary data, a solution that does this for arbitrary binary streams would also be in scope. I am a little surprised no such standard currently exists in a mature and robust state (at least that I could find) - though there seem to be a lot of interesting but not-quite-right and almost-there projects (see below). Perhaps that speaks to the difficulty of the problem, or maybe to a lack of demand.</p> <p>By way of example, I'm interested in technologies and ideas similar to the following (in no particular order):</p> <ul> <li><a href="http://sourceforge.net/apps/mediawiki/packetnet/index.php?title=Main_Page" rel="noreferrer">Packet.Net</a> - Does the job of converting from binary packet representations to structures, but the dissectors are all hard-coded and it doesn't appear to be able to handle more complex formats.</li> <li><a href="http://forge.gridforum.org/projects/dfdl-wg" rel="noreferrer">DFDL</a> - I've been following this one for a while and was even participating in teleconferences a year or so ago. The standard seems to be reaching maturity, but implementation appears to be challenging. Not that I mind getting my hands dirty, but I'm not sure I've got the resources on this project to implement such a wide-ranging standard from scratch for this purpose. </li> <li><a href="http://nmparsers.codeplex.com/" rel="noreferrer">Network Monitor Open Source Parsers</a> - This project describes packets using a C-like syntax for use by Microsoft Network Monitor. It has a lot of packets already defined and the language appears robust enough to support complex structures. Unfortunately, the only implemention of an execution engine is in NetMon and while the grammar for the language could probably be reverse-engineered, implementing a processing engine might be very difficult. I also worry that because of the explicit tie between the parser language and the NetMon tool there are non-general aspects to the language that would make it inappropriate for uses in other tools.</li> <li><a href="http://www.nbee.org/doku.php?id=netpdl:index" rel="noreferrer">NetPDL</a> - This one looks very interesting, but development seems to have languished. It's also not totally clear how to make use of the execution engine outside of their own environment.</li> <li>Wireshark Dissectors - I've thought about wrapping/using native Wireshark Dissectors for this purpose, but they are tied pretty closely to Wireshark itself. The dissectors also use code to perform most of the decoding, which is a little counter to what I'm looking for - I'd prefer something that's a little more declaritive (though obviously there's a balance since complex packet structures often require switching and other logic to determine the final makeup).</li> <li><a href="http://www2002.org/CDROM/alternate/334/" rel="noreferrer">BSDL</a> - An academic language similar in concept to DFDL (see above). Interesting and in the right direction, but outside of a couple papers nothing else seems to exist.</li> </ul> <p>I'm not necessarily looking for a complete solution here (though if someone knows of one I haven't covered, that would be great). I'm more interested in comments or anecdotes about the technologies I've indicated above as well as pointers or ideas for routes I haven't thought of or covered.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload