Wireshark-dev: [Wireshark-dev] .NET Based Dissector Plugin
From: "Kelvin Proctor" <Kelvin.Proctor@xxxxxxxxxx>
Date: Wed, 25 Jul 2007 17:22:56 +1000
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 ______________________________________________________________________
- Follow-Ups:
- Re: [Wireshark-dev] .NET Based Dissector Plugin
- From: Jaap Keuter
- Re: [Wireshark-dev] .NET Based Dissector Plugin
- Prev by Date: Re: [Wireshark-dev] New dissector: TNEF
- Next by Date: [Wireshark-dev] Patch to fix broken compilation
- Previous by thread: Re: [Wireshark-dev] [PATCH] packet-bootp.c: enhancement to decode DHCP option 121
- Next by thread: Re: [Wireshark-dev] .NET Based Dissector Plugin
- Index(es):