11.2 SMB Message Structure

Figure 11.1 provides an overview of SMB gross anatomy. It shows that SMBs are composed of three basic parts :

Figure 11.1. SMB gross anatomy

SMB messages are composed of three basic parts: the header, the parameters, and the data.

• the Header,

• the Parameter Block, and

• the Data Block.

Either or both of the latter two segments may be vestigial (size == 0) in some specimens.

11.2.1 SMB Message Header

Starting at the top, the SMB header is arranged like so:

We can also dissect the header using the simple syntax presented previously:

 SMB_HEADER   {   PROTOCOL  = "\xffSMB"   COMMAND   = <SMB Command code (one byte)>   STATUS    = <Status code>   FLAGS     = <Old flags>   FLAGS2    = <New flags>   EXTRA     = <Sometimes used for additional data>   TID       = <Tree ID>   PID       = <Process ID>   UID       = <User ID>   MID       = <Multiplex ID>   } 

We now have a pair of perspectives on the header structure. Time for some good, old-fashioned descriptive text.

The PROTOCOL and COMMAND fields

The SMB header starts off easily enough. The first four bytes are the protocol identifier string, which always has the same value, " \xffSMB ". It's not particularly clear ^[3] why this is included in the SMBs but there it is, and it's in all of them.

^[3] ...to me.

The next byte is the COMMAND field, which tells us what kind of SMB we are looking at. In the NEGOTIATE PROTOCOL messages captured above, the COMMAND field has a value of 0x72 (aka SMB_COM_NEGOTIATE ). The SNIA doc has a list of the available command codes. That list is probably complete, but this is SMB we are talking about, so you never know...

The STATUS field

Now things start to get surreally interesting.

DOS and OS/2 use 16-bit error codes, grouped into classes. To accommodate these codes, the STATUS field is subdivided like so:

Windows NT introduced a new set of 32-bit error codes, known as NT_STATUS codes. These use the entire status field to hold the NT_Status value:

With two error code formats from which to choose, the client and server must confer to decide which set will be used. How that is done will be explained later on. Error code handling is a large- sized topic with extra sauce.

FLAGS and FLAGS2

Look around the Web for a copy of a document called COREP.TXT . ^[4] This is probably the earliest SMB documentation that is also easy to find. In COREP.TXT , you can see that the original SMB header layout reserved fifteen bytes following the error code field. Those 15 bytes have, over time, been carved up for a variety of uses.

^[4] The first place to look is Microsoft's CIFS FTP site: ftp://ftp.microsoft.com/developr/drg/CIFS/. The COREP.TXT file is formatted for printing on an old-style dot-matrix printer, which makes it look a little goofy in places (e.g. bold font is accomplished by typing a character, then backspacing, then re-typing the same character). The same content is available in an alternate format in the file SMB-CORE.PS . See the References section.

The first formerly-reserved byte is now known as the FLAGS field. The bits of the FLAGS field are used to modify the interpretation of the SMB. For example, the highest-order bit is used to indicate whether the SMB is a request ( ) or a response ( 1 ).

Following the FLAGS field is the two-byte FLAGS2 field. This set of bits is used to indicate the use of newer features, such as the 32-bit NT_STATUS error codes.

The EXTRA field

The EXTRA field takes up most of the remaining formerly-reserved bytes. It contains two subfields, as shown below:

The PidHigh subfield is used to accommodate systems that have 32-bit Process IDs. The original SMB header format only had room for 16-bit PIDs (in the PID field, described further on).

The 8-byte Signature subfield is for SMB message signing, which uses cryptography to protect against a variety of attacks that might be tried by badguys hoping to gain unauthorized access to SMB shares.

When not in use, these fields must be filled with zeros.

TID , PID , UID , and MID

TID

The "Tree ID." In SMB, a share name typically represents a directory or subdirectory tree on the server. The SMB used to open a share is called a "Tree Connect" because it allows the client to connect to the shared [sub]directory tree. That's where the name comes from. The TID field is used to identify connections to shares once they have been established.

PID

The "Process ID." This value is set by the client, and is intended as an identifier for the process sending the SMB request. The most important thing to note regarding the PID is that file locking and access modes are maintained relative to the value in this field.

The PID is 16 bits wide, but it can be extended to 32 bits using the EXTRA.PidHigh field described earlier.

UID

The "User ID." This is also known as a VUID ( V irtual U ser ID ). It is assigned by the server after the user has authenticated and is valid until the user logs off. It does not need to be the user's actual User ID on the server system. Think of it as a session token assigned to a successful logon.

MID

The "Multiplex ID." This is used by the client to keep track of multiple outstanding requests . The server must echo back the MID and the PID provided in the client request. The client can use those values to make sure that the reply is matched up to the correct request.

The TID and [V] UID are assigned and managed by the server, while the PID and MID are assigned by the client. It is important to note that the values in these fields do not necessarily have any meaning outside of the SMB connection. The PID , for example, does not need to be the actual ID of the client process. The client and server assign values to these fields in order to keep track of context, and that's all.

11.2.2 SMB Message Parameters

In the middle of the SMB message are two fields labeled WordCount and Words[] . For our purposes, we will identify these two fields as being the SMB_PARAMETERS block, which looks like this:

 SMB_PARAMETERS   {   WordCount         = <Number of words in the Words array>   Words[WordCount]  = <SMB parameters; varies with SMB command>   } 

The Words field is simply a block of data that is 2 x WordCount bytes in length. Perhaps at one time the intention was that it would contain only two-byte values (a quick look at COREP.TXT suggests that this is the case). In practice, all sorts of stuff is thrown in there.

Each SMB message type (species?) has a different record structure that is carried in the Words block. Think of that structure as representing the parameters passed to a function (the function identified by the SMB command code listed in the header).

11.2.3 SMB Message Data

Following the SMB_PARAMETERS is another block of data, the content of which also varies in structure on a per-SMB basis:

 SMB_DATA   {   ByteCount        = <Number of bytes in the Bytes field>   Bytes[ByteCount] = <Contents varies with SMB command>   } 

The Bytes field holds the data to be manipulated. For example, it may contain the data retrieved in response to a READ operation, or the data to be written by a WRITE operation. In many cases, though, the SMB_DATA block is just another record structure with several subfields. Through time, SMB has evolved lazily and any functional distinction that may have separated the Parameter and Data blocks has been blurred.

Note that the SMB_DATA.ByteCount field is an unsigned short, while the SMB_PARAMETERS.WordCount field is an unsigned byte. That means that the SMB_PARAMETERS.Words block is limited in length to 510 bytes (2 x 255), while SMB_DATA.Bytes may be as much as 65535 bytes in length. If you add all that up, and then add in the SMB_PARAMETERS.WordCount field, the SMB_DATA.ByteCount field, and the size of the header, you will find that the whole thing fits easily into the 2 ¹⁷ 1 bytes made available in the NBT SESSION MESSAGE header.