SMB Documentation

The SMB Work Flow of pcapFS

With this wiki entry, we want to document how pcapFS handles SMB traffic internally. We give a detailed explanation of the whole SMB "work flow" of pcapFS and highlight assumptions made on the way as well as SMB scenarios where pcapFS has its weaknesses.

Overview

The functionality of pcapFS regarding SMB currently includes multiple things:

1. The creation of SMB control files (one SMB control file per underlying TCP connection) which contain information about all transferred SMB messages. SMB control files can be displayed by setting the option --show-metadata.
2. The creation of so-called SMB files. These are the server-side files which have been accessed during a captured SMB connection. These files have either been accessed directly by SMB2_CREATE/SMB2_READ/SMB2_WRITE messages or we know from the context that the respective file(s) exist, e.g. through conducted search queries (SMB2_QUERY_DIRECTORY and SMB2_QUERY_INFO messages).
3. SMB share reconstruction with file versions. Knowing these SMB files, pcapFS reconstructs, as far as possible, the known parts of the server-side directory hierarchy. For files accessed via Read/Write, the created SMB files are populated with the content read/written while also considering different file versions. Files, for which only metadata (file name, timestamps, file size) is known, are created as empty SMB files and are displayed when the option --show-metadata is set.
4. Displaying the state of the reconstructed SMB share at a specified point in time. This can be done using the --snapshot option.
5. Equipping the SMB files with different kinds of timestamps. Using the option --timestamp-mode, the SMB files can be seen w.r.t. the time of the SMB shares or w.r.t. the network time. These time dimensions can differ when there is a time discrepancy between the recording device and SMB shares.

Details about how everything works is given in the further course. Let's start with a quick overview over the SMB-related source code files with their respective responsibilities:

• smbcontrol.cpp/smbcontrol.h are responsible for creating SMB control files which protocol all transferred SMB messages.
• smb_packet.cpp/smb_packet.h are responsible for parsing SMB packets. One SMB packet consists of one SMB header and one SMB message body.
• smb_messages.h parses the SMB message body of an SMB packet w.r.t. the message type.
• smb_structs.h and smb_constants.h define structs, enums, response codes etc. needed for parsing and memorizing relevant SMB-related information.
• smb_utils.cpp/smb_utils.h contain functions frequently needed for handling SMB traffic.
• serverfile.cpp/serverfile.h define a super-class for virtual files representing server-side files which are accessed via protocols like SMB, FTP, etc.
• smb.cpp/smb.h inherit from the ServerFile super-class and represent server-side files ("real" files and directories) accessed via SMB.
• smb_manager.cpp/smb_manager.h is the connecting piece between the parts responsible for parsing SMB traffic and SMB files. It memorizes and manages per SMB server endpoint all server files as well as all SMB-related mappings that are needed to be kept in mind. The SmbManager inherits from an abstract ServerFileManager, which provides an interface for manager classes that need to be implemented when reconstructing network shares (For instance, for reconstructing the server-side directory structure for FTP files, a separate FtpManager is implemented)

SMB Parsing

Here, we give a detailed explanation of the SMB parsing process. The parsing is designed on the basis of Microsoft's documentation of SMB version 2 and 3, so you need to be somehow familiar with that.

There are multiple ways of how SMB traffic is embedded in network packets. SMB can be realized on top of raw TCP, NetBIOS over TCP, QUIC and RDMA. PcapFS currently only supports SMB over TCP and SMB over NetBIOS over TCP. When such communication is detected, smbcontrol.cpp initiates the parsing of the "SMB packets" contained in the respective TCP payload. One SMB packet consists of one SMB header and one SMB message body.

Depending on the SMB version, different SMB headers are used and can be distinguished by different magic numbers. PcapFS focuses on SMB packets containing the SMB2 Header which is the standard header for SMB version 2 and 3. When the SMB2 header is detected, the whole SMB message body is parsed in a detailed manner. The main SMB-related functionality of pcapFS - especially regarding SMB files - is built upon information extracted from packets containing this header. For all other header types, the only information extracted from them is, if possible, the message type (which is then documented in the resp. control file). In the further course, we assume to have packets with an SMB2 header.

SMB packets can be chained together. By this, multiple SMB packets can be embedded in the payload of one TCP packet. Offsets into the virtual TCP files differ for chained and unchained packets. Therefore, we need to carefully consider chained packets and distinguish chained packets which are the last part of a chain from other chained packets. This is done by taking the chainOffset field and related operations flag of the SMB2 header into account.

