CIFS Data Buffer and String Formats
The data portion of a CIFS packet typically contains the data to be read or written, file paths, or directory paths. The format of the data portion depends on the command. All fields in the data portion have the same format consisting of an identifier byte followed by the data. In every case it consists of an identifier byte followed by the data.
When the identifier indicates a data block or variable block, then the format is a word indicating the length followed by the data. The following table describes identifier byte values.
| Value | Description |
|---|---|
| 1 | Data block. |
| 2 | Dialect. Null-terminated string. |
| 3 | Pathname. Null-terminated string. |
| 4 | ASCII. Null-terminated string. |
| 5 | Variable block. |
Despite the flexible encoding scheme, no field of a data portion may be omitted or included out of order. In addition, neither a WordCount nor ByteCount field of value 0 at the end of a message may be omitted.
String Formats
In all dialects prior to NTLM 0.12, all strings are encoded in ASCII. If the agreed dialect is NTLM 0.12 or later, Unicode strings may be exchanged. Unicode strings include file, resource, and user names, and may be null-terminated strings, length-specified strings or type-prefixed strings.
In all cases where a string is passed in Unicode format, the Unicode string must be word-aligned. Should the string not naturally fall on a two-byte boundary, a null byte of padding will be inserted, and the Unicode string will begin at the next address.
In the description of the CIFS packet fields, quantities that may be encoded in Unicode or ASCII are labeled as STRING. If the encoding is ASCII, even if the negotiated string is Unicode, the quantity is labeled as UCHAR.
For type-prefixed Unicode strings, the padding byte is found after the type byte. The type byte is 4 (indicating SMB_FORMAT_ASCII) independent of whether the string is ASCII or Unicode. For strings whose start addresses are found using offsets within the fixed part of the packet (as opposed to simply being found at the byte following the preceding field,) it is guaranteed that the offset will be properly aligned.
The protocol strings in the SMB_COM_NEGOTIATE request and the service name string in the TREE_CONNECT_ANDX request are never passed in Unicode.
When Unicode is negotiated, bit 15 should be set in the Flags2 field of every CIFS packet header.