What’s new in v18.9?

File Format Support

• A generic relevance of files can be estimated. This is a new suboperation of the metadata extraction. This relevance is based on a variety of factors, such as the type of the file, its generator if known (for JPEG and PDF files), its currentness (last modification date), whether it is known from any hash database, the wealth of internal metadata that it contains, its size, the visual content of pictures, whether a PNG file is a smartphone screenshot, whether an HTML file has been locally saved by the user manually, whether there is something unusual about the file, etc. etc. The relevance is not merely content-based, but the result of a fundamental characterization. In particular the generator signature is a provenance-based criterion.The main idea is that if your time for examination is limited, you can start with the files that have the highest generic relevance, to maximize your chance to find what you are looking for, if it exists, and find it rather early. To sort listed files by relevance in descending order, i.e. prioritize them for review, once the relevance has been judged, invoke Navigation | Sort by Relevance in the directory browser context menu. A check mark in the Relevance column that will appear indicates that the relevance of a file was actually computed and taken into account for sorting.
• Generator signatures are now output also for PDF documents. Analogously to JPEG files, this helps to learn something about the origin of PDF files and identify PDF files that likely have the same source as a given PDF file. For example, the generator signature reveals whether a PDF file was generated by a scanner. Around 2,750 PDF generator signatures are defined (as of v18.9), covering approximately 95% of all PDF files. One particularly notable PDF generator signature category is “Reporting/Records”, which identifies documents like bank account statements and invoices. This identification also improves the automatic relevance judgement. PDF generator signatures are now output in the Metadata column, and they are available even for PDF files from which no metadata is extracted (if protected with certain encryption or if double-compressed).
• There is now a user-editable file named “Generator Signatures.txt”, which is similar to the other user-editable text files in X-Ways Forensics. You can edit it to adjust the relevance estimation that is part of metadata extraction. If for example knowing that a JPEG file was generated by a scanner is important for you (because you are a tax fraud or other white collar crime investigator interested in scanned documents), you would make sure that the “JPEG/Scan” group has a high weight (e.g. 9). That’s the number after the tab in the line with the *** group definition. If such a file is of less importance to you (e.g. because the pictures that you have to look for are CP photos), then you reduce the weight of that group (setting it e.g. to 1). You can also edit the individual relevance of each generator in a group on a scale from 0 to 9, where 9 signifies highest relevance. You can also edit the textual descriptions of JPEG and PDF generator signatures in the text file.
• Metadata extraction from PDF files slightly improved.
• Better protection against corrupt PDF files, which can destabilize or totally crash the viewer component in certain situations (logical search or indexing with text decoding, file format specific encryption test, FuzZyDoc). The protection requires metadata extraction. Crash-safe text decoding also prevents crashes of the main X-Ways Forensics process in such cases.
• Support for certain 3-byte escape sequences in certain East Asian ISO-2022 code pages in the text column.
• Ability to find search terms that consist of at least 2 Asian language characters in East Asian ISO-2022 code pages (JIS), even if not directly adjacent to the leading escape sequence.
• Increased stability when processing EDB databases. Events from EDB databases are added to the event list again like in v18.6 and earlier. Some minor improvements for EDB database processing.
• HTML metadata extraction and HTML file type identification improved.
• Events that are adopted into the event list from Windows .evtx event log files now always carry the event ID and record number in the Description column for filtering purposes.
• Events in .evtx event logs can now optionally be adopted completely. Previously, only a subset was processed, the presumably “more important” event types.
• Fixed inability to read the data of embedded files within large compressed files correctly.
• Fixed a rare crash with certain TIFF files.

PhotoDNA/Hash Databases

