11.3 Case in Point: NEGOTIATE PROTOCOL

11.3 Case in Point: NEGOTIATE PROTOCOL

Now that we have an overview of the structure of SMB messages, we can take a closer look at our live specimen. Remember packets 9 and 10 from the capture we made earlier? They show a NEGOTIATE PROTOCOL exchange. Let's get out the tweezers, the pocket knife , and dad's hammer and see what's inside.

 NEGOTIATE_PROTOCOL_REQUEST   {   SMB_HEADER     {     PROTOCOL  = "\xffSMB"     COMMAND   = SMB_COM_NEGOTIATE (0x72)     STATUS       {       ErrorClass = 0x00   (Success)       ErrorCode  = 0x0000 (No Error)       }     FLAGS     = 0x18 (Pathnames are case-insensitive)     FLAGS2    = 0x8001 (Unicode and long filename support)     EXTRA       {       PidHigh    = 0x0000       Signature  = 0 (all bytes zero filled)       }     TID       = 0 (Not yet known)     PID       = <Client Process ID>     UID       = 0 (Not yet known)     MID       = 2 (often 0 or 1, but varies per OS)     }   SMB_PARAMETERS     {     WordCount = 0     Words     = <empty>     }   SMB_DATA     {     ByteCount = 12     Bytes       {       BufferFormat = 0x02 (Dialect)       Name         = "NT LM 0.12" (nul terminated)       }     }   } 

The breakdown of packet 9 shows the SMB NEGOTIATE PROTOCOL REQUEST as sent by the jCIFS Exists utility. Other clients will use slightly different values, but they are all variations on the same theme. Some features worth noting:

• The COMMAND field has a value of 0x72 ( SMB_COM_NEGOTIATE ). That's how we know that this is a NEGOTIATE PROTOCOL message. We also know that it is a REQUEST rather than a RESPONSE because the highest-order bit in the FLAGS field has a value of zero ( ).

• The STATUS field is all zeros at this point because we haven't yet done anything to cause an error. Also, the error messages are presented in the older DOS format. This is because jCIFS is indicating, via a bit in the FLAGS2 field, that it is using the DOS format. We'll dig into those bits later on.

• Several fields (the EXTRA.Signature , the TID , and the UID , to name a few) contain zeros. The content of these fields has not yet been determined, and they may or may not be filled in later on. It all depends upon the types of SMB requests that are issued. Stay tuned .

• In this particular SMB the Parameter block is empty and all of the useful information is being carried in the Data block. In contrast, the response packet from the server (packet 10) makes use of both the Parameter and Data blocks ( assuming that there are no errors). See for yourself by looking at the NEGOTIATE PROTOCOL RESPONSE in your capture.

The Data block in the request contains the list of protocols that the client is able to speak. jCIFS only knows one dialect, so only one name is listed in the message above. As you can see, jCIFS implements the "NT LM 0.12" dialect (the most recent and widely supported as of this writing). Other clients, such as Samba's smbclient , support a longer list of dialects.