Home

Smb2 Design Goals

Sockets should be made by the application, not the library

This means Smb2 should work with anything that responds to a certain interface, i.e., if it looks like a socket, it should work. To that end, the Smb2::Dispatcher classes act as a wrapper for whatever socket you like.

Follow the spec by default

The Smb2 library should, by default, produce packets that look like Windows' packets or smbclient's packets.

Allow deviating when necessary

Since BitStruct objects are just Strings, it's pretty easy to modify them before dumping to the wire. If an application wants to push malformed packets, the library shouldn't care.

Smb2 Remaining Work

List files

• https://github.com/rapid7/smb2/milestones/List%20files

Stat files

• https://github.com/rapid7/smb2/milestones/Query%20File%20Info

The information needed for what we usually think of as stat comes from the various QueryFileInfo requests. In smbclient, when you type ls it sends a FileAllInformation request

1. See what Windows does in this case
2. Implement whatever Windows does

smbclient workalike

• https://github.com/rapid7/smb2/issues/40

Dialect differences

Requires combing through all the packet descriptions and examples for differences between 0x0200, 0x0202, and 0x0224.

Dialect 0x0200

• https://github.com/rapid7/smb2/issues/5

Needed for talking to Vista with no patches.

Dialect 0x0202

Main thing I tried to emulate with existing client.

Dialect 0x0224 - optional

Last update to 2.x before the switch to 3.x; only used by later versions of 2008, if I'm not mistaken. Requires research.

Dialect 0x030* - optional

Since, from what I understand, anything that supports SMB3.x will also support at least 2.02, this is not strictly necessary for talking to existing servers, but important for future-proofing.

• https://github.com/rapid7/smb2/milestones/Dialect%200x0300

If it comes down to it, I'd rather have this than 0x0224, but that one will be a lot easier, I'm sure.

Pass-the-Hash in rubyntlm gem

Necessary for preserving the same functionality as existing protocol in Rex::Proto::SMB. May involve forking gem until they can merge into upstream.

Integration with Metasploit Framework

NTLM

First, we need NTLM support to work for SMB1 and SMB2 protocols. MSF has support for NTLM in HTTP as well. The way I see it, we have two options for NTLM support:

1. Use rubyntlm in Rex::Proto::SMB and Rex::Proto::Http.
   • pro: makes everything that uses NTLM consistent; cleaner API
   • con: more work
2. Keep the namespaced copy of our forked NTLM code in Rex::Proto::NTLM and use rubyntlm only for Smb2
   • pro: easier
   • con: code bloat/duplication

Given enough time, I obviously would prefer option 1.

DCERPC

Make Rex::Proto::DCERPC work on top of Smb2. It already works on top of the old Rex::Proto::SMB, but I don't know exactly how much effort this will be.

Smb2 backports - optional

On the bubble

Extend Smb2's bit-struct stuff to work on SMB 1. This would have the advantage of consolidating the two libraries and allowing a simpler client for negotiating which protocol to use with a given server.

Server implementation - probably not

On the bubble

Many unknown unknowns

Kerberos support - probably not

There is a partial implementation of kerberos in Rex that may make this easier, but I'm not optimistic on getting it done in the short term