Volume Snapshot Options
These options can be reached via the Directory Browser Options. Most of them take effect when taking a new volume snapshot.
Extended attributes in NTFS are optionally included in the volume snapshot as child objects of the directory or file to which they belong, with the name "$EA" and marked in the Attr. column with "($EA)". Either all such attributes (if the box is fully checked) or only non-resident ones (if half-checked, default). If none at all, the clusters that belong to non-resident extended attributes of existing objects will be covered by the virtual file "misc non-resident attributes" as before. Background information: Microsoft uses extended attributes on system binaries as part of the secure boot components. Attackers have been using large extended attributes to hide malware in some high profile cases. Large extended attributes are flagged automatically by report table associations.
Including logged utility streams (LUS) in NTFS in newly taken volume snapshots is optional. Either all LUS can be included (if fully checked) or only non-$EFS LUS (if half checked) or no LUS at all. Useful for NTFS volumes written by Windows Vista, if you are not interested in $TXF_DATA LUS.
Downloaded files in NTFS can be conveniently recognized if their alternative data stream "Zone.Identifier" is represented as a report table association instead of as a child object in the volume snapshot. That means you do not need to navigate to the child object to find out what the child object might be. "ZoneId=3" as the name of the report table identifies files downloaded from the Internet.
By default, allocated clusters in FAT12, FAT16, FAT32, and exFAT file systems are skipped when reading the data of deleted files. That means that data of deleted files is not necessarily assumed to be contiguous, but assumed to occupy as many free clusters from the start cluster number as are necessary to accommodate the known file size, while skipping clusters that are marked as in use by existing files. If the end of the volume is reached that way, the next free clusters are taken from the start of the volume, replicating the built-in logic of typical FAT32 file system drivers to rotate through the volume on the search for allocatable clusters. This option retroactively changes the assumption about the storage location of files that are already contained in the volume snapshot, thus changing this option will also cause hash values to change if they are re-computed.
If you get read errors on a CD/DVD (e.g. because of scratches on the surface) when the volume snapshot is taken, you know that not all sectors with the data structures of the file system are readable. Listing the ISO9660 file system's directory tree on CDs in addition to a possibly also existing Joliet file system can be useful because that means a second chance to get all directories and files listed, if the corresponding data structures of the same directories are located in readable sectors in the ISO9660 area.
Parsing the journal in Ext3/Ext4 file systems when taking a volume snapshot is optional.
Extended attributes in HFS+ are now optionally included in the volume snapshot as child objects of the files or directories to which they belong (in X-Ways Forensics only) depending on a 3-state check box. If fully checked, extended attributes are presented as child objects even when they have been specially interpreted already by X-Ways Forensics internally. If half checked (default setting in X-Ways Forensics), they are presented as child objects only if they are not specially interpreted by X-Ways Forensics assuming that the user might want to check them out manually.
For better results when matching hash values against special hash sets, only the invariable header of loaded modules can be listed in main memory analysis.
There is an option for incremental snapshot completion when dealing with OS directory listings as evidence objects (when you add a directory to your case). If selected, the volume snapshot initially just contains the contents of the top-level directory, and it is further completed only on demand, step-by-step when you manually explore subdirectories. This is exactly how the Windows Explorer/File Explorer in Windows works, and useful when dealing with slow and huge network drives that would take a long time up front to scan completely. But it's very different from the usual approach in X-Ways Forensics, and will obviously prevent you from getting a complete listing of all files when exploring recursively, simply because there is no guarantee that all files have been included in the volume snapshot yet until you have explored all subdirectories. If at any time you decide that you wish to include the contents of a certain directory in the volume snapshot recursively, you can use the "Expand all" command in the context menu of the Case Data window (right-clicking that directory) or unselect the option to complete the volume snapshot on demand and then explore that directory. Please remember that the most convenient way to expand an entire subtree is by clicking its root and pressing the multiplication key on the numeric keypad (standard feature in Windows).
Evidence file containers of v18.8 and later specifically remember the volume snapshot refinement (RVS) status of the files that they contain, e.g. whether still images have been captured already from a video or whether embedded data already has been uncovered from a file. If you choose to accept and trust this status, these files will not be processed again if you decide to refine the volume snapshot of the container. You may occasionally not want to accept the RVS status of files in containers, to avoid missing something, if you suspect that the original examiner did not apply as thorough settings as you would or that they may have used an older, less capable version of X-Ways Forensics to process the files. Adopting the RVS status is also a must to get videos within a container represented in the gallery with rotating captured still images.
-------------
Inherit deleted state: Causes deleted partitions to pass on their deleted state to everything that they contain (files and directories), and deleted e-mail archives to pass on their deleted state to all the e-mails, directories and attachments that they contain. This may seem logical, but results in a loss of information, as depending on the reference everything may be listed as deleted, even files/e-mails that from the point of the file system/the e-mail archive still existed when the partition/file was deleted. By default, this option is not selected, so that X-Ways Forensics distinguishes between existing and deleted files and e-mails etc. even in deleted partitions/deleted e-mail archives, so that more information is retained.
Net free space computation: Allows you to work with an adjusted virtual free space file that is net of clusters that were identified as belonging to previously existing files, to minimize the amount of space in file systems that is read twice for logical searches and indexing. After changing this option or after discovery of more previously existing files, the virtual free space file is updated when it is opened next time, for example selected in File mode or when it is that file's turn during a logical search. Relative offsets of search hits in this virtual file may become wrong when it changes (for example when some more clusters are allocated to more identified previously existing files, so that the net free space file becomes smaller), so they cannot be used to navigate to the search hits in File mode. Only physical offsets of search hits, usable in Partition/Volume mode, are guaranteed to remain valid. The virtual free space will be frozen and not change any more once it has been indexed, or once it gets child objects, i.e. usually files that have been carved within it manually in File mode, because those depend on unchanged relative offsets within the virtual free space file.
Optionally, files on the logical drive letters A: through Z: can be opened from within the directory browser with the help of the operating system instead of with the built-in logic at the sector level. Please note that this is forensically sound only for write-protected media. On writeable media, Microsoft Windows may update (i.e. alter, falsify) the last access timestamp of files you open. The benefit, however, is that access to such files will be noticeably faster in many situations, especially on slow media such as CDs and DVDs, e.g. when you compute hashes or skin color percentages for files in a volume snapshot, because Microsoft Windows employs read-ahead mechanisms and entertains a file caching system. Another benefit is that files opened with the help of the operating system are editable in WinHex. Limitation: Files on multi-sessions CDs and DVDs cannot be read that way.
Known uninitialized portions at the end of a file in certain file systems that remember such conditions (valid data length < logical file size) can optionally be read as binary zeroes instead of as whatever data is stored in the allocated clusters. This mimics the behavior of Windows when ordinary applications open files through the operating system instead of reading the contents of the file directly from the sectors in the volume. Useful for example to achieve hash compatibility with such applications. This option notably does not apply to read operations for logical searches, so that logical searches remain forensically thorough and clusters allocated to uninitialized portions of files are still searched. This option has an immediate effect even on already opened files, for the next internal read operation.
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. just filename and path and/or timestamps), in Ext*, XFS, Reiser* and NTFS. If fully checked, all previously existing files of which metadata only is known will be included in a volume snapshot. If not checked at all, those files will be ignored. If half checked, only files for which more than just the name or timestamps are known will be included, but not directory entry remnants in Ext* or Reiser file systems.
Quick snapshots without cluster allocation speeds up taking a volume snapshot (in particular for the file systems Ext2, Ext3 and ReiserFS, and in particular also when the volume snapshot files are created across a slow USB 1.1 interface or network), however, causes WinHex to lose its ability to tell each sectors and clusters allocation (for which file it is used). You may use the command "Take New Volume Snapshot" of the Tools menu to update the view of a volume, e.g. after unchecking this option.
With the option Keep volume snapshots between sessions enabled, all information on file systems in opened volumes collected by WinHex (Disk Tools menu and/or Specialist menu) remains in the folder for temporary files even when WinHex terminates. WinHex can then reuse the snapshots in later sessions. Volume snapshots of evidence objects in a case are always kept, regardless of this setting, in that evidence object's metadata subdirectory.
Keep more data of the volume snapshot in memory, e.g. for much quicker sorting by timestamps.