For parsing the message bodies of SMB packets, pcapFS provides one dedicated class for almost each message type. These classes represent the respective messages and enable easy access of information contained in the message which is needed to provide more information about the message in the control file as well as for creating and updating SMB files. Parsing may fail if the message or field sizes are not correct, the structureSize field does not equal the obligated documented value or the SMB message type is unknown. Then, a generic SmbMessage class is instantiated and no further information is extracted. One special message type is the Error Response which is sent by an SMB server when an error occurs during handling the client's request message. PcapFS identifies an Error Response Message by detecting a structureSize value of 9 and a non-zero status code in the SMB2 packet header.

For each SMB message body, its message length is calculated. This needs to be done for the case that the respective SMB packets are chained in order to calculate the correct offsets. When they are not chained, the size field from the NBSS header can be taken.

When detecting an SMB2_READ response, SMB2_WRITE response, SMB2_QUERY_DIRECTORY response, SMB2_QUERY_INFO response, SMB2_SET_INFO response or SMB2_CLOSE response, the SMB manager is invoked for updating the state of SMB files according to the message. This is explained in the corresponding section below.

But before that, we need to look closer at relevant information - especially mappings - that is needed to be kept in mind. Some information is required to be managed per SMB connection and other stuff globally for all SMB connections to the same SMB server.

What is managed per SMB connection?

When parsing SMB packets, pcapFS manages one smbContext structure per SMB connection. smbContext stores information which needs to be memorized along one SMB connection. This includes among other things:

• a reference to the underlying virtual TCP file
• the current offset within the TCP file
• information, that must be retained between requests and responses for SMB2_CREATE, SMB2_CLOSE, SMB2_READ, SMB2_WRITE, SMB2_QUERY_DIRECTORY, SMB2_QUERY_INFO and SMB2_TREE_CONNECT messages (file name, fileId, fileInfoClass, ...)
• timestamp information (see below for more infos regarding this)

What is globally managed?

The SMB manager is - besides managing SMB files - also responsible for managing mappings which need to be maintained globally because they pertain all connections to the same SMB server, or all connections to the same tree of the same SMB server. Such a tree is identified by the ServerEndpointTree struct which consists of the SMB server's IP address and port as well as the respective tree name. Per ServerEndpoint (tree-independent), the following mapping is memorized:

• treeId-treename mapping: Each SMB server can have multiple separate directory trees which are identified by the treeId field of the SMB2 header. So, the treeId indicates which directory tree the respective SMB message refers to. The name of a tree corresponds to the name of its root directory (This is also the root directory of the directory tree which is derived by pcapFS containing the known SMB files which are located there). The treeId-treename mapping is extracted from SMB2_TREE_CONNECT requests and responses. Because of that, the tree name cannot be determined for a given treeId if the corresponding SMB2_TREE_CONNECT request and response haven't been recorded. When this is the case and the corresponding SMB message accesses a file which is to be created as an SMB file by pcapFS, we cannot determine to which tree it belongs, i.e., in which derived directory tree to put it. This results in the creation of a derived tree with the generic tree name "treeId_x" with x being the treeId number. The respective accessed file is then inserted there. The treeId-treename mappings are resolved even before the actual detailed SMB parsing is done. For resolving, all freshly created TCP files are skimmed right at the beginning. This needs to be done because the SMB connections are later parsed connection-wise and in scenarios with simultaneous, accesses to the same tree, some mappings might otherwise be determined too late.

Per ServerEndpointTree the following mappings are memorized by the SMB manager:

• fileId-filename mapping: Each server-side file is addressed using its fileId instead of its file name. The usual procedure for the client to interact with a server-side file, is that at first, the file needs to be opened. For that the client sends an SMB2_CREATE request containing the file name. The server responds with a newly created fileId (file handle) corresponding to the file which is valid until the file is closed with the SMB2_CLOSE message. Having the fileId, the client does whatever they want to to with the file (obtain metadata information, read, write, ...). The fileId-filename mapping is memorized globally because the same fileId can be used over multiple connections to the same ServerEndpointTree, i.e., it is possible that in one connection, the fileId is obtained by an SMB2_CREATE response and in another simultaneous connection to the same tree, this fileId is used. Similarly to the treeId-treename mapping, the fileId-filename mappings are obtained before the actual SMB connections are parsed in detail. For that, pcapFS skims through all TCP files in advance.
• filename-FilePtr mapping: By this mapping, the derived server-side files (SMB files) are managed. The FilePtr is a pointer to a virtual ServerFile (this can also be a directory) which later becomes a real file in the resulting server-side directory hierarchy derived by pcapFS. More to that in the subsequent section.

