Wireshark as 010 Editor Alternative?

Why couldn't Wireshark's packet dissection capabilities be used as an open-source alternative to 010 Editor's binary template feature?

Pros:

• free, open source
• C > 010's BT language
• python support?

Cons:

• much harder to write
• no editor, just viewer
• extra preparation step
• bugs

To prepare a file for Wireshark's consumption, we must make it look like a PCAP capture file. Luckily the PCAP format is not too complicated. Data link type is chosen as DLT_USER0 which is supposedly reserved for private use. The rest of the details are implemented in this tool:

pcap-wrap.c - wrap files in pcap capture format

The easiest way to setup an environment for building plugins is to download the Wireshark source (version 1.4.4 used here) and build it. It works very well being built in its source directory. Autogen, configure with --with-ssl, and make. In the root of the source tree will be the Wireshark executable and config.h which you will include in your plugin source to define preprocessor variables which are read in the other Wireshark includes. Plugins are just shared objects that are read (among other places) from ~/.wireshark/plugins/.

Writing plugins is a real pain at first. See docs/README.developer. Each subtree must be described before its used. Each field, too, must be described in excruciating detail via an hf_register_info struct. I think the whole mess is justified by this line from the docs: "By strictly defining (or "typing") the data that can be attached to a proto tree, searching and filtering becomes possible." It's never fully explained that "items" are both the little data fields themselves, but also required for attachment by subtrees. A subtree cannot have subtree directly; it must have an item which can then have a subtree.

Much code can be generated (will show in a future blog post) and in fact, some of the example plugins shown from epan/dissectors/* are generated. See packet-rrc.c which weights in at over 7MB! Anyways, as a proof of concept, I made a dissector for the canonical WAV file format.

packet-wav.c - dissector for canonical WAV files

Nearly every rule in the coding style / compatibility section was broken in this code and there's probably leaks and security problems; just a disclaimer. So what does it look like?

You can click fields in the tree struct and the hex view will highlight the corresponding bytes and visa-versa.

Now can we simplify things? If we forfeit the ability to do the advanced filter expressions, we can declare just one "dummy" field and subtree, and use its handle every time we add a field and subtree. Instead of relying on Wireshark to format the data for us (and using its complicated string lookup and bitfield mechanisms), we add most things with field type FT_NONE and with *_format() functions, supplying our own strings. Often you can just tack on additional data to an item via proto_item_append_text(). Here's take two:

packet-wav-new.c - a clearer dissector for canonical WAV files

You'll also need:

Makefile - for GNU make to build pcap-wrap utility and wav dissectors

A WAV file is almost a disappointing example, but again it was just for POC. Here's Wireshark chewing on something a little more complicated:

A bug exists in wireshark where if more than one dissector for "wtap_encap" exists in the plugins directory, plugin tests will not continue after the first, even if the first plugin answers "no" (returning 0) from its dissect() function.

packet-whatever.c: dissect() (returns 0)
wireshark/epan/packet.c: call_dissector_work() (returns 0)
wireshark/epan/packet.c: dissector_try_port_new() (returns FALSE)
wireshark/epan/packet.c: dissector_try_port() (returns FALSE)
wireshark/epan/dissectors/packet-frame.c: dissect_frame() (doesn't try other dissectors in sub_dissectors)

I don't have the wireshark know-how to make a proper fix/patch and Wireshark bug database is down at the moment. It sucks but for now I make sure just one of these plugins are present to wireshark at a time.

So do you think this practical? Or is it just not the right tool for the job?