Hello Todd,
I will do some digging and see if there is any mention of the endianness for the fields in question.
You are absolutely correct in that the NTLMSSP code should only be invoked if the DCE/RPC auth_type is '10'. I will make the appropriate change.
Regarding the creation of a sub-dissector, this is a good idea. However, I think initially, I will focus on the proper decoding of the fields for the DCE/RPC packets. Once I have this done, it should not be too difficult for me to break the code into it's own dissector. Admittedly, a large influence on this decision is that I have never written a sub-dissector, and will have to look at some of the other dissectors to see how it is done.
Any recommendations you could make on examples of the 'model dissector' would be appreciated. Since I will probably copy another dissector when writing mine, it would be helpful to use one of the better written dissectors as a starting point.
Thanks,
Devin
Quoting Todd Sabin <tsabin@xxxxxxxxxxxxx>:
> Ronnie Sahlberg <sahlberg@xxxxxxxxxxxxxxxx> writes:
>
> > Hi,
> >
> > Looks very good.
> > But i have some suggestions:
> > [...]
> >
> > 4, in dissect_dcerpc_ntlmssp_negotiate()
> > You use tvb_get_letohs() to read the 16bit bitmask with the flags.
> > This is a bug and will not work if the host sending the packet is big
> > endian.
> > The byteorder of DCERPC types are always encoded as the native format
> of the
> > sender.
> > There are other users of these things which are not x86 based. Think
> NT for
> > MIPS/ALPHA/PPC/...
> > (dead platforms now, but they do exist).
> > Instead, when reading datatypes for DCERPC you should use the
> accessors
> > specially made for DCERPC.
> > These accessors are called dissect_ndr_xxx().
>
> I'm not sure about that. As far as the NDR is concerned, these auth
> blobs are just byte arrays. Also, these same NTLMSSP blobs are used
> in a lot of other contexts besides just DCERPC and they themselves
> contain no indicator of endianness, so I wouldn't be at all surprised
> if they're required to be little endian. Not sure, though.
>
> That leads into my main suggestion, which is that I think you (Devin)
> should create an entirely new dissector, say packet-ntlmssp.c(?),
> instead of adding this to DCERPC. There are two reasons. First, as
> mentioned above, NTLMSSP can be used in many other contexts (LDAP,
> HTTP, Telnet, etc.), and having a separate dissector for it would make
> your work usable for those, as well. Second, DCERPC auth data doesn't
> have to be NTLMSSP. You need to check that the auth_type field
> (hf_dcerpc_auth_type) is 10 before dissecting it as NTLMSSP. So the
> best approach would be to have DCERPC do a handoff to a subdissector
> based on auth-type and have the NTLMSSP dissector register with it for
> type 10.
>
> That may be more work than you're looking for, but you did ask. :)
>
>
> Todd
>
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
732-652-5211