Ethereal-dev: [Ethereal-dev] Re: dissect_ndr_pointer() experimental unfinished implementation
"Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx> writes:
> Hi Todd, hi list
>
Hi. (Sorry I never wrote back about the other ndr stuff. I got
diverted onto something else. It seems Tim's way ahead of me,
anyway.)
> After reading up a bit on how dcerpc encodes pointers into the pdu's
> I came up with a crude dissect_ndr_pointer() function.
Well, you've chosen a particularly nasty problem. Be great if you
solve it, though.
> I would though want comments as to if this approach would work and if it
> would dissect deferred pointers
> properly as per the dcerpc specification.
>
> If Todd, or someone on the list which understands how pointers are encoded
> in NDR, could just have a quick look
> and tell me if it is a workable approach then I will finish the
> implementation.
The idea of passing a callback which is responsible for dissecting the
pointed to object is, I think, the right approach. However, the
callback can't be put off until the child dissector has finished. All
deferred pointer referents are processed before moving on to the next
arg in a function. So, if you have, say
struct _foo {
[string] char *defer;
uint32 bar;
};
int hairy_rpc_func (struct _foo **pComplex, uint32 Flags);
then what you'd have in the stub is 4 bytes for pComplex. If not
null, then 4 bytes for pComplex->defer and 4 bytes for pComplex->bar.
Then, if pComplex->defer is not null, you'd have the data for that.
Then, you'd have the 4 bytes for Flags, and 4 bytes for the return
code.
I hope that makes sense. This stuff is too hard to describe in
words. :)
Some other things to think about/be aware of:
Having a pointer_default in ethereal probably doesn't make sense.
They're only used in the idl files. Once the idl is written, every
pointer is one of full, unique, or ref. So the dissector for a given
interface should know what they are.
Full pointers from a request can be referred to in the reply. (!)
Yes, that's going to be ugly, if you want to handle it correctly.
Despite what the specs say, unique pointers are not actually
marshalled the same as full pointers. At least, not by MS's runtime.
[I don't know about other implementations. If anyone has sniffs of
AIX or HP-UX dcerpc traffic with or without associated idls, I'd love
to see them.] Either this is because MS deviates from the spec, or
because the spec was updated, or something else :). The specs on the
opengroup's website describe transfer syntax 8a885d04..... _v1_, but
if you look at the stuff you actually see on the wire with NT, it's
actually _v2_ (check the bind packets). Whether this v2 is official,
unofficial, or an MS invention, I don't know. Anyway, the only
difference I've noticed is that with v2 unique pointers seem to be
marshalled like a hybrid of the full and ref pointers. They are
always put on the wire (like full pointers, but not ref pointers), but
their wire representation is the actual pointer value (like ref
pointers, not full pointers).
Todd