• When importing PhotoDNA hash values from ProjectVic that have conflicting categorizations in the hash collection file (for example “Child Exploitation” and “non-pertinent” for the same picture), X-Ways Forensics will now assign such hash values to “ProjVic Cat5 – Uncategorized”, except if they are hash values of uninteresting, monochromatic pictures (e.g. all black), then “ProjVic Cat0 – non-pertinent”, or if the two categorizations are the rather severe “Child Exploitation” and “Child Abuse”, then the first categorization will be kept. X-Ways Forensics will also report this in great detail for the first 10 conflicts to give you or the publisher a chance to improve the quality of their hash collection. After 10 conflicts it will become less talkative. In recent ProjectVic data sets you can apparently expect much more than one thousand of conflicting categorizations, so it is important that X-Ways Forensics prevents numerous duplicate entries in the database and in particular misleading categorizations.
• It is now possible to cleanse a PhotoDNA hash database from unwanted hash values. There is a new button for that in the PhotoDNA database management dialog window. The hash values to remove are provided as a plain text file, with 1 hash value in hex ASCII notation per line and “PhotoDNA” in the first line. The specified hash values match exact equivalents contained in the hash database and also small variations (same deviation permitted as set for matching). It may become necessary to cleanse a PhotoDNA hash database if you have imported hash sets from a foreign source whose contents partially do not meet your requirements, which becomes apparent when you get false hits, if you do not wish to remove the entire hash set, or if you have accidentally included a wrong picture in your hash database yourself.
• When creating a PhotoDNA hash set of selected pictures, you may now choose to not add the hash set into the internal database, but create a separate plain text file with PhotoDNA hash values instead. For that, please check the “Save as…” box. Such files can be passed on to other users if they wish to add the specified hash values to their databases or remove them (see above).
• PhotoDNA hash entries can now optionally be classified as notable or irrelevant, or they can remain uncategorized. Uncategorized can be interpreted to mean “not decided yet” or “uncertain”.
• Matches with PhotoDNA now show the related categories in the Hash category column and can be filtered accordingly through this column.
• Hash sets in conventional hash databases (based on MD5, SHA-1, etc.) may now also remain uncategorized. Which could be useful for example for hash sets that are temporarily needed only within a certain case to find certain duplicate files.
• When adding PhotoDNA hash values to the internal PhotoDNA hash database with the Create Hash Set command, you now have the option to store your comments about the selected files in that hash database as descriptions. These descriptions can be automatically adopted as comments again next time when the same pictures are found in another case. They can either replace existing comments in the other case or (if the corresponding check box is half checked) be appended to existing comments. This is very useful for example for police investigators who are required by the court to provide a textual description of each and every child pornography picture, to at least spare them the work of entering descriptions of the same known pictures more than once. Also useful to store information such as known identities of the persons in the photo, previous case numbers etc., for future reference if the same photos are found elsewhere.The descriptions in the hash database can be updated with your comments by simply adding the PhotoDNA hash values of the same files to the internal database again through the Create Hash Set command. When you import a colleague’s internal hash database (by selecting their RHDB file), be sure to have not only the corresponding RHCN file (with the category names) present in the same directory, but also the new subdirectories that contain the descriptions, if any, if you wish to import these descriptions.To delete all internal descriptions, you can simply delete the D* subdirectories of the PhotoDNA hash database directory. Or if you wish to share your database with other users without the descriptions, simply do not include the D* subdirectories. You may also manually delete or update any individual descriptions in the text files in the D* subdirectories at any time. Descriptions that you already have in your database will not get lost if you import hash values of the same pictures again from other sources, except they will be overwritten if that other source is a PhotoDNA hash database of X-Ways Forensics that has descriptions of the same pictures.
• The “Create Hash Set” command has been renamed to “Include in Hash Database” because one of its purposes is now to just update descriptions of PhotoDNA database entries with comments from the volume snapshot.
• X-Ways Investigator now has the ability to manage and fill a PhotoDNA hash database. On the other hand, the functionality to run raw file header signatures within files to find embedded data has been removed.

Performance Enhancements

• Experimental parallelization option for the logical simultaneous search that allows to better utilize multiple processor cores by employing multiple threads. Has an effect only when searching in evidence objects that are images or directories, not disks. The faster your mass storage solution performs, in terms of seek times and data transfer speed, the more time you save percentage-wise. In perfect conditions this can more than double the speed of logical searches. If you select just 1 thread for the logical search, it will work as before. If you select 2 or more threads, searching is done in additional worker threads, and the main thread of the process will be idle, which means the GUI will remain highly responsive. In X-Ways Investigator up to 2 worker threads may be used, in X-Ways Forensics up to 6 (if a suitable number of processor cores was detected).
• Slightly improved handling of huge search hit counts.
• Indexing is now a sparse-aware operation as well, so that it will skip unallocated areas of sparse files in NTFS and other file systems as well as zeroed out disk areas identified as such at the .e01 evidence file level.

