Ulf schriebt:
>
> 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.
Yes, I didn't mean to suggest that the opnum-based scheme should be
used, just that the means of injecting the binding / conversation
association may be helpful in figuring out what to do.
> >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.
dcerpc_init_protocol() does this, and it is registered using
register_init_routine() which should do the job. If anything,
the register_init_routine() comment in packet.h suggests that
the init routine might be called more frequently than necessary
(at least in this case).
> >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.
Absolutely. Individual dissectors register their UUIDs using
dcerpc_init_uuid()
which is in packet-dcerpc.c. It saves the list of UUIDs in a hash table
called dcerpc_uuids. Since that is a hash table, I'm afraid that the
dialog would need to sort the entries for display. At least, it appears
that some sort of protocol name is included in the hash table entries.
>
> >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.
It looks like the context_id could be added to struct _packet_info,
so it would be accessible in the dialog via cfile.edt->pi.
For the purposes of adding a conversation/uuid binding, the DCERPC's
"transport_type" internal param is also needed. Conveniently, this
can also serve as a flag indicating whether the packet in question
is of the DCERPC type.
I've set up another little patch which should provide you most of
the dissector-side tools needed to implement a DCE-RPC tab.
This patch saves the context-id and transport type values where
appropriate, and provides a routine add_conv_to_dcerpc_bind_table()
which the GUI code can call to set up a new UUID/conversation binding.
You'll need to add your own routine to enumerate the values in the
dcerpc_uuids hash table. This routine should probably live in
packet-dcerpc.c, and g_hash_table_foreach() should make it easy. :-)
[Presumably, the foreach call only needs to be made once, since
afaik the list of UUIDs never changes in a program run.]
The conversation can be obtained by calling find_conversation()
using data already stored in _packet_info, e.g.,
conv = find_conversation (&pinfo->src, &pinfo->dst, pinfo->ptype,
pinfo->srcport, pinfo->destport, 0);
and then
add_conv_to_dcerpc_bind_table(conv, pinfo->dcectxid, pinfo,
uuid, ver);
where pinfo is presumably == &(cfile.edt->pi).
It would certainly be possible to embed the find_conversation()
call inside the add routine, but it seemed like it might make it
a tad more general this way. Similarly, the ctx_id argument could
be inferred from pinfo. So if you wanted to be minimal, the args
could be (pinfo, uuid, ver)
where uuid and ver are obtained based on the user's DCERPC interface
selection.
Only problem I can think of here is that since the binding is being
established outside of the DCERPC dissector, it will be necessary to
reinvoke dissection after calling add_conv_to_dcerpc_bind_table().
Presumably, something similar is already done after filtering (or maybe
the other "decode as" options).
>
> >
> >regards,
> >Eric Wedel, Bluearc Engineering
> >
>
Attachment:
ulf2.patch
Description: ulf2.patch
