G'day Wireshark Team,
In the last few days I have succeeded in getting a dissector plugin
running
that is a mixed-mode C++ assembly (for those unfamiliar with
Microsoft.NET
this dll is half native C++ / half .NET).
Why did I do this? My company has built a new networking layer for our
product that is all .NET based. We have a base IMessage interface that
all
messages derive from the provide Serialize / Deserialize methods etc...
All of this code has been done in C#.
Unfortunately there are a lot of message types and they are going to be
changing quite a bit for a while to come. What I wanted to do was to
get the
messages classes to deserialize themselves and then get access to all
their
properties via reflection.
How did I go about this? The basic steps were:
1. Get Wireshark compiling under VS2005. (easy)
2. Stop my plugin from using the make-dissector-reg.py script and just
do that
bit by hand. (my plugin started life a few years ago so this was
easy)
3. Convert from C -> C++. This involved a few makefile tweaks and
extern "C"
in the DLL exports.
4. Make the plugin compile using the /CLR compiler flag. There were
just a
few things this required. It did not like the opaque definition of
struct dissector_handle for dissector_handle_t for example , but I
just
gave it a dummy definition in source file.
5. Break the dissector into '#pragma managed' and '#pragma unmanaged'
segments.
6. Iterate through all the assemblies in the GAC using fusion.dll and
load all
the assemblies for our product.
7. Find all the classes deriving from IMessage and store them.
8. Write a normal dissector for the basic encapsulation protocol that we
used
(just a very simple data_length, data blob sort of protocol)
9. Once you have identified the types and data for each blob create a
new
message class, call deserialize with the data from the encapsulation
packet.
10. Use reflection to find all the public properties of the object and
get
their values. Call ToString() on all the property values to get
strings
to display.
Some of the real fun tricks came from all the things that are normally
statics
in a dissector, such as subtree and field arrays. I had to create
managed
wrapper classes for this sort of thing and allocate memory for them on
the fly.
I can't release the source to the plugin back to the community as it
would make
reverse engineering our product a little bit too easy. However I'm
really
interested in any ways (Wiki pages, more detailed e-mails to this list,
a
section in the developer guide, etc...) that I can contribute the
lessons
learned and techniques I have developed back to the Wireshark community.
Any comments / questions are most welcome.
Cheers,
Kelvin Proctor
Driver Developer
Citect
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