Automation

• New command line syntax is now supported in X-Ways Forensics (not X-Ways Investigator) to 1) create a case, 2) add images, and 3) refine the volume snapshot of all added evidence objects. Example:
  exe “NewCase:D:\Cases\My case” “AddImage:Z:\Images\My image.e01” “AddImage:Z:\Images\My other image.dd” RVS:~ auto

The quotation marks are required only for parameters that contain spaces. If no path is specified for the case, it will be created in the default directory for cases. “auto” will make X-Ways Forensics terminate itself at the end.

To refine the volume snapshot (“RVS:~” command), X-Ways Forensics will run the same operations as were applied to a “virgin” (i.e. completely unrefined) volume snapshot last time according to the WinHex.cfg file. If you wish to apply different settings to different kinds of cases, you need to store these settings in separate WinHex.cfg files (in different directories or with different names) and restore the desired one before executing X-Ways Forensics. Also, please note that a few settings are stored in other files, e.g. “X-Tensions.txt” and “Unwanted Metadata.txt”.

• Disk imaging through the command line interface now involves image hash verification (if selected in the user interface before), and the optional descriptive text file contains the so-called Technical Details Report.Those users who are not familiar with this feature please be advised again of the syntax: The first command line parameter should start with a colon and then specify the number of the device in Windows (e.g. “:1” for hard disk No. 1, i.e. the second hard disk). This will cause that device to be opened automatically upon start-up. The second parameter should start with a pipe, followed by either “e01” or “raw” to indicate the preferred image file format, followed by another pipe and the path and filename of the image (e.g. “|e01|G:\Output filename.e01”). In v19.0 it will be possible to also specify an internal description and the examiner name. The third parameter can be “auto” to automatically exit X-Ways Forensics after imaging.
• Ability to hash files, interpreted images and disks in X-Ways Imager. Ability to immediately verify images after creation in X-Ways Imager.

File System Support

• Support for certain new and so far rare XFS variants, with new a Inode version and more timestamps, new directory data structure variants (“local” directory storage)
• Some minor internal improvements in XFS support.
• Fixed an exception error that could occur when parsing Ext4 file systems.
• Now includes filenames and timestamps from certain partially wiped index record in the volume snapshot that were rejected in previous versions due to corruption, as part of the particularly thorough file system data structure search.
• Resolving reparse points in NTFS when finished taking a volume snapshot is faster now in certain Windows installations.
• Improved recognition and representation of BitLocker and BitLocker To Go volumes. Metadata is output in the Technical Details Report: Volume creation timestamp, textual volume description, encryption method, protection type, and volume master key last modification timestamps. BitLocker-related timestamps are also output as events. Improved representation of the encrypted and unencrypted files in the wrapper file system of BitLocker To Go volumes.
• File carving support for English language BitLocker recovery key text files.

X-Tensions API

• Ability to find out via XWF_GetItemInformation whether or not alternative file data is available through XWF_OpenItem if desired, e.g. a thumbnail generated by X-Ways Forensics. Query the flag 0x400000000 (XWF_ITEM_INFO_FLAG_ALTERNATIVE_DATA_AVAILABLE).
• New function XWF_GetMetadataEx. XWF_GetMetadata is now deprecated.
• XWF_GetItemInformation now supports another info type, XWF_ITEM_INFO_PIXELINDEX.
• XT_Init should now return 2 instead of 1 if the X-Tension considers itself thread-safe. If your X-Tension does not identifies itself as thread-safe, that may result in suboptimal performance of future versions of X-Ways Forensics during operations which invoke your X-Tension.
• The X-Tension API function XWF_GetItemType was revised to support the output of the type description of a file.
• The X-Tension API demo DLLs were recompiled, and a demo X-Tension about XWF_GetItemType was added to the Delphi download.