Management of SMB Files

Now that we roughly know how pcapFS handles SMB parsing and which information needs to be memorized at which abstraction layer, it remains to be explained how SMB files are extracted and how the server-side directory hierarchies are derived. All of that is handled by the SmbManager. Currently, SMB files are created/updated via eight different SMB message types, SMB2_TREE_CONNECT response, SMB2_CREATE response, SMB2_READ response, SMB2_WRITE response, SMB2_QUERY_INFO response, SMB2_QUERY_DIRECTORY response, SMB2_SET_INFO response and SMB2_CLOSE response. As previously explained, SMB2_TREE_CONNECT and SMB2_CREATE, are handled separately right at the beginning, before the actual detailed packet parsing process begins (in order to resolve mappings early enough). The other mentioned message types are handled during main parsing. When one of these message types is detected, the SMB manager takes over right after the message is parsed. Depending on the different file content/metadata contained in the message, different file properties are set or updated. When the SMB manager encounters a message regarding a file, which is priorly unknown for the respective tree, a new SmbFile is created and its metadata is set according to the information contained in the respective SMB message. SmbFile is a specialized ServerFile for SMB. The difference of a ServerFile from other virtual files is that it contains more timestamps and a pointer to its parent directory which is also a ServerFile. So, starting from an SmbFile, a cascade of parent directory pointers can be built up until the root directory of the corresponding tree (whose name is obtained by the treeId-treename mapping) is reached. By that, pcapFS can easily build up the respective directory hierarchy at the mount point. For each newly created SmbFile, its parent directories can be determined because the file name for the SmbFile (as it has to be derived from the fileId-filename mapping) luckily always includes its absolute path beginning with the first subdirectory of the corresponding tree (There is one exception when handling SMB2_QUERY_DIRECTORY responses, look below for further info).

Let's look closer at what pcapFS does for each of the mentioned message types.

SMB2_TREE_CONNECT Response

Apart from saving the treeId-treename mappings, as explained above, if not already present, an SMB file is created that represents the root directory of the corresponding tree.

SMB2_CREATE Response

First of all, the fileId-filename mapping of the file requested via the SMB2_CREATE message is updated for the tree it belongs to. When the file is not yet present as an SMB file in the filename-FilePtr mapping, a new SmbFile is created and its metadata is initialized with the file information contained in the SMB2_CREATE response (namely timestamps, file size and the information whether it is a directory or not). In order to set the pointer to the file's parent directory, pcapFS iterates backwards through the file's absolute path and recursively creates SMB files for all parent directories which are not yet represented by an SmbFile instance. If the file requested via the SMB2_CREATE message is already present as an SMB file in the filename-FilePtr mapping, the list of timestamps, that the SMB file comprises, is updated. Details about timestamp handling are explained further below.

SMB2_READ and SMB2_WRITE Response

These two message types are responsible for reading from server-side files or writing to them. Through them, we are able to actually fill our SMB files with content. Both message types are handled similarly. Each time a new SMB2_READ/SMB2_WRITE request-response pair with a read-/write-offset of zero is encountered for a file, a new SMB file version is created. The internal management of the different file versions per SMB file is explained in the corresponding section below. Possible redundant successive file versions containing the same content are deduplicated later on. When the read-/write-offset equals the current file size, i.e. new data is appended to the file, no new file version is created. Instead, the current file version is updated.

SMB2_QUERY_DIRECTORY Response

In contrast to the other two message types, SMB2_QUERY_DIRECTORY responses can contain information for multiple files, i.e., all files in the current directory which match the search pattern specified in the SMB2_QUERY_DIRECTORYrequest. The file info classes which are relevant for pcapFS are:

• FileDirectoryInformation,
• FileFullDirectoryInformation,
• FileIdFullDirectoryInformation,
• FileBothDirectoryInformation,
• FileIdBothDirectoryInformation,
• FileIdExtdDirectoryInformation.

