13.4 Are We There Yet?
Okay, let’s be honest... Ripping apart that NEGOTIATE PROTOCOL RESPONSE SMB was about as exciting as the epic saga of undercooked toast. It doesn’t get any better than that, though, and there’s a lot more of it. Implementing SMB is a game of patience and persistence. It also helps if you get a cheap thrill from fiddly little details. (Just don’t go parsing your packets in public or people will look at you funny.)
It seems, too, that our overview of the SMB Header and the NEGOTIATE PROTOCOL exchange has left a bit of a mess on the floor. We have pulled a lot of concepts off of the shelves and out of the closets, and we will need to do some sorting and organizing before we can put them back. Let’s see what we’ve got:
-
Opportunistic Locks (OpLocks), which were taking up space in the SMB_HEADER.FLAGS field,
-
Virtual Circuits (we found these in the box labeled MaxNumberVCs),
-
The Capabilities bits (and pieces),
-
Distributed File System (DFS), which spilled out when FLAGS2 fell open,
-
Character Encoding — which seems to get into everything, sort of like cat hair and dust,
-
Extended vs. DOS Attributes,
-
Long vs. short names, and...
-
Authentication, including plaintext passwords, Challenge/Response, Extended Security, and Packet Signing.
The only way to approach all of these topics is one-at-a-time. ...but first, take another break. Every now and then, it is a good idea to stop and think about what has been covered so far. This is one of those times. We have finished tearing apart SMB headers and the body of a NEGOTIATE PROTOCOL message. That should provide some familiarity with the overall structure of SMBs. Try doing some packet captures, or skim through the SNIA CIFS Technical Reference. It should all begin to make a little more sense now than it did when we started.