Filters

• Now up to 4 filter expressions are supported for the Metadata, Comments, and Event Description filters. (Previously just 2.) These filter expressions are now stored along with all other filter settings in cases and in .settings files.
• Metadata, Comments, and Event Description filter expressions can now be more flexibly combined with AND and OR. The last combination always has priority. For example “A and B or C” is interpreted as “A and (B or C)”. “A or B and C” is interpreted as “A or (B and C)”.
• Metadata, Comments, and Event Description filter expressions may now start with a colon to indicate NOT at the expression level.
• The Size filter works slightly differently now in that files with an unknown size do not always pass through the filter any more. And you now have the option to focus specifically on files with an unknown size with the condition ≤ -1.

Copying Files

• If you enter a non-existing output path for the Recover/Copy dialog, you will be notified and may now proceed anyway, and that path will be created automatically.
• Recover/Copy: The unique ID can now be inserted not only in the middle of the filename if desired, but also be prepended to it.
• New option in the Recover/Copy dialog window to overwrite files with identical names instead of generating a new unique name as it always happened in previous versions.
• If the option to insert an artificial top directory level in evidence file containers is half selected, that now means that only the the names of partition evidence objects are included that have a physical evidence object as a parent. Useful if the parent evidence object name is very long and redundant to include because you will fill your entire container only with files from that physical evidence object and will reference that object’s name in the container name already.

Miscellaneous

• More information in the About box (which appears when you click the version number on the right-hand side of the menu bar), such as how much free space is available on the drive for temporary files and image files, whether the program is running with administrator rights, whether the MS Visual C++ 2013 Redistributable Package (for the latest version of the viewer component and Dokan) is installed and if not whether at least the MS Visual C++ 2005 Package is installed (for v8.5.2 of the viewer component and older). Useful to check in particular if you are running X-Ways Forensics on a machine that is not your own machine, e.g. a live system that you wish to preview/triage.
• The Notation option “Created > Modified → copied” is now a display and filter setting of the Description column. So the word “copied” has become part of the description. As a frequently asked question is what this option is about, please remember that if the creation date is later than the modification date of a file, that indicates that a file was copied to the place where you see it.
• Option to change the text colors for slack space and uninitialized space in Options | General.
• It is now possible to delete individual history entries of edit boxes, by selecting them from the pop-up menu when the Shift key is held.
• Alternate filenames are now output in HTML format by the Export List function and in the Recover/Copy log just like in the directory browser.
• Slightly revised status representation in the progress indicator window.
• A new directory browser context menu command in the Navigation submenu now allows to conveniently seek the item with a given internal ID, no matter whether file or directory. If a filter prevents listing that item, all filters will be deactivated automatically.
• The key combination Shift+Del can now be used to include listed excluded items.
• Many minor improvements.
• Some minor fixes.
• Program help and user manual updated for v18.9.

Changes of service releases of v18.8