They contain timestamps, filename and relevant file attributes for every matching file of the requested directory. The directory is addressed using its fileId. For creating/updating the SMB files corresponding to the files listed in the SMB2_QUERY_DIRECTORY response, we need to know (the absolute path of) the directory name. This is no issue when the fileId-filename mapping for that directory is already known. However, pcapFS needs to tackle somehow the case that the name for the fileId is not known. This case might not occur very often because before a SMB2_QUERY_DIRECTORY request, the corresponding directory has to be accessed via SMB2_CREATE and, with every SMB2_CREATE response, the respective fileId-filename mapping for that directory gets memorized. But, it can happen that the SMB2_CREATE request and SMB2_QUERY_DIRECTORY request for the same directory are chained together. Then, the client specifies the fileId 0xfffff...f in the SMB2_QUERY_DIRECTORY request, indicating that they refer to the directory accessed via the SMB2_CREATE request right before. Then, only looking at the SMB2_QUERY_DIRECTORY messages, pcapFS does not know the name of the requested directory (since the fileId fffff...f doesn't resolve to a known file name). Thus, pcapFS takes the name specified in the last SMB2_CREATE request as directory name. Then, pcapFS is able to assemble the absolute path for every file listed in the SMB2_QUERY_DIRECTORY response and can create/update the corresponding SmbFile instances. If the name specified in the last SMB2_CREATE request is not available (i.e., it is empty), pcapFS puts the respective SMB files into the root directory of the current tree. This is done because it is common for SMB to have SMB2_CREATE messages with empty file name when it is referred to the root directory.

SMB2_QUERY_INFO Response

The detection of an SMB2_QUERY_INFO response initiates SMB file creations/changes only if the underlying query info type is SMB2_0_INFO_FILE and the file info class is FileAllInformation, FileBasicInformation or FileNetworkOpenInformation. All other info types/classes don't contain (enough) needed file information. Like SMB2_QUERY_DIRECTORY, SMB2_QUERY_INFO messages address files via their fileIds. Hence, the fileId-filename mapping for the requested file needs to be known in advance for all file info classes except for FileAllInformation which also contains the file name. So, when the fileId-filename mapping is not known for the requested file's fileId and we have a FileAllInformation info class, pcapFS is still able to establish that mapping through the file name contained in FileAllInformation.

SMB2_SET_INFO Response

PcapFS updates the SMB file's timestamp list if the operation was successful and the corresponding set info request contains FileBasicInformation.

SMB2_CLOSE Response

PcapFS updates the SMB file's timestamp list if the operation was successful and SMB2_CLOSE_FLAG_POSTQUERY_ATTRIB is set to true. This indicates that the close response contains timestamps.

Management of SMB File Versions

Each SMB file (more precisely, every ServerFile) contains a map of file version entries. The identifier for each file version entry is a custom struct consisting of three different timestamps, which are explained in the timestamp handling section. Each file version is represented by a structure containing the following information:

• fragments indicating where the content for that file version is located in the underlying TCP file.
• the client IPs of the SMB clients that accessed this file version. This needs to be memorized for the corner case, that accesses to the same directory tree from different clients have been recorded and the --sortby option contains clientIP.
• an indication whether the file version corresponds to a read or write operation. This information is required for smartly choosing the correct SMB file timestamp later, also in specific corner cases.
• a set of timestamp triples that represent the points in time when the file version has been accessed (The previously introduced timestamp triple, which is the identifier of a file version entry, always corresponds to the oldest file version access). This needs to be memorized for setting correct timestamps, especially when the option --snapshot is set.

When the SMB Manager handles read/write messages and a new file version needs to be saved, a new file version entry is created in the internal map of the SMB file. At this point, it doesn't matter whether the content of the newly created version is identical to the previous one; this is handled later, when identical successive file versions are deduplicated.

Deduplication is done at the end when all virtual files have been created. During this phase, successive file versions are compared for identical content. When two versions have the same content, the newer file version is retained and the metadata from the old version is copied over. The state of the resulting SMB files is the one that is later saved in the index file. By that, depending on the pcapFS options (--snapshot, --snip, --timestamp-mode, --show-metadata), the corresponding SMB file version(s) and timestamps can be dynamically set during the directory hierarchy creation.

Timestamp Handling

Before explaining, how the reconstructed SMB shares are created, it's important to understand, how pcapFS manages SMB file timestamps. Usually, the timestamps, that pcapFS sets for virtual files, are network timestamps that correspond to the point in time when the network packets containing the file content have been recorded. However, for SMB files, a different approach is used.

Because the goal is to reconstruct SMB shares as accurate as possible, the default behavior is that SMB files are equipped with the corresponding file system timestamps that were present in the SMB share. These file system timestamps are communicated via SMB messages (and thus can be tracked by pcapFS) and are CreationTime, LastAccessTime, LastWriteTime and ChangeTime. These timestamps are passed to FUSE as follows:

• CreationTime is ignored, because as of now, birth time is not supported by libfuse
• LastAccessTime is mapped to the file's access time
• LastWriteTime is mapped to the file's modify time
• ChangeTime is mapped to the file's change time

Usaually, during an SMB2_READ operation, LastAccessTime is updated, and during an SMB2_WRITE operation, LastWriteTime and ChangeTime are updated. However unfortunately, the actual timestamp updating and communication is rather unreliable and can be inconsistent, as in some cases, timestamps may not be updated as expected.

To mitigate this, pcapFS adopts a hybrid approach by default, taking the communicated file system timestamps into account and updating them intelligently when they have not been updated by SMB. Users can also instruct pcapFS to not follow this hybrid approach and to take the communicated filesystem timestamps as is or to set network timestamps, as it is done for the other virtual files. This behavior is controlled via the --timestamp-mode option, where the user can choose fs (for file system timestamps), network or hybrid. However, using these different timestamp modes requires sophisticated timestamp management by pcapFS, especially when used in combination with the --snip or --snapshot options. How pcapFS does this, is now explained.

Generally, three different sets of timestamps are managed for SMB files:

• network timestamps: These are individual timestamps that correspond to the time of the network packet containing the SMB file content.
• fs timestamps: These are sets of each four timestamps (CreationTime, LastAccessTime, LastWriteTime, ChangeTime). They are the file system timestamps that are part of some recorded SMB messages.
• hybrid timestamps: These are also sets of the four timestamps, but they are updated by pcapFS based on observed read/write operations. Hybrid timestamps reflect the time dimension of the SMB share more accurately.

The extraction of network timestamps and fs timestamps is straightforward. Hybrid timestamps are set when a new sequence of read/write messages is processed by the SMB manager. In order to set a hybrid timestamp correctly, pcapFS first determines the reference timestamp, which is the hybrid or fs timestamp that is both older than and closest to the SMB share time. The SMB share time corresponds to the fs time of the read/write message. In most cases, this corresponding SMB share time is identical to the network time but there can also be a time discrepancy (e.g. when the SMB server hangs back in time). In order to determine, whether there is a time discrepancy between the network time and fs time, pcapfs parses the SMB2_NEGOTIATE response of the SMB connection. Part of the SMB2_NEGOTIATE response is the SMB server's system time at that moment. Hence, the time skew is the difference between the server's system time and the network time of the SMB2_NEGOTIATE message. Having determined the time skew, it can be added to the network timestamp of the read/write message in order to calculate the corresponding SMB share time. This SMB share time is the upper bound of the reference timestamp candidates. Having determined the nearest reference timestamp, a new hybrid timestamp is created which comprises the reference timestamp with updated LastAccessTime or updated LastWriteTime and ChangeTime (depending on whether it is a read or write operation). The updated value set is the SMB share time corresponding to the network time of the read/write message, which has been determined before through the skew.

When --timestamp-mode=fs is set, there is a special case for SMB files, that are modified with SMB2_WRITE messages but are either not accessed afterwards or read afterwards but only after another file content modification happened. Then, pcapFS can't determine the fs timestamp for the file version corresponding to the write operation because it hasn't been communicated. In such cases, pcapFS sets all timestamps for that file version to zero. For read operations this issue doesn't arise because we always have a matching fs timestamp from the preceding SMB2_CREATE response. For write operations, that modify the file content however, we can't use the fs timestamps of the preceding SMB2_CREATE response because they are slightly too old and the overall write operation could have taken some time.

When --timestamp-mode=hybrid is set, pcapFS chooses a timestamp for each SMB file (or file version) by considering both hybrid and file system timestamps. Fs timestamps are also candidates because they could be better suited (e.g., newer or closer to the specified snapshot time) than a hybrid timestamp.

When the --snapshot option is used, i.e. the state of the reconstructed SMB share(s) at a specific point in time is to be displayed (and not all file versions), the timestamp, that is passed to --snapshot, is interpreted w.r.t. the specified time stamp mode. For instance, with --timestamp-mode=fs, the snapshot time point is interpreted as file system time. In order to make that happen, each SMB file version is saved with a set of time triples consisting of the hybrid, fs and network time of file accesses for the corresponding version. The allowed range for snapshot time points is only constrained for network timestamp mode. There, only points in time, that are in the range of the capture file recording, are allowed. For the other timestamp modes, snapshot time points before the start of recording are also allowed in order to display earlier stages of the SMB share(s) (even though the reconstruction is most probably very incomplete). In contrast to --snapshot, the timestamp(s) passed to --snip are not interpreted w.r.t. the timestamp mode, they are always seen as network timestamps. This is because --snip is a global option of pcapFS (not limited to SMB) and directly refers to the capture file(s).

Creation of derived server-side directory hierarchies

Before creating the actual reconstructed SMB shares, pcapFS decides which timestamps to set as well as whether - and if so, which - file versions are to be displayed. This can be different depending on the options --snapshot, --timestamp-mode and --snip.

In the default case (--snapshot is not set), a separate SMB file is created for each file version. When --snip is specified, then only those file versions are considered, that contain a saved file access with a network timestamp inside the snip interval. There is a special case where the oldest recorded read/write access of an SMB file is newer than the upper bound of snip (This means that no memorized access fits into the snip interval), but we have a saved file timestamp, that fits into the interval. Then, pcapFS knows that the SMB file still has been accessed during the snip time period (but not through a read/write) and the file is displayed as a metadata file with empty content (because we know the file has been accessed, but its content has not been read/written in that time interval).

When --snapshot is set, then, for each SMB file, only the file version is displayed, that corresponds to the specified snapshot time (interpreted w.r.t. the timestamp mode). For each SMB file, the latest file version accessed before the snapshot time is selected. When additionally --snip is specified, the network time of the respective access has to be inside the snip interval. Also here are multiple edge cases. For instance, if the SMB file has been read/written but only after the snapshot time, the first access after the snapshot time is SMB2_WRITE and there are memorized timestamps, which are older than the snapshot time, then we know that the file existed but don't certainly know its file content to that time. In that case, the SMB file is displayed as empty metadata file.

After taking all such things into account and creating the SMB file version(s), the directory trees are built. Knowing the absolute path for every SMB file through the cascade of parent directory pointers, it is pretty easy to derive the resulting directory hierarchies for all SMB server endpoint trees and incorporate them into the directory layout. For that, pcapFS reverses the cascade of parent directory pointers for every SMB file and then inserts each resulting tree into the mount point's subdirectory, where the underlying SMB connection satisfies the --sortby property for the directory.

Memorizing SMB file hierarchies in the index file

PcapFS typically stories all important meta data information about each derived virtual file (especially offsets into and identifier for the underlying (virtual) file) in an index file. This has the advantage that for the next time pcapFS is to be executed with the same capture file(s), the index file can be passed to pcapFS by what the capture file(s) don't need to be parsed once more. Instead, the virtual directory hierarchy can be constructed directly by using the information saved in the index file.

In order to reconstruct SMB files by reading out of an index file, more information needs to be saved than for other virtual files. The additional timestamps and the information, whether the SMB file is a directory, can be directly put into the index file. For memorizing a reference to the parent directory, which is also an SMB file, each parent directory has a unique representative Id. Instead of a FilePtr object which can't be really saved in the index file, the parent directory is saved as its Id. By that, the parent directory file pointer can be reconstructed correctly for each SMB file after all virtual files are created by reading out of the index file. In general, SMB files are memorized in the form they have before the concrete file versions are created at separate SMB files. This allows us to set differing options (--snapshot, --snip, --timestamp-mode) while using the index file with -i.

Summary of SMB-related issues

• When SMB files are located in a tree and the SMB2_TREE_CONNECT request/response for that tree is not captured, the respective tree name (aka the tree's root directory name) is set to "treeId_x" where x is the treeId number. For multiple captured connections to the same tree, this can lead to redundancies of the same files being saved in different derived directory trees (with different tree names according to their treeIds).

• When sorting the virtual directory hierarchy w.r.t. the source port of TCP connections (--sortby=srcPort), it can be the case that not all of the SMB files, which are accessed in the TCP connection, are displayed in the corresponding port folders. This can happen when having multiple simultaneous connections accessing the same files. Then, e.g., for the case that we have 2 of those connections, the respective SMB files are displayed only in one of the corresponding port folders, not both.

• One limitation is that fragmented updates of SMB files are not incorporated. This means, for instance, when a file of length 100 bytes (that is part of the SMB share) is first fully read but then only the first 50 bytes are overwritten using SMB2_WRITE, this results in a second reconstructed file version which only consists of the 50 bytes written. In most cases, when a file is modified with SMB2_WRITE, the full length of the updated file is sent via SMB2_WRITE, beginning at file offset 0 and ending at the file's length (also when only a small part of the file is modified). But it can also be the case that SMB optimizes this step and only communicates the modified file fragment. This leads to file fragments, which are seen as entire versions. However, this only happens, if the updating SMB2_WRITE message writes to file offset 0.