File System Data Structure Search

WinHex & X-Ways

Particularly Thorough File System Data Structure Search

 

Part of volume snapshot refinement. Running a particularly thorough file system data structure search is possibly a lengthy operation, depending on the size of the volume, and for that reason not done automatically when taking the volume snapshot.

 

• FAT12/FAT16/FAT32: Searches for orphaned subdirectories (subdirectories that are no longer referenced by any other directory).

 

• Ext3/Ext4: Similar to the procedure for FAT. Checks the entire volume for previously existing directory structures whose contents are no longer known from corresponding inodes (these would have been looked at as part of the regular volume snapshot already). Such directories are listed with a generic name, usually in "Path unknown", but potentially in the root directory, if that is where they existed previously. (The root directory is special in this situation, as it has an unchangeable ID.)

 

• ReiserFS, Reiser4: Searches for deleted files (which are not included in the standard volume snapshot at all).

 

• UDF: While the first and the last session of multi-session UDF CDs/DVDs will be listed automatically, additional sessions in the middle can be found only with this option.

 

• CDFS: Usually all sessions on a multi-session CD/DVDs are detected automatically. In cases where they are not (e.g. when CDFS co-exists with UDF or if the gaps between the sessions are unusually large), this will detect sessions beyond the first one.

 

• RAM (main memory): May find terminated processes and rootkits.

 

• NTFS: Volume shadow copies can be parsed optionally, with a forensic license. Existing and previously existing volume shadow copy host files are checked for valuable information that would not be available otherwise, such as files that cannot be found in the current $MFT any more or previous versions of files whose contents have changed. Those files will be reconstructed up to 1 GB in length according to the shadow copy. Processing of volume shadow copies, if any, occurs before all the other operations that are part of the particularly thorough file system data structure search (parsing $LogFile, optionally searching for FILE record outside of $MFT and outside of VSC, searching for index records in the slack of INDX buffers). If there are volume shadow copies, the caption of the small progress indicator window will tell you when they are being parsed. Volume shadow copy host files that you exclude before processing will be omitted.

 

Files found in volume shadow copies are specially marked with "SC #" in the Attr. column, or "SC #, prev. version" if they are previous versions of files that were known to the volume snapshot already before the thorough file system data structure search, so that it is easy to filter them in or out. #  stands for the sequential number of the snapshot in which these files were found. Remember you can sort by ID to see the files they are a previous version of next to them. You can also easily navigate to the VSC host by using the command Navigation | Find related file in the directory browser context menu, for example so that in Details mode learn more about that particular snapshot. You could then invoke the same command once more to navigate to the corresponding snapshot properties file, where in Details mode you learn even more, e.g. description and official creation date.

 

You may optionally avoid that previous versions of files in volume shadow copies are added to the volume snapshot if they are exact duplicates (identical file contents) so that it is much easier to focus on files for which actually previous data is still available. Time for that may be well invested because even if modification dates are different, the file contents are often the same for files installed by the operation system. If fully selected, X-Ways Forensics will compare files up to 128 MB, if half selected, only up to 16 MB, as to not waste too much time on this feature.

 

• NTFS: FILE records can be optionally searched everywhere, in sectors that neither belong to the current MFT nor to a volume shadow copy (VSC) processed by the above-mentioned option. Such FILE records can be found e.g. in free space after a partition has been recreated, reformatted, moved, resized, or defragmented. Time consuming on very large partitions.

 

• NTFS: With a forensic license, the current $LogFile as well as old versions of $LogFile found in processed volume shadow copies can be exploited. The contents of deleted files can often be reconstructed thanks to $LogFile. Index records remnants in $LogFile as well as in the slack of INDX buffers can be exploited that either reveal previous names or paths of renamed/moved files/directories that were known to the volume snapshot before or deleted files that the volume snapshot was not aware of before (without file contents, though). You can indicate whether you are interested in earlier names and paths of renamed/moved files and directories or not. If the checkbox for earlier names/paths is half checked, you may find earlier names/paths of renamed/moved files in the Metadata column and don't get additional files in the volume snapshot for each earlier name/path. You can also indicate whether you are interested including traces of files in the volume snapshot whose clusters are unknown and for which only name, size, timestamps and attributes are available.

 

During all the suboperations for NTFS, the inclusion of redundant (identical) files in the volume snapshot is avoided as much as possible. If the only new information gained from old versions of FILE records or index records is previously valid timestamps, no earlier names/paths/contents of files, or if you have indicated that you are not interested in earlier names/paths, then these timestamps are only output as events, depending on the volume snapshot refinement option "Provide by-catch timestamps from various sources as events".

 

• NTFS: You can indicate whether you are interested in getting files included in the volume snapshot whose clusters (and therefore data) are totally unknown, with only metadata (e.g. filename, path, size, attributes, and timestamps), as may be found in index records in INDX buffers or in $LogFile. If checked, all previously existing files of which metadata only is known will be included in a volume snapshot. If not checked, those files will be ignored.

 

• other file systems: no action taken