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. :-)
Yes, that's the point where the "correct" implementation have to start.
However, the selection of the missing binding should base on the context
information, not the opnum (as you said yourself, this is a bit horrible).
As this will not work fine, if you are using more than one unknown
interface (which I typically do) in your capture file. As typically if I
couldn't get the context info, this is true for all interfaces.
[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.
I'm not quite sure, if and how this has to be removed later.
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.
It might be possible to do this based on the UUID's registered into the
dcerpc dissector. so you don't have to export all UUID's from all the
subdissectors.
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.
This might be possible in some way, it shouldn't be too complicated, but
didn't had a look.
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?
regards,
Eric Wedel, Bluearc Engineering
