What’s new in X-Ways Forensics v21.0?
User Interface
The case tree now visibly tracks the mouse pointer position and highlights the node corresponding to the mouse position, similar to the directory browser.
The case tree now also supports full row reactivity, meaning you can click anywhere to the left or right of a node for the desired response, so that you do not have to aim so precisely any more. The supported actions are left-clicking to select and explore, middle-clicking to tag or untag, right-clicking to explore recursively, and double-clicking to expand or collapse subdirectories or partitions.
Improved understandability of the user interface in various areas.
Ability to access the column header functionality solely with the keyboard, without using the mouse, by pressing Ctrl+H (H for header), to activate or deactivate filters and to select columns as sort criteria.
If you store and load directory browser settings in cases, the current DPI settings are now stored along with the column widths, so that those column widths can be automatically adjusted proportionally when opening the same cases in Windows systems with different DPI settings. (Only in newly created cases of v21.0. Releases of v20.6 and later from Oct 27, 2023 can still load the directory browser settings from such cases, but will ignore the DPI settings.)
Improved ability to abort previewing or viewing large files with the viewer component, by moving the mouse cursor in the lower right corner of the viewer window, when a notice appears there to make you aware of this option.
The auto update function was improved (the ability to update, with a single mouse click, the picture shown by the graphics display library in a separate window).
When running multiple instances (sessions, processes) of WinHex/X-Ways Forensics at the same time on the same machine, those instances are now numbered starting with 1 instead of 0. The instance number can now not only be seen in the so-called About box (the box that pops up when clicking the version number in the upper right corner), but for additional instances also in the caption of the main window, so that it’s easier to tell them apart in the Windows Task Bar and the Windows Task Switcher. That depends on a new checkbox in the General Options dialog window. Note that if you end earlier instances and then start new ones, the new instances will re-use slots with instance numbers starting with 1.
If the new check box to better distinguish between sessions fully checked, different instances can have their own background colors, which currently is not compatible with dark mode.
A few function/command icons were revised. More icons were added in various areas of the graphical user interface.
The directory browser can now show file archives with a dedicated archive icon or the regular blue icon with a superimposed capital A, depending on the settings in the directory browser options.
The option to mark pictures in the gallery as already viewed now extends to pictures that are displayed by the viewer component, not the internal graphics display library. This affects for example JPEG 2000, DXF, WMF, and EMF files.
Revised visual marking of check boxes with user tooltips.
An optional special simplified RVS+search dialog window was introduced in the triage user interface of X-Ways Investigator (option +104 in investigator.ini).
The legacy option to omit previously existing files when adding selected files to a hash set was removed.
Fixed a graphical glitch in certain list boxes at high DPI settings.
Timestamp Analysis
The timestamp filter can now optionally combine the conditions for the various timestamp types (creation, modification, …) with a logical AND instead of the default OR.
There are two different types of AND combinations for timestamp filters. A strict AND combination (fully checked) requires that all targeted timestamps are actually present/available. A soft AND combination (half checked) requires only all available timestamps to meet the filter condition (and at least one must be available).
The event timestamp filter and the general timestamp filter are now fully independent of each other, so that it’s possible to filter for example for events after July 2022 in files that were created before March 2017.
The timestamp filter now allows to focus on NTFS 0x10 timestamps that look like significantly backdated compared to their their 0x30 counterparts, and also on creation timestamps from the file system that are earlier than content creation timestamps from the internal file metadata. You can define a threshold in milliseconds, seconds, minutes, hours, days, weeks, months or years that makes such timestamp discrepancies relevant to you, i.e. you can require that the main creation timestamp is that much older than the corresponding 0x30 timestamp or the content creation timestamp. If you compare UTC-based creation timestamps from the file system to content created timestamps that were recorded in an unknown local time zone (e.g. in PNG files), you could take into account how many hours difference could be attributed merely to this base effect. To assist you, the UTC creation timestamp is rendered more comparable to a local content creation timestamp by adjusting it to display time zone. Please note that backdating most often occurs automatically, for various reasons (e.g. file archive extraction or setup programs), and is not necessarily the result of intervention by a suspect or by malware activity with malicious intent. If you are interested in potential manual interventions by a suspect, it could be useful to employ the file type filter at the same time and focus on file types for which timestamps could make a difference in your case e.g. documents.
All NTFS 0x10 timestamp cells now show a backdating icon if they predate their corresponding 0x30 counterparts (the columns with the superscript 2 in the header) by more than the threshold that is defined in the timestamp filter dialog window. Creation timestamp cells show such an icon also if they predate the “Content created” timestamp, if any such timestamp exists and was extracted. The arithmetic difference between the two timestamps that are compared is displayed after the icon, rounded to milliseconds, seconds, minutes, hours, days, weeks, months or years.
The general timestamp filter now has an “All” setting that allows to focus on files with any value for the selected timestamp types, for example to combine that with the Backdating condition or simply to focus on files that have a timestamp of the select timestamp type(s) at all.
Cases and Evidence Objects
When adding a single archive file to the case as an evidence object (using the Add File menu command or via drag & drop), that archive will be explored immediately and only its contents will be presented in the directory browser, not the archive file itself, just like when adding an image or an evidence file container to the case. That works for all supported archive subtypes whose contents you have X-Ways Forensics include in a volume snapshot when refining it. Spanned/segmented Zip and 7z archives in 7-Zip and WinZip styles are also supported, just please make sure that you add the first segment to the case, which in case of 7-Zip style is the segment named .001 and in WinZip style the one named .z01. For password-protected (encrypted) Zip, 7z and Rar archives you will be prompted for the password. The password can be saved in the case so that you do not need to enter it again when re-opening such an evidence object.
Ability to hash (and after that verify) ordinary files and archive files that are evidence objects, using the “Hash/verify evidence objects” command.
In newly created cases, the two internal subdirectories for evidence objects that are directories or single files now get shorter names, which no longer include the original paths of those directories or single files. The uniqueness of the subdirectory names is now ensured in the same way as for images (should multiple directories or single files with the same names be added to the same case). The new naming conventions are also understood by v20.8 from SR-6 and v20.9 from SR-5.
If the user tries to open an evidence object that is a single file or a directory, and if that file or directory does not exist any more in its original path, X-Ways Forensics now conveniently offers the user to either provide the new path or to open the evidence object anyway without the underlying data (loading only the volume snapshot).
For convenience, no longer requires the user repeatedly to select evidence objects for processing (volume snapshot refinements, logical searches, index searches, case report, …) or confirm the selection while the same case is open and no new evidence objects are added.
Volume Snapshot Refinement
The picture content analysis functionality is now also available when volume snapshot refinement is applied to selected files.
Discarding results of picture analysis and processing (by unchecking the “already done” box) now removes labels for identified photo content.
The maximum number of worker threads in X-Ways Forensics (not X-Ways Investigator) has been increased from 16 to 24 (subject to availability of processor cores).
A previously existing file whose first cluster was reallocated according to the file system (shown as “1st cluster not available”) can now be processed by volume snapshot refinement if you uncheck a new checkbox that by default causes them to be omitted. That means in particular that unrelated random data that does not belong to the file can now be hashed and presented as that file’s hash value although it most certainly was not that file’s hash value. Previously X-Ways Forensics would have only budged and processed such a file if it was specifically targeted via tagging or selecting. If X-Ways Forensics is forced to compute them, hashes of nonsensical data are displayed in the directory browser in gray color, to remind the user that they should not be overinterpreted or expected to be found on other storage devices.
Volume snapshot refinement now refuses to run on evidence objects that were opened without their data sources (without the storage device, image, directory, …) because that does not make sense.
Ability to compute and store MD5 hash values of half the regular length (“folded”, i.e. first half xor’ed with the second half, yielding 64 bits), as an economical compromise between CRC32 (32 bit) and regular MD5 hashes (128 bits), to bridge the gap between the two and save memory and/or drive space, for example for deduplication purposes.
Ability to compute EDRM MIH hash values for extracted e-mail messages and original .eml and .emlx files (if the contain complete headers), to search for e-mails with a known MIH value, for database matching, or for deduplication purposes. If an MIH is assigned to an .eml file in a volume snapshot and the .eml file was extracted from an .msg file, the same MIH will automatically be assigned to the parent .msg file as well. Two copies of the same e-mail message may have different regular hash values, but the same MIH, for example if the file format is different (raw .eml file vs. OLE2 MSG file) or if body format and/or content are stored differently. If EDRM MIH is selected as the hash type, but no MIH can be computed because the targeted file is not an e-mail message of a supported type, the hash value cell remains blank. As a compromise, you can choose MD5/MIH as the hash type, where an MIH is computed if possible, or an MD5 hash value if not, so that all hashable files get a hash value usable for deduplication or matching. MIH is an eDiscovery standard, and was described as a “groundbreaking solution” by a leading supplier.
Search Functionality
Regular expressions now support \u Unicode values within square brackets, i.e. within sets of characters.
The search term window now has an option in its context menu to thin out potentially very long lists of search terms by excluding non-responsive ones (search terms that never yielded any search hits). That is not guaranteed to work with search terms in case files written by older versions.
Right-clicking in the search term window no longer makes you lose a selection of multiple search terms.
File Type Support
The internal graphics display library was updated.
The generating “software class” reported in Details mode was revised. There are now two more classes: scanner and web site builder. Examples of the latter include WIX, JIMDO, Site123, Squarespace, and Shopify.
Another change in the Summary Table in Details mode is the new entry “propensity score”. It can assume values from 1 to 99. The relevance computation is mainly based on that value. That value is an objective statistical probability for the picture having additional, removable, relevant metadata. It could also be also be designated as documentality, the quality of being able to serve as a document. One can check this additional information for its consistency. The propensity score generally exists for raster images (that are measured in pixes), in particular also for the formats PNG and WEBP.
A new internal label was introduced for Avatar/Identicon JPEG pictures. Such identicons are often smaller versions of avatars and exist on Tiktok, Twitter, Facebook, Instagram, Youtube, Quora, Gravatar, Pinterest and elsewhere.
The recognition of generating device was updated as always. Among other improvements, recognition of iPhone 15 as a generating device has been added.
Support for previews of a newer version of jump lists (.automaticdestinations-ms files).
Details mode now points out the presence of JUMBF metadata blocks in JPEG files, a voluntary marker of computer (AI) generated pictures
System Tools
A new command in Tools | File Tools submenu allows to take control of all the files in a directory that you select (in the currently active Windows system). It gives all users full access, recursively. Requires administrator rights.
The OS-Wide Write Protection function was slightly revised. When applied to a volume on an MBR-partitioned storage device, the user is now offered to target all volumes on that device instead because the protection cannot be enabled for just a single volume in that case.
Templates and Scripts
Ability to use variable names with spaces in them (if enclosed in round brackets) in formulas in templates.
Ability to define constants in templates, with a name, an integer type and a value of your choice, and use those constants in calculations. If the name contains a space, it needs to be enclosed in quotation marks. The value can be a formula and may depend on other constants or variables that are already defined at the time when the constant is defined. Constants are listed in the template window along with variables. Example:
const int16 100 “My constant”
const int16 (“My constant”*10) “My other constant”
goto (“My other constant”*5)
This will change the current position of template interpretation to offset 5000.
Ability to use internal predefined constants named Bytes_per_sector and Bytes_per_cluster in formulas, in templates that are applied to storage devices or interpreted images or partitions/volumes.
Another new predefined constant is Bytes_per_record. It depends on the record size defined in View | Record Presentation, if active. If that display option is not active, on partitions/volumes with an Ext2/Ext3/Ext4, XFS or UFS file system it is the inode size, or in NTFS file systems the FILE record size.
Another new predefined constant is Base_offset. That’s the offset in the active data window that the template was applied to by the user, which may change when navigating to adjacent records.
The keyword multiple in a template definition may now appear in the body. When used there, it must be accompanied by a parameter that provides the amount of data covered by the template in bytes, and may be a formula and (unlike in the header) may use constants or other variables. This allows to navigate to adjacent records to the left and to the right. If that amount of data is not explicitly defined in the body, i.e. the multiple keyword is used only in the header without parameter, then the amount is deducted indirectly based on the current read position at the end of template interpretation like in previous versions, and may be considered variable in length if variables in the template have a variable size, in which case no navigation to the left is possible.
The legacy WinHex script command UseLogFile was revised. It now has an effect on more messages that are output, and the resulting log file is now Unicode-capable (UTF-8).
Miscellaneous
Files created with the File | New command can now be optionally held in memory instead of in a temporary file, for performance or storage quota or security reasons. If the checkbox is fully checked, that means the user insists on memory storage and the menu command fails if not enough memory is available (or not enough contiguous memory address space in case of the 32-bit edition). The same setting applies when pasting data from the clipboard into a new file via Edit | Clipboard Data | Paste Into New File. The Info Pane will show the buffer address in the memory address space instead of a path for the newly created file. Please note that the data you are handling could still be written to disk by Windows for example as part of pagefile.sys. Also, if your goal is to avoid disk I/O and the usage of temporary files, you may want to disable file backups for the Undo function, in Options | Undo.
When printing selected files along with direct child objects, excluded and filtered out child objects are now omitted.
The NSRL RDS hash sets, in a format for import into X-Ways Forensics, have been updated to release 2023.12.1, and are available for download from the resource directory in both MD5 and SHA-1 versions as always.
The downloadable Tesseract package has been updated with the latest version in October. It includes updated WebP support with a fix of a potential heap buffer overflow.
For those who were wondering: The two vulnerabilities that were identified in the WinRAR software in August do not affect X-Ways Forensics even though X-Ways Forensics can decompress RAR archives.
The program help and the user manual were updated.
Many minor improvements.