Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] Keeping decryption state of dissector in sync

From: Max <dmitrmax@xxxxxxxxx>
Date: Fri, 29 Apr 2011 18:59:45 +0400
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?

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?

2) How to run dissector on the decrypted tvbuff? Should it be done
manually or Wireshark does this itself?
    If I should run it manually than how to get the encrypted tvbuff
on the subsequent calls of the protocol dissector?

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).

--
Max