11.4 The AndX Mutation

In the trace given above, Ethereal has identified packets 11 and 12 as being a SESSION SETUP ANDX exchange. ^[5] The term " ANDX " at the end of the names indicates that these messages belong to a curious class of creatures known as "AndX messages." SMB AndX messages are actually several SMBs combined into a single symbiotic packet as shown in Figure 11.2. It is an efficient mutation.

^[5] Ethereal version 0.9.3 will report the name of the last AndX Command in the chain, rather than the first. This was fixed somewhere between 0.9.3 and 0.9.6. The trick with Ethereal is to update early and often.

Figure 11.2. AndX SMBs

AndX SMBs combine several SMB messages into one. Only one header is used, but each parameter block contains information identifying the next AndX body segment.

AndX messages work something like a linked list. Each Parameter block in an AndX message begins with the following structure:

The AndXCommand field provides the SMB command code for the next AndX block in the list ( not the current one). The AndXOffset contains the byte index, relative to the start of the SMB header, of that next AndX block think of it as a pointer. Since the AndXOffset value is independent of the SMB_PARAMETERS.WordCount and SMB_DATA.ByteCount values, it is possible to provide padding between the AndX blocks as shown in Figure 11.3.

Figure 11.3. AndX SMB chaining

The AndXOffset value in each AndX parameter block gives the offset (relative to the start of the SMB) of the next AndX block. The AndXOffset of the last AndX block has a value of zero ( ).

Now that we have a general idea of what an SMB AndX message looks like we are ready to dissect packet 11. It looks like this:

 SESSION_SETUP_ANDX_REQUEST   {   SMB_HEADER     {     PROTOCOL  = "\xffSMB"     COMMAND   = SMB_COM_SESSION_SETUP_ANDX (0x73)     STATUS       {       ErrorClass = 0x00   (Success)       ErrorCode  = 0x0000 (No Error)       }     FLAGS     = 0x18 (Pathnames are case-insensitive)     FLAGS2    = 0x0001 (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)     }   ANDX_BLOCK[0] (Session Setup AndX Request)     {     SMB_PARAMETERS       {       WordCount     = 13       AndXCommand   = SMB_COM_TREE_CONNECT_ANDX (0x75)       AndXOffset    = 79       MaxBufferSize = 1300       MaxMpxCount   = 2       VcNumber      = 1       SessionKey    = 0       CaseInsensitivePasswordLength = 0       CaseSensitivePasswordLength   = 0       Capabilities  = 0x00000014       }     SMB_DATA       {       ByteCount     = 20       AccountName   = "GUEST"       PrimaryDomain = "?"       NativeOS      = "Linux"       NativeLanMan  = "jCIFS"       }     }   ANDX_BLOCK[1] (Tree Connect AndX Request)     {     SMB_PARAMETERS       {       WordCount       = 4       AndXCommand     = SMB_COM_NONE (0xFF)       AndXOffset      = 0       Flags           = 0x0000       PasswordLength  = 1       }     SMB_DATA       {       ByteCount       = 22       Password        = ""       Path            = "\SMEDLEY\HOME"       Service         = "?????"  (yes, really)       }     }   } 

There is a lot of information in that message, but we are not yet ready to dig into the details. There is just too much to cover all of it at once. Our goals right now are simply to highlight the workings of the AndX blocks, and to provide a glimpse inside the SESSION SETUP ANDX and TREE CONNECT ANDX sub-messages so that we will have something to talk about later on.

The block labeled ANDX_BLOCK[0] is the body of the SESSION SETUP REQUEST , and ANDX_BLOCK[1] contains the TREE CONNECT REQUEST . Note that the AndXCommand field in the final AndX block is given a value of 0xFF . This, in addition to the zero offset in the AndXOffset field, indicates the end of the AndX list.