The data portion of SMBs typically contains the data to be read or written, file paths, or directory paths. The format of the data portion depends on the message. All fields in the data portion have the same format. In every case it consists of an identifier byte followed by the data.
| Identifier =============== |
Description ========================= |
Value ===== |
| Data Block Dialect Pathname ASCII Variable block |
See Below Null terminated String Null terminated String Null terminated String See Below |
1 2 3 4 5 |
When the identifier indicates a data block or variable block then the format is a word indicating the length followed by the data.
In all dialects prior to NT LM 0.12, all strings are encoded in ASCII. If the agreed dialect is NT LM 0.12 or later, Unicode strings may be exchanged. Unicode strings include file names, resource names, and user names. This applies to null-terminated strings, length specified strings and the type-prefixed strings. In all cases where a string is passed in Unicode format, the Unicode string must be word-aligned with respect to the beginning of the SMB. 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 SMBs, items 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 SMB (as opposed to simply being found at the byte following the preceding field,) it is guaranteed that the offset will be properly aligned.
Strings that are never passed in Unicode are:
When Unicode is negotiated, bit 15 should be set in the flags2 field of every SMB header.
Despite the flexible encoding scheme, no field of a data portion may be omitted or included out of order. In addition, neither an wordcount nor bytecount of value 0 at the end of a message may be omitted.