I will look at the fixes you mention below ... I am struggling with
ucarrays at the moment, because I believe that one of the srvsvc calls uses
them, and they don't seem to do the right things.
they should do the right thing. however there are some ndr gotchas to watch
out for.
arrays in ndr are a bit weird and this puts restrictions on dissectors.
first, arrays can not be top level objects in NDR.
That means that you can never call ...ucarray or ...ucvarray directly from
the request/reply dissectors.
you must tehrefore go through a pointer to use the array dissector.
if the capture looks like there is no pointer (4 bytes) in teh bytestream
this just means that it is a toplevel REF pointer,
so, when arrays look like they are toplevel objects, what you really have is
a toplevel REF pointer to an array.
Thus call it through dissect_ndr_pointer(..._REF...) to a wrapper calling
...ucarray or ...ucvarray
second, when ethereal dereferences pointers for dcerpc, ethereal will always
call each pointed to subdissector TWICE. Once with conformant_run==1 and
once with conformant_run==0.
the reason for this is to be able to dissect structures with embedded arrays
in them, for that case the array metadata and the array content are stored
at different places in teh bytestream with other data inbetween.
See packet-dcerpc.c for the function that follow pointers, there is a good
explanation there.
calling each subdissector twice when handling pointers have a consequence
for the subdissector.
If the subdissector will eat bytes (change offset) outside of calling the
already prepared dissect_ndr... functions (such as calling something in
packet-smb.c which doesnt understand ndr array handling)
you must put an ifstatement in your dissector to prevent it from
eating any bytes in teh packet if conformant_run==1
See packet-dcerpc.c again.
ronnie sahlberg
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.