Ethereal-dev: [Ethereal-dev] RE: Missing UUID inference
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Eric Wedel <ewedel@xxxxxxxxxxx>
Date: Fri, 24 Oct 2003 19:40:31 -0700
Hi.. Have spent some quality time trying to come up with a UI for setting the opnum / UUID inference associations suggested for the below patch. Actually, two approaches were suggested: 1) call each DCE/RPC subdissector looking to see which can handle the protocol (no prefs UI needed, presumably), or 2) set up a prefs UI which can be used to set the opnums which imply a given UUID. The idea in either case being to get away from the present hard-coded knowledge of just a few (probably application-specific) opnum/UUID inferences. Regarding option (1), it seems the DCE/RPC subdissectors are not presently structured to provide a go/no-go sort of response. They merely return an offset indicating how much of the packet they "consumed." Consumed in quotes since at least some of the NDR parsing seems to advance the offset regardless of whether the data is valid. So it doesn't even seem practical to use the offset output to decide whether a dissector likes a packet. For option (2), I tried the simple approach of adding an integer preference to the main DCP/RPC preferences pane for each UUID, to allow selection of opnum per UUID mapping. This produced a totally unworkable preferences dialog, since the dialog apparently has no provision for introducing a scrollable child pane when the full set of preferences items for a module exceeds a "reasonable" dialog window size (whatever that might be :-). There are a lot more DCE/RPC subdissectors than I had thought. At this point, it seems like the best approach would be a custom dialog linked from a button on the DCE/RPC preferences pane. The present generic preferences machinery used by the dissectors doesn't seem to support this. I'd be willing to take a stab at it, but it is not clear to me what giving the DCE/RPC dissector knowledge of a GTK dialog callback (as needed by the button setup, presumably) would do to tethereal. Comments / suggestions very welcome at this point. thanks, Eric > -----Original Message----- > From: Eric Wedel > Sent: Wednesday, October 08, 2003 7:19 PM > To: 'ethereal-dev@xxxxxxxxxxxx' > Subject: Missing UUID inference > > > Hi.. > > We just had a field case where the customer seemed unable to > obtain full traces. Instead, they kept giving us traces > where the DCERPC bind had happened sometime earlier, so > ethereal didn't know how to interpret subsequent traffic. > > Looked through 0.9.15, and couldn't see any option to force > the UUID. So I knocked together a little hack to guess the > UUID when a request is seen whose conversation doesn't have a > known binding. Patch is attached for your amusement. > > This code cannot be considered finished, as at a minimum it > would need an option flag so it only turns on when the user > wants it. And of course the in-line externs are yucky. But > I wanted to post the code as-is to get reactions to the whole > idea. Did a quick archive search and didn't find any > discussion, not sure if this idea has been considered before. > I can tell you that when you need it, this is *very* helpful. :-) > > Comments? > > regards, Eric > > ------------------------------------------- > > diff -r -E -u -X eth.x orig-0.9.15/packet-dcerpc-lsa.c > ethereal-0.9.15/packet-dcerpc-lsa.c > --- orig-0.9.15/packet-dcerpc-lsa.c 2003-09-04 > 19:09:36.000000000 -0700 > +++ ethereal-0.9.15/packet-dcerpc-lsa.c 2003-10-07 > 15:49:57.000000000 -0700 > @@ -4493,12 +4493,12 @@ > > /* Protocol handoff */ > > -static e_uuid_t uuid_dcerpc_lsa = { > +e_uuid_t uuid_dcerpc_lsa = { > 0x12345778, 0x1234, 0xabcd, > { 0xef, 0x00, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab} > }; > > -static guint16 ver_dcerpc_lsa = 0; > +guint16 ver_dcerpc_lsa = 0; > > void > proto_reg_handoff_dcerpc_lsa(void) > diff -r -E -u -X eth.x orig-0.9.15/packet-dcerpc-netlogon.c > ethereal-0.9.15/packet-dcerpc-netlogon.c > --- orig-0.9.15/packet-dcerpc-netlogon.c 2003-08-05 > 19:26:58.000000000 -0700 > +++ ethereal-0.9.15/packet-dcerpc-netlogon.c 2003-10-07 > 13:23:37.000000000 -0700 > @@ -247,12 +247,12 @@ > static gint ett_get_dcname_request_flags = -1; > static gint ett_dc_flags = -1; > > -static e_uuid_t uuid_dcerpc_netlogon = { > +e_uuid_t uuid_dcerpc_netlogon = { > 0x12345678, 0x1234, 0xabcd, > { 0xef, 0x00, 0x01, 0x23, 0x45, 0x67, 0xcf, 0xfb } > }; > > -static guint16 ver_dcerpc_netlogon = 1; > +guint16 ver_dcerpc_netlogon = 1; > > > > diff -r -E -u -X eth.x orig-0.9.15/packet-dcerpc.c > ethereal-0.9.15/packet-dcerpc.c > --- orig-0.9.15/packet-dcerpc.c 2003-08-05 > 19:27:00.000000000 -0700 > +++ ethereal-0.9.15/packet-dcerpc.c 2003-10-08 > 13:31:29.000000000 -0700 > @@ -2590,7 +2590,62 @@ > bind_key.ctx_id=ctx_id; > bind_key.smb_fid=get_smb_fid(pinfo->private_data); > > - > if((bind_value=g_hash_table_lookup(dcerpc_binds, &bind_key)) ){ > + bind_value=g_hash_table_lookup(dcerpc_binds, &bind_key); > + > + /* XXX - major HACK. If UUID binding is not > yet known for > + this request's conversation, then fake one up. > + Hopefully targeted UUID's dissectors > will be able to > + protect themselves against improperly > assigned packets. > + */ > + if (bind_value == 0) { > + /* values for UUID reg in > packet-dcerpc-netlogon.c: */ > + extern e_uuid_t uuid_dcerpc_netlogon; > + extern guint16 ver_dcerpc_netlogon; > + > + /* values for UUID reg in packet-dcerpc-lsa.c: */ > + extern e_uuid_t uuid_dcerpc_lsa; > + extern guint16 ver_dcerpc_lsa; > + > + /* XXX - we should gate this heuristic > opnum-based guesswork > + so that it is only attempted when > our RPC is being > + passed over something CIFS-like > (SMB, or ??). > + Not sure how to find our > lower-layer dissectors though. > + */ > + switch (opnum) { > + case 2: > + /* assume netlogon's SamLogon */ > + bind_value = g_mem_chunk_alloc > (dcerpc_bind_value_chunk); > + bind_value->uuid = uuid_dcerpc_netlogon; > + bind_value->ver = ver_dcerpc_netlogon; > + break; > + > + case 15: > + /* assume lsa's LookupSIDs */ > + bind_value = g_mem_chunk_alloc > (dcerpc_bind_value_chunk); > + bind_value->uuid = uuid_dcerpc_lsa; > + bind_value->ver = ver_dcerpc_lsa; > + break; > + } > + > + if (bind_value != 0) { > + /* add this entry to the bind table. > By definition, > + no prior identical entries to remove. > + */ > + > + dcerpc_bind_key *key; > + > + key = g_mem_chunk_alloc (dcerpc_bind_key_chunk); > + key->conv = conv; > + key->ctx_id = ctx_id; > + key->smb_fid = get_smb_fid(pinfo->private_data); > + > + g_hash_table_insert (dcerpc_binds, key, > bind_value); > + } > + } > + > + /* resume normal packet processing.. */ > + > + if(bind_value != 0){ > if(!(hdr->flags&PFC_FIRST_FRAG)){ > dcerpc_call_key call_key; > dcerpc_call_value *call_value; > ********************************************************************* This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin@xxxxxxxxxxx *********************************************************************
- Follow-Ups:
- Re: [Ethereal-dev] RE: Missing UUID inference
- From: Ronnie Sahlberg
- Re: [Ethereal-dev] RE: Missing UUID inference
- From: Tim Potter
- Re: [Ethereal-dev] RE: Missing UUID inference
- Prev by Date: [Ethereal-dev] New IOSTAT graphs
- Next by Date: Re: [Ethereal-dev] RE: Missing UUID inference
- Previous by thread: Re: [Ethereal-dev] New IOSTAT graphs
- Next by thread: Re: [Ethereal-dev] RE: Missing UUID inference
- Index(es):