Pia Sahlberg <piabar@xxxxxxxxxxx> writes:
> 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
