Eric Wedel wrote:
Hi Ulf..
I knocked together a little patch which infers the bind type for
a few CIFS UUIDs, based on the opnum. Have attached a version
for 0.10.6. This approach is a horrible kludge, but it has done
the job for me for a while now. The code at least points the way
to a correct fix, especially now that our resident UI expert
is interested. :-)
Our resident UI expert :-)))
[Had toyed with the idea of adding a GUI some months ago, but the
prospect of leaping into a totally unfamiliar area (I don't do UI
in general, and have zero experience with GTK) has kept me hobbling
along with the attached patch.]
Inside the DCERPC code, it keeps a table mapping from a
(conversation,context id) pair to an associated binding.
The code just after the patch's added switch statement in
epan/dissectors/packet-dcerpc.c
is what makes it work. If those key values can be obtained
from whatever context the "Decode As" dialog has available, then
it should be very simple to give the conversation a binding.
The "key" value used to look up the proper binding contains a
conversation identifier (from find_conversation()), and a context ID
which is apparently dissected out of the DCE packet (see the top of
dissect_dcerpc_cn_rqst() in packet-dcerpc.c).
Not sure how hard it would be to extract these values from the
highlighted packet.
Ideally, the "Decode As" dialog could reach in and grab the values
from the partially-dissected DCERPC packet. Afraid I don't know
how to do that though.
I assume you're thinking of adding a new "DCERPC" tab to the
"Decode As" dialog?
Exactly what I had in mind.
I have a dream that one day, we have a DCERPC tab (only if the packet is
a DCERPC packet), which will list all available interfaces, so you can
select the right one to choose.
The UI part will be easy for me to do, however, the conversation stuff
isn't well known to me.
I will have a look at your patch, and might send a more detailed
response later today (if I find some time).
Regards, ULFL