• SR-1: The option “Default to evidence object folders for output” did not have any effect on the Recover/Copy functionality in the original v18.8 release. That was fixed.
• SR-1: The case report option “Copy and link each file only once” counted even previous report outputs if the order of files in the case root window was used. That was fixed.
• SR-1: v18.8 miscounted directories recreated by the Recover/Copy command. That was fixed.
• SR-1: The option to exclude all but one duplicate in each group did not have an effect in all situations in v18.8. That was fixed.
• SR-1: PhotoDNA matching did not have any effect when not computing skin tone percentages at the same time. That was fixed.
• SR-1: Avoids a time-out when loading certain corrupt picture files with the internal graphics viewing library.
• SR-2: The entropy check for fully encrypted files was not applied to all files in v18.8. That was fixed.
• SR-2: In Ext* partitions with very few blocks, the file system was not recognized by an internal plausibility check. That was fixed.
• SR-2: Virtual files generated by X-Ways Forensics v18.8 for examination purposes were potentially output with timestamps of when they were generated. That is now prevented.
• SR-3: Ability to display certain PNG pictures with certain illegal compression with the internal graphics viewing library in the 64-bit edition. Those pictures were previously shown as all black.
• SR-3: Fixed an exception error that could occur when trying to list more than 134 million search hits at the same time.
• SR-3: Ability to import plain text files with 1 PhotoDNA hash value per line in hex ASCII or Base64 no matter whether the last line is followed by another line break or not.
• SR-3: Fixed potential miscounting of child objects that were targeted for inclusion in an evidence file container, leading to an incorrect confirmation message (“x of y files were added to ___.ctr”).
• SR-4: Fixed an exception error that could occur in v18.8 when uncovering embedded data in P7M and VCF files.
• SR-4: The file header signature search option “Output as child objects of existing files if suitable” did not work correctly. It did not check the surroundings of carved files thoroughly enough and occasionally made wrong decisions about whether to present newly added files as child objects. That was fixed.
• SR-4: Fixed an error in Quoted Printed decoding.
• SR-4: X-Tension API: In all releases from today, ProcessItem[Ex] is also called for virtual files such as “Free space” as part of volume snapshot refinement although these files are otherwise largely ignored by that operation.
• SR-5: Fixed missing conversion of search hits in certain code pages to Unicode in the search hit list display.
• SR-5: The “Full path display” option had no effect on items in the root directory. That was fixed.
• SR-5: Previously, when working with multiple open data windows, the category statistics in the Category filter’s pop-up menu may have been shown for another data window after changing the filter settings, not the active data window. That was fixed.
• SR-5: The case report may have been output incompletely under certain circumstances if the option “Position pictures above the text” was not selected. That was fixed. The error occurred if the “successfully saved” confirmation message at the end was absent.
• SR-5: Fixed an exception error that could occur under certain circumstances when analyzing documents with FuzZyDoc.
• SR-6: Fixed incomplete import of large plain-text files with PhotoDNA hash values.
• SR-6: The descriptive imaging text file may have reported a certain number of unreadable sectors when creating a cleansed image although no sectors were unreadable. That was fixed.
• SR-6: Fixed a possible exception error when extracting events from .evt event log files.
• SR-6: Fixed a stability problem that occurred later in the same session after X-Ways Forensics recommended to decode text in HTML and RTF files for indexing due to the presence of non 7-bit ASCII characters, if that message had not been yet suppressed yet with the “Do not show again” option.
• SR-7: Timestamps of files in evidence file containers that were based on an unknown local time zone (e.g. from a FAT file system), not on UTC, were treated as if they were based on UTC. That was fixed.
• SR-7: Prevented an exception error with corrupt (typically carved) jumplists.
• SR-7: Under certain circumstances, files that were classified as irrelevant in a previous volume snapshot refinement run already were touched again by subsequent runs when they should have been omitted. That was fixed.
• SR-7: Fixed exception errors that could occur when starting a logical search in v18.8 under certain circumstances.
• SR-7: The case report option “Position pictures above the text” prevented the output links to non-pictures files from the report. That was fixed.
• SR-7: v8.5.3 of the viewer component hangs with various versions of the NTFS $UpCase file. That file is now no longer sent to the viewer component to generate a non-picture thumbnail for the gallery.
• SR-8: The XML list export did not include the contents of the “Report table” column. That was fixed.
• SR-8: Prevented an exception error that could occur when the case was saved.
• SR-9: GREP syntax: # now has its special meaning even inside square brackets.
• SR-9: Fixed an exception error that could occur with physical search hits on physical media without case association.
• SR-9: Prevented a possible infinite recursion and an exception error when searching for embedded data in carved DLLs.
• SR-10: Fixed the report table independent listing of Unicode search hits in the case report.
• SR-10: Ability to identify more PDF and HTML documents with no extractable text.
• SR-10: Fixed an exception error that could occur in v18.8 when trying to decode text in files of certain types that do not contain extractable text, if the crash-safe decoding option was not selected.
• SR-10: Fixed duplicated output of the case log if output at the same time as the case report.
• SR-10: Prevented an exception error that could occur when searching embedded data in corrupt service_worker files.
• File EDBex.dat in the X-Ways Forensics download replaced. In some previous versions, if something went wrong during EDB database processing, the user had to click away an error message to proceed. This is now avoided.s.