Although SMB2 support was our main objective, we took the time to implement some other functionalities that we have detected that were necessary.
SMB2 support for ExportObjects->SMB
The major part of work to write SMB2 support has been finding out where the needed information can be found in smb2 dissector and, for those pieces of information not already there, how to store them in the right place to integrate, as far as we can, into the wireshark code structures. The rest of the code (the part where the file is built from the chunks that are extracted from each packet) has been almost completely reused. We have implemented the minimum functionality to be able to make a proof of concept, but we have tested it against a lot of real captures and it seems to be stable. You can see what it looks like in the following screenshot.
Other major changes
The "File ID" vs. "File Name" dilemma
There was another important issue flying around our minds since we wrote the first plugin. SMB and SMB2 identify a file based on a File ID (which has different formats and meanings in SMB and SMB2). It is usual to find the same file (i.e. same tree_id AND same file_name) several times in the same capture file. That means that it is possible that some parts of a big file are associated with one file_id and other parts of the same file are associated with a different file_id. In that case the plugin, as it was, would report that it knew a percentage of two different files. We were wondering if taking the "tree_id+file_name" as the file identifier could make the plugin to capture the whole file or at least a bigger part of it.
This seemed to make sense, because the plugin builds the final file by inserting the chunks that it receives in the order that appear in the capture, and so it overwrites older parts of the file with newer ones. Yet, we were not completely sure that was the best solution, and finally decided to make it an option for the user, available at
Edit->Preferences->Protocols->SMB and Edit->Preferences->Protocols->SMB2
for that purpose:
Support for other SMB dialects
Some time ago Paul Santangelo pointed out that the plugin didn't work under some circumstances. After studying the capture file that he sent us, we concluded that he was right: we had implemented the extract capability for *_ANDX SMB commands, but not for the original SMB_COM_CREATE, SMB_COM_OPEN, SMB_COM_READ and SMB_COM_WRITE commands. Although according to Microsoft these commands are deprecated, we decided to include support for them because wireshark smb dissector supports it and also because that way the plugin can be used in rare but existing old environments. By the way, Paul, we loved the example pdf file extracted from your capture!
Other minor changes
We have also include some minor improvements to the plugin.
The first one is a bit of cleaning in the way that file names are shown. Wireshark uses UTF-8 enconding to show strings in the ExportObjects->SMB window, but SMB uses some flavour of UTF-16. We have ensured that the string passed to that window is encoded in UTF-8 schema, and all non printable characters coming from UTF-16/UNICODE have been transformed into a single '?'. It is not a perfect solution, but it is a bit cleaner.
The last change we added has to do with tree id names and filenames. Until now, when the plugin was not able to find the tree id it just showed TREEID_UNKNOWN or TREEEID_XXX (where XXX was the ID number of the tree). Now, the server IP address has been added to the tree pseudo-name, so that the user doesn't have to dive into the packet trace to find it.
Regarding filenames, we have decided to show the full pathname instead of the basename, because we think that this provides better information.
Coming next
In a few days we will send the patch to wireshark for inclusion in the deveolpment trunk, so we hope it will be publicly available soon. As usual, we will then publish a windows compiled version of wireshark including all this. So stay tuned if you want this feature in your Wireshark!
Posts
