There is a lot of stuff that is still unknown about the SMB protocol. This is a partial list of these open questions.

QFS Info Levels

In trans2 QFS (sub command 3) we know how to decode all 11 info levels that windows servers support, plus the two extended unix info levels supported by Samba. What we don't know is why some windows server support level 1008 (OBJECTID_INFORMATION) and some don't. In specific levels:


In the QPATHINFO (sub command 5) and QFILEINFO (sub command 7) trans2 calls we know windows servers support 27 information levels (26 for QFILEINFO). A number of the levels contain fields we don't properly understand. In particular


There are quite a few SETFILEINFO/SETPATHINFO trans2 levels that we don't understand. Windows servers support 19 levels, and we can decode only 13 of these. The levels we don't understand are:

Error Codes

Throughout the protocol we don't know what error codes are considered valid for a particular operation. We have also not fully worked out when a operation uses forced DOS error codes even when NTSTATUS codes are negotiated.

For example, we know that windows servers will return an old style DOS error code ERRSRV:ERRbaduid when an invalid vuid is given in the SMBntcreatex and SMBntcancel calls, but use the NT_STATUS_INVALID_HANDLE NTSTATUS code for other SMB commands with invalid vuid fields. We don't know in what other situations this happens.

String Formatting

The available public documentation on the SMB protocol is very unclear when it comes to string formatting, but we have found that windows clients are extremely fussy about exact formatting conventions. In particular, some strings in the protocol must be always in UTF16 unicode format even when ASCII strings are negotiated, and some must always be in ASCII even UTF16 is negotiated.

Also, some strings must be NULL terminated, and some must not be NULL terminated, but the required termination is not known in many cases. The reason this is critical is that we know that some windows application look for a specific length of the returned string, so if for example a file name is returned with a null termination in a SMBfindfirst search and the client is expecting that the string not be terminated then the client will not recognise the file name, which can lead to data corruption.

Ideally we would extend the wireshark parser to display an error for strings that don't conform to the known 'correct' formatting and termination rules, so we can quickly find these errors in implementations.

A good example of this kind of thing is that the STANDARD info level in trans2 findfirst (level 1) needs to return a null terminated string, but the 8 bit length field at offset 22 in the same returned data must not include the termination in the length calculation. In Samba we mark this string as STR_LEN8BIT|STR_TERMINATE|STR_LEN_NOTERM.

In a similar fashion, most strings that are in UTF16 format are aligned on a 16 bit boundary relative to the start of the SMB packet, but there are exceptions to this rule. For example, the filename returned in the EA_LIST SMB trans2 findfirst level (level 3) is not 16 bit aligned.

SMB/OpenQuestions (last edited 2008-04-12 17:51:36 by localhost)