On Sun, 1 Sep 2002, Todd Sabin wrote:
> Richard Sharpe <rsharpe@xxxxxxxxxx> writes:
>
> > Hi,
> >
> > I was looking at the NTLMSSP dissector and running it over some data now
> > that SPNEGO is working OK, and I noticed two things:
> >
> > 1. We know that the NTLMSSP blob is NDR encoded, so rather than breaking
> > it out by hand, it would be a lot more useful if the support in
> > packet-dcerpc.c et al was used.
>
> Though they look like NDR, and are quite similar, they're not. I'm
> pretty sure they don't pay attention to the data representation, even
> when they're used with DCERPC. I.e., they're always little endian.
Well, that is true. They assume LE data representation. Considering that
they have not go through a bind and etc, this seems reasonable.
> Also, for uni strings that are "empty", the pointer is non-null and
> indicates the offset where the data would have occurred, if there were
> any. In NDR, if you did that, there'd be a max, offset, and count
> (what samba calls a uni_ldr(?), I think) in the deferred data. There
> isn't any in the NTLMSSP blobs.
Hmmm, well in the NTLMSSP_AUTH these things seem to be top level ref
pointers, and there is definitely a pointer there to an empty string. We
have a 0 max, a 0 count, and an offset that points to the end of the blob.
However, there is also a BLOB in the NTLMSSP_CHAL BLOB, that has an
interesting encoding. I found the code in Samba that handles it, and it
makes more sense now. There are 5 strings in the blob, a couple of which
are empty in the trace I have.
They go:
USHORT: Some sort of seq number
USHORT: String lenght (total bytes in a UCS2-LE string)
UCS2-LE string
... four more of the above.
Regards
-----
Richard Sharpe, rsharpe@xxxxxxxxxx, rsharpe@xxxxxxxxx,
sharpe@xxxxxxxxxxxx
