X-Ways Forensics, X-Ways Investigator, WinHex 20.6 released

Are you interested in this product?

1300 55 33 24


Request a Call back

X-Ways Forensics: Integrated Computer Forensics Software Version 20.6

X-Ways Forensics is an advanced work environment for computer forensic examiners and our flagship product. Runs under Windows XP/2003/Vista/2008/7/8/8.1/2012/10/2016/2019/11*, 32 Bit/64 Bit, standard/PE/FE.

Picture Analysis

  • The pixel filter dialog window was redesigned for improved understanding of how it works.

  • There is now a small button on the right-hand side of the “Picture analysis and processing” dialog window. Clicking that button will show user interface controls for usage of PhotoDNA and Excire PhotoAI, even if the functionality is unavailable, to give you an idea of how these modules can be used. PhotoDNA is provided for free to users in law enforcement agencies. Excire PhotoAI is commercially available and described here: https://www.x-ways.net/excire.html.

  • Ability to analyze pictures in HEIC format with Excire PhotoAI.

  • Ability to choose the minimum resolution of pictures that should be analyzed with Excire PhotoAI. The previous minimum was 224×224 pixels. If you are interested only in high quality digital photos, you can save time by increasing this minimum a lot. If you are also interested in low resolution photos, including thumbnails (for example because you think thumbnails are sometimes all you can find of incriminating photos), you can use a lower minimum. The absolute minimum accepted is 48×48 pixels, but it is not recommended to go much lower than 80×80 as detection errors will be more frequent if the picture quality is very bad.

  • Pictures can now be automatically categorized as irrelevant or notable using Excire PhotoAI. In the extensive hierarchy of identifiable objects you can select individual objects or entire subtrees that render a picture irrelevant from your point of view, such as any kinds of animals, plants, sports, musical instruments etc. Automatically categorizing pictures as irrelevant based on detected image content is subject to two extra conditions: A certain minimum confidence and a certain minimum resolution in KP.

  • To reduce the number of report tables associations generated using Excire PhotoAI, within irrelevant subtrees you can choose to not output findings at a lower level. If for example the subtree “Animal” is marked as irrelevant, then if a photos shows an identifiable butterfly, you won’t get the report tables “Butterfly” and “Insect”, but only “Animal”. (Optionally you can get to see in the Comment column which exact animal was identified.)

  • You can define what renders a picture notable for you, such as nudity (“act”), vehicles, children, text etc. “Notable” always overrides “irrelevant” when in doubt, if for example dogs are marked as important in a particular case, but animals in general are still marked as irrelevant. The next release of Excire PhotoAI might add detection of guns, powdery substances, pills and pornography.

  • Logical AND combinations are supported when categorizing photos as notable based on content detected by Excire PhotoAI. To add a new AND combination, you select the first object name, click the AND button, then select the second object name, and click the AND button again. If you have misclicked, exit the dialog window via Cancel OR simply remove the checkmark in front of your accidental AND combination so that it will not be remembered when you click OK. Two AND combinations are predefined in fresh installations that are meant to assist in searches for child pornography. You can combine any items in the tree, not only those from the bottom-most level that are represented by file icons. Irrelevant and notable detections are defined in these two text files: “Excire Irrelevant.txt” and “Excire Notable.txt”.

  • Option to conveniently access the keyword list of Excire PhotoAI and see the translation of internal object names to friendly designations in English, German, Spanish, Italian or French (depending on the current user interface language), by clicking the Edit button in the categorization window for Excire. For example, photos identified as act photography can be described as “nudity” instead of “act”, if you simply change the word after the comma. You may need to restart X-Ways Forensics to see the effect.


Picture Display

  • The internal graphics display library was updated.

  • Better support for some PNG pictures with transparency.

  • Changed the way thumbnails are created for the case report, for file types supported by the internal graphics display library. Among other file types this affects Photoshop PSD, which apparently cannot be properly rendered by the 64-bit edition of the viewer component, but by the internal graphics display library.

  • Applying Exif orientation metadata in Preview mode, for the View command, in the gallery, for OCR and for Excire PhotoAI was partially revised and is now optional and controlled by a 3-state checkbox. If fully checked, the Exif orientation is strictly applied. If half checked (the previous behavior and still the default), it is not applied if X-Ways Forensics thinks it is most likely correct to not (further) rotate or flip the picture.

  • Improved Exif orientation compliance in the gallery. In particular, thumbnails and low-resolution alternatives embedded in JPEG files now inherit the Exif orientation from their parent files.

