Wireshark mailing list archives
Re: Keeping decryption state of dissector in sync
From: Jeff Morriss <jeff.morriss.ws () gmail com>
Date: Fri, 29 Apr 2011 12:43:13 -0400
Max wrote:
Hi, I'm new to the list and to the wireshark development. I want to ask you a couple of questions, answers for which I haven't found in the docs and on the Internet. I'm writing a dissector plugin which does dissection of some proprietary protocol which uses encryption and optionally compression. The protocol has multiple phases and from phase to phase the packet format radically changes. So I have to keep the state information of the conversation but run into the problem that Wireshark calls the dissection multiple times for the same packet, so when dissection is called for the last packet in the phase, conversation's state transitions to the next phase, but the next time dissector is called for this packet, it cannot parse the packet any more because it thinks that the packet is malformed - it has the layout of previous phase but dissector resides in the next phase. For now I use "global" conversation state for dissection if the packet has no proto data associated with it, otherwise I use state from associated data which stores the state before first packet dissection was done. Am I right doing such things?
Do you mean you try to use data from the stored conversation state (ala README.request_response_tracking) and if that does not exist then fall back to a global variable? I think normally the fallback to not having the conversation data is to just assume it's the first packet (decode it as such and then create a conversation structure). But maybe I misunderstand your question.
The next problem is decryption and decompression. I've read how this should be done, but I have not found any info regarding the following moments: 1) Whether decryption and decompression should be done every time the dissector is called? Or there is way to figure out that it was already done?
I don't know how it's normally done, but I think the only way you'd know if it had already been done is if you stored the result of the decryption in a dissector-specific structure in a way that you can easily find it again. I suspect, though, that normally the decryption is redone each time it is needed.
2) How to run dissector on the decrypted tvbuff? Should it be done manually or Wireshark does this itself?
You need to do that manually: once you have the decrypted data in a (new) TVB you need to call a (sub)dissector on it.
If I should run it manually than how to get the encrypted tvbuff on the subsequent calls of the protocol dissector?
See (1): either build it again or store it and look it up.
3) If it is supposed that decryption is done every time the dissector is called, how then should I keep the decryption cipher context? Cloning and storing cipher context for every packet may cost a lot of memory, and AFAIK libgcrypt doesn't provide any means to clone the context (cipher handle).
I can't even hazard a guess on this one... ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Keeping decryption state of dissector in sync Max (Apr 29)
- Re: Keeping decryption state of dissector in sync Jeff Morriss (Apr 29)
- Re: Keeping decryption state of dissector in sync Max (Apr 29)
- Re: Keeping decryption state of dissector in sync Stephen Fisher (Apr 29)
- Re: Keeping decryption state of dissector in sync Jeff Morriss (Apr 29)