I cant specify a link since www.dcerpc.net seems to have died.
attached are the two files.
lsa-muddle-orig.idl is what i assume are muddle generated.
I think it is TYPE_8 that is the security descriptor.
I think TYPE_8 is generated by muddle but am not sure. If it is generated by
muddle then there
exists an NDR encoding for the security descriptor.
If one chooses the UNIQUE pointers carefully
(they are unique so they could have any arbitrary value for non-NULL)
as the offset inside the packet for where the struvture is, as SMB uses
these fields,
then NDR and SMB could have the identical wire representation of the SD
structure.
lsarpc.idl is what i belive is their handtuned idl file. it contains many
calls not implemented in ethereal yet
but implementing them would be very easy.
The parameters for these calls differs in their representation though from
what the muddle file has.
I dont know which of the idl files to trust to be correct.
----- Original Message -----
From: "Todd Sabin" Subject: Re: [Ethereal-dev] DCERPC-LSA
> Pia Sahlberg
> > I am not too sure about the other missing ones since the idl file:
> > lsarpc.idl is very different/incompatible with the muddle generated one
> > lsa-muddle.idl for the missing calls.
> >
> > I expect the muddle one being more correct as for what types the packets
> > contain but can not be sure.
> > Any captures for "missing" lsa calls would be appreciated since it
> > would allow whether it is lsarpc.idl or lsa-muddle.idl that is correct.
>
> Can you give links to the two files you're talking about? I'll check
> if I know any of the missing calls.
>
> > Different topic:
> > Guy, the changes you made to the dissection of the NT Security
> > descriptor in packet-smb.c , well , this structure is NOT described
> > as just a blob in lsa-muddle.idl.
> >
> > lsa-muddle.idl which is a machine generated idl file for the lsa
> > interface actually has a complete NDR representation of this very
> > structure.
>
> I think Luke post-edited some of those muddle generated files, so
> their present contents might not reflect the exact output of muddle.
>
> > The NDR representation is byte compatible with what is in packet-smb.c
> > if one chooses the UNIQUE pointers (which are just NULL or non-NULL)
> > ((where non-NULL just means the pointer points to a structure, the
> > pointer value, non-NULL, can be any arbitrary value))
> > [...]
> > It is perfectly legal for a LSA implementation to choose the pointers
> > when they should be non-NULL as being the offset which SMB uses.
> >
> > According to lsa-muddle.idl these are unique pointers so it would be
> > perfectly legal as well to choose these pointers when non-NULL to
> > always have the value 0x01, though then it would not be compatilbe
> > with the original NT Security Descriptor dissector in packet-smb.c
> > [...]
> > I.e. NT Security Descriptor when used from LSA/(and other interfaces
> > as well) ARE NDR encoded structures.
> >
> > They just happen to have an indentical representation to what
> > SMB/Transaction use if one chooses the Unique pointer values carefully.
>
> I think you figured this out later in the thread, but that's not
> correct. The typical encoding of an SD doesn't follow the NDR rules
> about the order referents are marshalled. There's really just a win32
> function, MakeSelfRelativeSD, that returns that blob format. At the
> NDR level, they're usually marshalled as a struct something like this:
>
> typedef struct _SD {
> ULONG Length;
> [size_is (Length)] unsigned char *pSD;
> } SD, *PSD;
>
> I.e., the SD itself is just a byte blob as far as NDR is concerned.
>
>
> Todd
>
> _______________________________________________
Attachment:
lsa-muddle-orig.idl
Description: Binary data
Attachment:
lsarpc.idl
Description: Binary data