Metadata Extraction

  • The relevance scale for PNG files is now comparable to that of JPEG files, so that sorting files of both types by relevance gives a more plausible result now.

  • The compression level of PNG files is now output in the internal metadata in Details mode. It also affects the relevance computation. The conditions “trailing data” and “incomplete” (also in Details mode) are new for PNG files.

  • Fixed a problem with false detection of a scanner as the generating device of PNG files.

  • If the IFD GPS field in Exif metadata is available, but empty, or if it contains unvalid coordinates, this is an irregular situation, different from the IFD GPS not being present at all, and often means that the GPS data have been removed retroactively. It is now reflected as “GPS format: NaN”, where NaN means “not a number”.

  • Fixed a rare situation in which a geolocation was not output previously.

  • Generator signature concept for JPEG pictures revised. The number of error rates was reduced to less than 0.1%, by avoiding hash collisions (one signature matching two devices). This may be noticeable when dealing with Samsung Galaxy devices.

  • The Summary table in Details mode for JPEG files now specifies the confidence with which the generating device type was identified.

  • Users may now specify a minimum confidence in % that they require for the identification of generating devices of JPEG and PNG pictures.

  • Mention of AMPF (presumably for “Apple Multi Picture Format”) in the JFIF header in Details mode.

Directory Browser

  • Improved readability of tooltips of cells in the directory browser that represent very long text without line breaks, e.g. comments.

  • The number of characters extracted from a file (be it via text decoding or OCR) is now shown in the Description column (if the box “other” is checked in the Notation options of the Description column), and with the filter you can require a certain minimum number of characters (like 5 or 10, 255 at most), for example to avoid pictures in which a few characters have been recognized merely erroneously, i.e. pictures that not actually do contain text.

  • Directory browser option to display the start offset of the data of a file in the First Sector column instead of the number of the first sector. This is more precise information and available for most files. The title of the column will be changed accordingly in most places of the user interface. The offset can optionally be made a physical offset (from the point of view of the physical disk/image if shown in a partition) just like the sector number can be made a physical sector number. The filter of that column expects numbers of the same meaning as shown in the directory browser (i.e. either offsets or sectors, either logical or physical), and in the same notation (decimal for sector numbers, decimal or hexadecimal for offsets).

  • The directory browser context menu command “Find duplicates in list” can now also identify duplicates based on exact identical start offsets instead of just identical start sectors if the “First sector” column is populated with offsets.

  • The Hash Category column, which shows which files are considered irrelevant or notable, has been renamed “Categorization”. Hash database matching is just one method to populate this column. Files can also be designated as irrelevant or notable by X-Tensions, by adopting data from evidence file containers, and now in v20.6 also simply using the directory browser context menu.

  • The former “Category” column is now named “Type Category”, analogous to “Type Status” and “Type Description”.


  • You can now rename any directory browser column to your liking, for example in order to keep continuity in the user interface between earlier and future versions, or for compatibility in data transfers (e.g. Export List command), or because a certain column title has not been translated to your preferred Latin-based user interface language and you would like to see your own translation of the English title, or because you prefer to see “Attributes” instead of the abbreviation “Attr.”, etc. In the dialog window with the directory browser options you can simply right-click a column title for that, and will then be given the opportunity to replace the title with your own wording.

  • In fact many more text fragments (strings) in the user interface are now customizable, through this menu command: Help | Setup | UI Text Adjustments. You would need to identify the exact standard text fragment to replace and provide your own version of it. If the text that you are looking for is not found and you don’t know exactly how it is stored internally, you can search for it in the file “language.dat”. Your customizations are stored in the file “UI Text Adjustments.txt” and can be shared with other users. The file can presumably be used in future versions as well, as long as the original text fragments remain the same. It simply consists of one adjustment per line, with the original text first and the replacement second, delimited by a tab character (meaning those few original texts that already contain a tab character cannot be adjusted). You may also edit that file manually. Please note that the translations of non-Latin languages are available as simple text files and can thus be changed in those files much more directly.

  • Ability to automatically resume certain operations after a crash (an involuntary program termination), without any user intervention. This is a new setting in Options | Security. The currently supported operations are the stages “file header signature search” and “processing of individual files” of volume snapshot refinement when invoked from the main menu or the command line or by adding evidence objects to a case. Following a crash, these operations will be resumed at a point that depends on when the volume snapshot was last saved. (That in turn depends on the auto-save interval in the case properties because whenever the case is saved, the volume snapshots of all open evidence objects are saved as well. You can also save the case manually while volume snapshots are being refined.) If it is not clear which particular file has triggered a crash because you were running the operation with additional threads, then the operation will be resumed first with no additional threads. With some luck, that will not trigger the crash again. If it does, the operation is resumed once more. Once the exact file is identified, it will be skipped automatically. In case of a crash during the file header signature search, the sector that triggered the creation of a problematic file will be skipped.

  • Only in Preview and Beta releases, you can simulate crashes if you wish to observe, test, or demonstrate this new automatic work-around, for example because you wish to benefit from it when running X-Ways Forensics more or less automatically with command line parameters, and need to react to the situation where one instance of X-Ways Forensics disappears and is immediately replaced by another instance that you didn’t start yourself. For the simulation, you provide the name of a file that you want to trigger a crash in the supported operations. The filename should be rather unique and target ideally just one file that you know is in the initial volume snapshot or that you expect to be added to the refined volume snapshot. It’s case-sensitive. Note that if you have X-Ways Forensics assign names based on incrementing numbers to carved files, and you make it simulate a crash with a carved file whose name is expected to be 012345.jpg, then even if X-Ways Forensics successfully learns to avoid the sector where that file is found in the file header signature search, the next carved file after that might be named 012345.jpg as well (depending on the file type), triggering yet another crash. Unique names of carved files are those derived from the intelligent naming option (like “Canon DIGITAL IXUS 950 IS 2007-07-01 12:01:46.jpg” or from the option to name files based on start sectors. To simulate a random, non-repeatable crash, you can simply terminate X-Ways Forensics with the Windows Task Manager. v20.6 Beta 5 will remain available for a few weeks in case you need this feature.

  • The “Uncover embedded data in various file types” functionality now takes extra precautions not to produce duplicates of files that were already carved by the file header signature search. More precisely, its output will replace corresponding carved files in the volume snapshot. The internal IDs of the carved files will remain the same, but additional metadata may become available (such as path/representation as a child object of the parent file, presumed original filename, more correct file size etc.). With the usual settings, this affects a considerable number of sector-aligned files, from example in the Chrome browser cache.

  • Makes a note in the report of how report table items are sorted.

  • Reminds users of the paths where hash databases are stored when managing those hash databases.

  • The more complex version of the dialog window that allows you to manage report tables and report table association now also has a button to remove associations with the selected report tables.

User Interface

  • Ability to create two copies of an image files when imaging from the command line. The path of the second copy, if desired, may be appended after the path of the first copy, delimited by a forward slash. Example: “|e01|Z:\First Copy.e01/V:\Second Copy.e01|Image description|Examiner name”.

  • RVS:~ in the command line refines the volume snapshots of all evidence objects of a case, while RVS:~+ now refines the volume snapshots of only newly added evidence objects (added since the case was opened).

  • The user interface now shows improved instructions for the reconstruction of certain Linux MD RAID variants.

  • The settings of the file header signature search are now accessible from within the refine volume snapshot dialog window via a “…” button, just like all the other subsettings, and like most of them are usually now shown only on demand.

File Type Support

  • New option to accelerate various operations such as volume snapshot refinement, logical searches, and especially the optional dynamic context preview rendering around search hits in the search hit list, by keeping more decompressed contents of file archives in the volume snapshot cache. This option can be found in Options | Volume Snapshot. It generally accelerates opening files in archives again after the first time, especially nested archives.

    The volume snapshot cache could become very large that way. It can be discarded optionally whenever closing the data window if you like (useful if you are done dealing with that evidence object for the moment, or done with the entire case), and that is a case-specific setting in the case properties. Once discarded, files can get cached again afterwards at any time if/when they are opened again, if the option for that is active. If the box for caching is half checked, that means only nested archives are cached, similar to how compressed TAR archives were in previous versions.

  • Clicking files in non-nested archives of the type zip in the directory browser in Partition/Volume mode now causes jumps directly to the respective zip record. More precisely to the filename part of that record, to make the contained file better distinguishable from its parent (also in terms of the 1st sector/Offset column). The actual start of the record is already sufficiently highlighted by the automatic signature recognition.


  • Now filters out leading white spaces resulting from OCR text recognition.

  • A new option in Options | Viewer Programs makes X-Ways Forensics ignore OCR-derived text if it does not contain at least x contiguous useful characters. Such OCR results will not be stored/output/copied/indexed/searched. This is beneficial if you apply OCR to unknown/random/ordinary pictures (i.e. not known textual data), to reduce the number of files that later will (misleadingly) respond to the Description filter for files with OCR-derived text or for which child objects are (unnecessarily) created by the “Copy: Extracted Text” function etc. A “useful” character is defined here as a character with an ASCII/Unicode value of 0x30 or higher. That means whitespaces <=0x20 are not counted, and neither are the printable characters !=#$%&'()*+,-.& (0x21-0x2F range) because some of them are occasionally misdetected in random pixels. All real letters in any language count, and so do numbers (“0” through “9”).

  • Logical searches remember if OCR was applied to pictures unsuccessfully (meaning with no resulting text) so that subsequent searches with OCR enabled will quickly skip those files.

  • Warns users about spaces at the end of search terms (e.g. resulting from copy & paste).

File System Support

  • Improved representation of HFS+ file systems with redundant inactive catalog entries.

  • HFS+: Duplicate entries in the Catalog (one inactive and one active) for the same file or directory (same ID, same name) are apparently created under Linux, under certain circumstances. In newly taken volume snapshots now usually only the active one will be included.

  • HFS+: If an inactive Catalog entry and an active entry was found for the same directory (same ID, same name) and both were included in the volume snapshot, in newly taken volume snapshots the content of that directory will be shown for the existing directory, and not randomly in one of the two.

  • Option to restrict the search for NTFS FILE records (part of the particularly thorough file system data structure search) to the currently defined block. (If no block is defined, the search will be carried out in all sectors of the volume as usually.)

  • The kind of data structure to be found at the designated file system offset is now printed right in the “File system offset” column, for files and directories in NTFS.

  • Option to define a fallback code page for Ext* file systems in the case properties, or even enforce a non-standard code page, by half-checking or fully checking the box next to the second case-specific code page in the case properties. That code page will be used to decode filenames and directory names that are not encoded in UTF-8 (the Linux default), which may be the case in some legacy systems, or other purpose-built environments where encodings other than UTF-8 were specified.


  • The “Event Log Events.txt” config file now accepts a line beginning (1st column position) with a semicolon to signify a comment line. Obviously this can be used either to remove lines from parsing or to add comments to particular sections. The configuration file now accepts an optional fourth column that can be used to add a plain text comment to the Event’s Description column.

  • “Event Log Events.txt” now contains some explanations as comments and has an example of a comment that is taken over into the event description in the event list.

  • Exporting and importing selected report tables to/from text files now include the descriptions in addition to just the report table names.

  • The list of sectors to omit during the file header signature search can now comprise 16 sector numbers per evidence object instead of just 8.

  • Option to automatically categorize FuzZyDoc matching documents as notable.

  • Unicode filename support in the “Wipe Securely” function.

  • X-Tension API: The XWF_OutputMessage() function now accepts the flag 0x8, which directs the message to the Output window, as opposited to the Messages window, where users may want to select and copy text and where no [XT] prefix is inserted to distinguish between internal messages and messages from X-Tensions.

  • The program help and the user manual were updated.

  • Many minor improvements.

Changes of service releases of 20.5

SR-1 SR-2 SR-3 SR-4
The table of generating devices was updated. Improved Unicode support for EVTX processing. Fixed sorting partitions by size in the directory browser. Some minor improvements and fixes.
 Some new video generator signatures. Originally WofCompressed files in evidence file containers could not be opened for reading. That was fixed. The alternative e-mail preview did not present Date and Recipient fields in some rare cases. That was fixed.
Some more format variants added for the device type “Video publishing”. Fixed unintended dependency of the alternative e-mail presentation in the case report on the setting in Options | Viewer Programs. Fixed occasional inability to preview compressed Prefetch files in v20.5.
Structure types are now computed for the file types XLS, WEBP, and WAV. The definitions in “Event Log Events.txt” were not applied completely when processing .evtx event logs since v20.4 SR-6. That was fixed. Fixed a user interface error that could occur in some installations in v20.5 SR-2.
More formats supported for filename analysis. The particularly thorough file system data structure search in NTFS now skips some volume areas that could only result in unnecessary duplicate findings, and grouping orphaned files now always happens in virtual directories that have a connection to the root directory via the virtual “Path unknown” directory. The directory browser context menu command to copy extracted text to various output channels had encoding issues with some settings. That was fixed.
Keyboard shortcut assignments in the report table association dialog did not always work in v20.5. That was fixed. Fixed some report table management functions for the new optional report table listing in alphabetical order.
Clarified supported file types in online Excire product description. Clarified supported file types for face definitions in marker-help.txt in the Excire package. Face marking now accepts supported picture files with any filename extension or without filename extension.