WinHex & X-Ways Forensics Newsletter Archive

This mailing is to announce the availability of version 21.8, with official release date May 25, 2026.

License owners please go to https://www.x-ways.net/winhex/license.html as always for the latest download instructions including the latest log-in credentials (!), details about their licenses, and upgrade or renewal offers. Please do not ask us for the download password. Your organization has access to it already if eligible, as described.

Service releases are announced in the Announcement section of the forum, and you can subscribe to instant e-mail notifications of postings in that section if you have a forum profile. You can create such a profile here (if you have our log-in credentials). If you wish or need to stick with an older version for a while, please switch to the latest service release of that version.

Upcoming Training Events

Please sign up for our training notifications here if you would like to be kept posted on future training dates.

What's new in X‑Ways Forensics 21.8?
(where applicable, changes also affect X‑Ways Investigator, WinHex, and X‑Ways Imager)

File Format Support

• Carving algorithm significantly improved for certain MPEG video variants.

• File carving support for AVIF files.

• No longer includes extra Exif Makernote data in the thumbnail child object of JPEG files whose embedded data is uncovered, to achieve more universally usable hash values for such child objects.

• Alternative extraction method for attachments encoded in .eml files.

• Completely revised parsing of .evtx Windows event log files and more complete output of event data to the event list. More stable with corrupt .evtx files.

• Recognizes DocuRay-processed document files as encrypted/DRM-protected.

• Identifies hardlinks and symlinks in TAR archives as such. Hardlinks are presented with the original file contents and the hardlink count within the archive.

• That certain binary files are included in the case report in a readable format if possible is now optional. This affects for example .job files, .lnk, prefetch files, $I*, $LogFile, $UsnJrnl:$J, wtmp, utmp, btmp, TCP and UDP packets, and many more. If binary copies are preferred that cannot be viewed in the browser along with the report, the new box for this can be unchecked.

• Tentatively identifies RTF files that contain embedded pictures, using a label ("No pictures extracted").

Picture Support

• Ability of the internal graphics display library and the picture content analyis to load pictures from AVIF files.

• HEIC display support completely revised.

• PNG and JPEG support updated in the internal graphics display library.

• Improved detection of AI-generated pictures through various micropatterns. You can check the software class row in the summary table in Details mode for an assessment. If it does not say "AI-generated", the device class/type "No device" could also raise suspicion, as should Annotation No. 201 if it is output.

• Updated picture generating device detection.

• Improved picture size+ information in the Summary table in Details mode (called sensor size or paper size in previous versions), with textual descriptions of the resolution, output of the aspect ratio if worth pointing out, and potentially a known previous resolution if a picture was resized. An arrow up indicates an unexpectedly high propensity score. An arrow down indicates an unexpectedly low propensity score, which is correlated with reduced-resolution copies for dissemination and a lower generic relevance. "Picture size" is now marked there with a tiny + symbol to set it apart from the directory browser column of the same name.

• A new entry called “Media design” in the Summary table for several picture file types, already introduced in v21.7, is meant to aid the assessment of a picture's aspect ratio. There are about 128 aspect ratios that represent a statistically significant variant. All other aspect ratios are labeled "Random". Particularly common aspect ratios, like e.g. 4:3, which are used by camera sensors, are labeled "Native". The group of "Framed" media designs are further distinguished as "Framed", "Square", "Scaled", "Social media" or "Featured". The latter refers to the "Open Graph" standard introduced by Google, which identifies pictures that are meant to represent a website as a whole. Media design information can be used to assess the overall consistency: A picture with a processing state labeled "Original" should always have a media design labeled "Native". A modified picture would expect a "Framed" variety, while "Featured" or "Social media" correlates with the processing state of "Disseminated". If no other tangible context exists, the media design could still be used for a general assessment.

• Improved interpretation of picture aspect ratios in v21.8.

Evidence Object Support

• For a while already, UFDR reports can be added as evidence objects just like normal Zip archives, and the file report.xml in .ufdr archives is presented as a virtual file because it contains metadata for the examination and is not an original file. It can optionally be parsed to present all the other files in the archive with their original timestamps and in their original paths whenever possible. In v21.8, the timestamps that the other files have according to the Zip archive records can now optionally be discarded altogether if you find them too unreliable/misleading.

• If report.xml interpretation is fully selected instead of just half, X-Ways Forensics can now also extract messages and present them as events. Messages of the following types are usually supported:
  Instant Messages: Android CallLog database
  Instant Messages: Android
  Chats: Kik Messenger
  Instant Messages: Phone
  Chats: Native Messages
  Chats: Kik Messenger
  Chats: Snapchat

• More detailed feedback on report.xml parsing in case of problems.

• Ability to store decoded document text and OCR-derived text in evidence file containers. This allows recipients of such containers to run fast logical searches in the included files without spending time on text decoding and OCR, if they are using v21.7 SR-3 or later.

• Ability to continue filling encrypted container archives. (The user needs to enter the same password again.)

File System Support

• Ability to detect an exFAT file system in a partition and immediately work with it even if the boot sector was overwritten, as long as the backup boot sector is available.

• A template for exFAT boot sectors is now included.

• The directory tree depth at which an error in the file system will be presumed and at which recursion will be aborted when taking a volume snapshot of FAT* or Ext* file systems can now be defined in the Volume Snapshot Options, and helps to avoid stack overflow errors, which would otherwise occur in some very rare cases. If this situation occurs, a message will be output: "Probably circular link detected. Recursion depth ...".

• Improved ability to cope with a certain type of NTFS file system manipulation.

• Broader recognition of BitLocker recovery key files, which are identified as "blkey" in the Type column.

• Recovery keys that were encountered in any evidence object in the case already are automatically used to decrypt BitLocker partitions that you open if they fit.

• A new security option controls whether BitLockers passwords and keys that you enter manually or that are found automatically (BEK and recovery key files) or that match when trying out passwords from a list are centrally stored in the case (on disk). That is convenient and the default setting, but perhaps not desirable for internal investigations if the case directory itself is not protected/encrypted.

User Interface

• More granular setting for what action should be triggered when double-clicking files with child objects (explore or view).

• The first 4-state check box in X-Ways Forensics (or maybe in the universe) has been introduced. Grid lines in the directory browser are now available in 3 different shades (and can optionally be completely hidden).

• Ctrl+A now works in windows of the viewer component to select all, in text documents and spreadsheets (but not in PDF documents, presentations, ...).

• The Description filter can now filter for directories.

• Extended UTF-8 support in some functions/parts of the user interface.

• The Ukrainian and Russian translations of the user interface were updated.

Notation and Output

• A new notation setting allows to see the complete internal path of an evidence object in the evidence object column instead of the user-definable, up to 79 characters long title or number of the evidence object.

• Another new notation setting allows to not show filename extensions in the columns "Name" and "Parent name", which could be useful for users of X-Ways Investigator in particular who do not care much about what type a file is or pretends to be.

• You can tell X-Ways Forensics what you like to see in the Int. Parent column: The internal ID of the parent as in previous versions, its name, or its description, or a combination of these three. The filename can optionally be truncated before the extension in this column as well.

• Another new notation setting allows to display file sizes in units of sectors. If not found on storage devices or images with sector-level access, but e.g. in evidence objects that are zip archives or directories, a standard sector size of 512 bytes is assumed. The display sector count is either rounded up (because a file occupying 1 full sector plus 2 bytes actually utilizes 2 sectors where files are stored as sector-aligned) or it is displayed with one decimal digit. The display style with one decimal digit can give you an idea how precisely or roughly carved files were sized because if a file size is an exact multiple of the sector size, it will be displayed with no decimal, whereas .0 indicates a few extra bytes that just do not amount to one tenth of a sector. This can also give you an idea which file types are naturally rounded in size, e.g. Windows registry hives and OLE compound files. On the other hand, if a JPEG or HEIC or any other usually unrounded file is shown with no decimal digit, that is a candidate for a file that was truncated, e.g. by carving or file system corruption. (Though if file sizes are equally distributed, one in 512 files would happen to be a multiple of the sector size naturally.)

• The notation settings dialog window was tidied up and renamed Notation/Output. The main notation/output settings of the graphical user interface itself can now be reached from the main menu. The "Notation..." button in the General Options dialog window will probably be removed at some point.

• The option to output either the main filename, an alternative name or both in exported lists and in copylog files, if an alternative filename is known at all, has become a setting in the Notation/Output dialog window.

• The two options for the "1st sector" column, previously part of the directory browser options, have become notation settings and thus can now be different for the GUI and exported lists.

• The setting to display a triangle in Name cells to indicate the presence of labels has been moved from the notation settings to the directory browser options dialog.

X-Tension API

• The XWF_Label() function can now be used to remove a label from a file.

• The XWF_OpenItem() function now supports a flag to embed attachments in an .eml file, usually for export purposes.

• The functions XWF_GetReportTableAssocs() and XWF_AddToReportTable() got new names: XWF_Label() and XWF_GetLabels(). These functions can still be called by their old names for compatibility purposes, but the old names are now deprecated since the arrival of v21.7 SR-4.

Miscellaneous

• When importing hash values, either from an external text file with ASCII hex values or from files selected in the directory browser, you now have the option to merely find out which hash values are already contained in your database and which hash values are new, without actually adding the hash values to the database. This can be used for example to find out how an import would affect your database / if there is any new material included at all etc., or if you get your hands on a list of hash values of files of interest and do not have access to the files themselves (e.g. files that once were in someone's possession) and need to find out whether they are known in your hash database.

• The Recover/Copy function's log function, if fully checked, now also logs directories that are being recreated in the output path, with their original names, internal IDs, timestamps, attributes or whatever you select.

• X-Ways Forensics now monitors additional threads during volume snapshot refinement and attemps to terminate and resume hanging threads if they are found to be unresponsive for e.g. 15 minutes. This is a new settings under Options | Security and assumes that the user interface itself is still responsive. Even if a particular file takes longer to process (e.g. large Outlook PST e-mail archive with many e-mails and attachments), the corresponding thread makes it known that it is still alive, so that alone will not trigger any recovery measures.

• Ability to simulate hanging on a file, using one of the unlabeled, but tooltipped check boxes in Options | Security, only in Preview and Beta releases. (v21.8 Beta is still downloadable for a while.)

• Registering at least one e-mail address specifically for the insurance of each dongle is now much more optional (and will also be treated as more optional in future releases of older versions). If no e-mail address is defined for that purpose, the final transaction code to complete the cancelation of the insurance will be e-mailed to all e-mail addresses connected with the entire license group that the dongle belongs to. If you think that is too annoying for too many colleagues, you can still register more specific e-mail addresses just for this purpose like before.

• The viewer component was last updated with patches on our server for download on Feb 26, 2026.

• An MPlayer release from 2025 is now downloadable.

• The NSRL RDS hash sets, in a format for import into X-Ways Forensics, have been updated to release 2026.03.1, and are available for download in both MD5 and SHA-1 versions, now from the alternative download server.

• The program help and the user manual were updated.

• Many minor improvements.

Changes of Service Releases of 21.7:

• SR-1: Fixed an exception error that could occur when applying OCR to certain PDF documents.

• SR-2: Fixed an exception error that could occur when applying OCR to certain PDF documents.

• SR-2: Fixed a memory allocation error that could occur when reaching around 358 million items in a volume snapshot.

• SR-2: Fixed inability to recognize a FAT file system as such if it consists of less than 100 sectors in total.

• SR-2: The option to skip and omit data in free clusters when creating an image was ignored when active in the .cfg file and when imaging was triggered from the command line. That was changed.

• SR-2: Fixed inability of v21.6 SR-4 and later to extract e-mails from small MBOX e-mail archives.

• SR-2: Improved simultaneous compatibility with v8.5.4 and v8.5.7 of the viewer component.

• SR-2: Improved compatibility of "File Type Signatures Search.txt" with editing in MS Excel.

• SR-3: Ability to import extracted text from evidence file containers, which can be included in evidence file containers in v21.8 and later.

• SR-3: Fixed an exception error that could occur when parsing the report.xml file in some UFDR archives.

• SR-3: Support for overlong UNC (network) paths for progress notifications as files.

• SR-3: v21.7 did not present the dongle management dialog window in some situations when needed at startup. That was fixed.

• SR-4: The Exif table in Details mode was not present for HEIC files since v21.6. That was fixed. The fix is has also been applied to v21.6 SR-8.

• SR-4: Content created timestamps from HEIC files were not translated correctly to local time. That was fixed.

• SR-4: Improved size detection of QuickTime video files with an mvhd atom. This change is also available in v21.6 SR-8.

• SR-4: Fixed an instability associated with the parsing of certain PList files.

• SR-4: Fixed a division by zero error in v21.7 when processing certain video files.

Recent Additions to the X-Tension Repository

Become a certified user of X‑Ways Forensics
Become an X-PERT (X‑Ways Professional in Evidence Recovery Techniques)

Prove your proficiency in computer forensics in general and X‑Ways Forensics in particular with our certification program. After passing the challenging exam, you will be part of an exclusive circle and enjoy various benefits such as special recognition, training discounts, updated training material. For further details, please check here.

Thank you for your attention! We hope to see you soon somewhere at https://www.x-ways.net or on our Facebook page. You may also follow us on Twitter/X. Please forward this newsletter to anyone who you think will be interested. If you wish to subscribe with another e-mail address, please do so here.

This mailing is to announce the availability of version 21.7, with official release date Feb 17, 2026.

License owners please go to https://www.x-ways.net/winhex/license.html as always for the latest download instructions including the latest log-in credentials (!), details about their licenses, and upgrade or renewal offers. Please do not ask us for the download password. Your organization has access to it already if eligible, as described.

Service releases are announced in the Announcement section of the forum, and you can subscribe to instant e-mail notifications of postings in that section if you have a forum profile. You can create such a profile here (if you have our log-in credentials). If you wish or need to stick with an older version for a while, please switch to the latest service release of that version.

Upcoming Training Events

Please sign up for our training notifications here if you would like to be kept posted on future training dates.

What's new in X‑Ways Forensics 21.7?
(where applicable, changes also affect X‑Ways Investigator, WinHex, and X‑Ways Imager)

File Type Support

• The play duration of certain video files that cannot be determined and added to the Metadata column during the metadata extraction step can now be extracted when capturing sporadic still images.

• If you select multiple video files whose play durations are known in the Metadata column, the total play duration of all these videos combined is computed and shown below the directory browser. This enables you and others (e.g. lawyers) to better understand the amount of video data, for example to assess how complete the coverage of surveillance videos is or to judge the amount of illegal videos found, in a more meaningful way than measuring it in megabytes, gigabytes or terabytes, especially for a computer layman.

• Updated support for PNG, TIFF and WEBP files in the internal graphics display library.

• More pictures can now be identified as belonging to the “No device” class, which are known to not have been generated by optical input devices like cameras or scanners, but purely by software.

• The propensity score in the summary table was superseded with the introduction of the confidence about the device class.

• Self-extracting archives in the form of Windows PE .exe files (if they are identified as type “sfx”) are now treated as general-purpose archives and are thus explored along with ordinary archives like Zip, RAR, and 7z, revealing their various sections, and certificates if signed. The PE section that contains data that can be interpreted as an embedded Zip or RAR archive is then usually identified and processed as such.

• Revised processing of .evtx event log files. Fixed some parsing errors. More complete coverage of data types and output of the Name attribute.

• "Uncover embedded data..." now outputs all timestamps found within BPLists as a separate type of event.

File System Support

• Support for WofCompressed files in NTFS with resident storage.

• Support for namespace extended attributes in Ext4 file systems.

• More robust processing of certain corrupt directory cluster chains in FAT file systems.

• For more convenience, when starting off filling a skeleton image by taking a new snapshot of an already open volume/partition, a few sectors from the start of that volume/partition are now included as well to enable the recipient to identify the most common file systems. Note that you absolutely do not have to take a volume snapshot and thus transfer all essential file system data structures into the skeleton image. That could easily include a hundred thousand names of files and directories names, which may or may not be necessary or appropriate for your purpose. If you just need the contents and some metadata of certain files in an NTFS file system for example, you can specifically include the FILE records and contents of those files, without the entire $MFT, and thanks to the inclusion of sector 0 (the boot sector) X-Ways Forensics will know what the file system and the cluster size were, and can find the FILE records with a particular thorough file system data structure search in the skeleton image (quickly, thanks to the sparse nature of the image) and will therefore know the storage locations and names and timestamps etc. of those files in the volume.

• A small number of sectors are no longer included in skeleton images indirectly if they are only read for internal purposes (e.g. to identify and highlight slack space area).

• When creating a skeleton image, the contents of small files that are stored within the $MFT system file can now be automatically excluded from the acquisition when X-Ways Forensics reads $MFT to take a volume snapshot. This may seem like a natural choice since ordinary (larger) files are by default not included in the target image either unless you specifically include them. However, this involves redacting data within certain sectors and as such alters the hash value of the affected sector range in the target image compared to the source volume. As a compromise, if hashing is active, a second hash value for the redacted data is included in the .log file, and that second hash value is the one that is re-computed when you have X-Ways Forensics verify the integrity of a skeleton image created with this new option. Resident main file contents and resident alternative data streams that share the same FILE record as storage space are excluded or included together.

• Adding selected files to a skeleton image will now usually copy those files without slack space, i.e. trigger sector I/O only for the logical file size.

• After taking a volume snapshot of the subject volume that is being acquired as a skeleton image, which includes the essential file system data structures required to locate all file contents, the user is now offered to revert to idle mode so that any subsequent random read operations do not trigger acquisitions any more and the user can freely click around and navigate in the directory browser and will only specifically add file contents to the skeleton image using the dedicated command in the directory browser context menu.

BitLocker Support

• Informs the user if a fitting startup key for a BitLocker volume is found in a .BEK file in the case directory and names that file and where it was found.

• On BitLocker volumes that it can decrypt, X-Ways Forensics now tries to automatically detect unencrypted areas. Such areas can be present if only in-use drive space was encrypted and rewritten when the BitLocker volume was created, for example for performance reasons or because the security implications of this were not understood. If this situation is detected, X-Ways Forensics will recommend running your analyses also on the undecrypted volume, bypassing BitLocker decryption. For example a physical keyword search in the undecrypted sectors in addition to a logical search in the files found in the decrypted volume could be advisable.

• There is a new command in the context menu of an evidence object that is a BitLocker volume that X-Ways Forensics knows how to decrypt. That command allows to open such a volume without decrypting the data in any of its sectors, to see what data are actually, literally stored in them. In that state you could run physical searches or carve data automatically or manually. Not available in X-Ways Investigator.

• The file header signature search can now additionally and automatically perform a second run on the data directly as stored in a partition that is protected with BitLocker, bypassing the decryption algorithm. Either only if the presence of unencrypted areas was detected by X-Ways Forensics in the BitLocker volume (potentially just seconds before during the first, regular run of the file header signature search!) or, if fully checked, on any BitLocker volume that is processed in its decrypted form.

• X-Ways Forensics will specifically remember which files were carved (automatically or manually) while BitLocker decryption was bypassed so that those files in future can be read correctly even when BitLocker decryption is otherwise active. The Description column will identify such files. When working with the decrypted BitLocker volume, switching between Volume/Partition and File mode for such files will show the obvious difference between the data that are either passed through the decryption algorithm in the former modes (falsely, because it was never encrypted in the first place) or not in File mode.

Performance and Stability

• Greatly accelerated loading of very large Passwords.txt files.

• The password collection in Passwords.txt can now be tried to open BitLocker volumes using multiple threads for much better performance.

• Internal graphics display library thoroughly revised.

• Does not waste time with certain unnecessary file system I/O or opening compressed files when including selected files in a hash set and the hash values can simply be taken from the volume snapshot.

User Interface

• The option to assign labels to a parent file now has a tooltip that defines exactly what to expect: The next (closest) parent object that is not a directory will be targeted. This option skips parent directories and keeps looking until a file is found. If no file is found upwards in the hierarchy, no label will be set.

• A new related option was introduced, which targets the so-called ultimate file. That is the parent object highest in the hierarchy that is a file, i.e. the most aggregate file that indirectly contains the data. Parent directories (in file or e-mail archives) can be skipped over optionally. If not, then the last parent file encountered before a directory will be considered the ultimate file. If no file is found upwards in the hierarchy, the label will be set to the selected item itself, if it is a file.

• Another new option allows to simply assign label to all the parent object files of a selected file, in a sequence that may or may not be interrupted by directories. You could then decide later for example based on file type which of those you actually need (e.g. e-mails).

• A new option allows to assign a label to the direct parent object of a selected file, no matter whether it's a file or directory.

• Slightly revised look of the dialog window in which labels are managed.

• If a file is destined to appear in the case report because it was assigned to a label that is includable in the report as a report table, that file is now marked with a special icon in its name cell, where also a yellow post-it icon appears if the file was commented on. The icon for the report is displayed in a fainter color if the label is not currently selected for output in the report options.

• Omitting excluded child objects when printing is now optional.

• Some icons in the user interface were revised, for the simultaneous search, copying extracted text, skeleton imaging and running external programs.

Search Hit Lists and Event Lists

• The search hit filter now allows to more precisely define where in the context of a search hit an additional keyword is required, either to the left or to the right of the search hit or both. Also, an additional keyword can be required in the search hit itself. That can be useful if the data in the search hit is variable for example because it is based not on a fixed keywords, but on a regular expression (e.g. to match e-mail addresses in general), or because the user has shifted the offset of the search hit to the left or to the right to cover related data that needs to be exported etc.

• For both search hits and events there are now two distinct menu commands to add items to the report and remove them. (For search hits there was previously only a single menu command that toggled that state.)

• Selected events from all selected evidence objects can now be included in the case report, near the end, in the order that was last defined in an event list, e.g. sorted by timestamps for a chronological timeline view. (Not in X-Ways Investigator.)

• The description of individual events can now be changed or set retroactively by the user, using the context menu. (Event descriptions are currently limited to 255 bytes in UTF-8.).

Miscellaneous

• Progress notifications can now optionally by output into subdirectories that are named after the machine on which the X-Ways Forensics session is running that produces these notifications.

• Surrogate ASCII patterns for unreadable sectors on storage devices with errors, redacted sectors in cleansed images etc. are now prepended with an UTF-8 signature so that the latest version of the viewer component will display such patterns when viewing or previewing files that consist of only such text (interspersed with binary zeroes), assuming that they are text files.

• X-Tension API: The XT_PREPARE_TARGETFILESWITHUNKNOWNDATA flag now forces XT_ProcessItem() and XT_ProcessItemEx() calls for files with unsupported encryption or compression.

• Files in certain corrupt/incomplete archives can now be opened with 0 bytes instead of not at all. That also means that the X-Tension API function XT_ProcessItemEx() can now receive calls for such files with (useless) handles.

• The viewer component was last updated with patches on our server for download on Nov 2, 2025.

• The NSRL RDS hash sets, in a format for import into X-Ways Forensics, have been updated to release 2025.12.1, and are available for download from the resource directory in both MD5 and SHA-1 versions.

• The program help and the user manual were updated.

• Many minor improvements.

Changes of service releases of 21.6:

• SR-1: Ability to display a rare JPEG variant.

• SR-1: Fixed inability of the original v21.6 release to open the same case with the same user account in cooperative mode more than once (the second time as one's alter ego).

• SR-1: Using only AND combinations of detections of the picture content analysis for the categorization as notable did not work because those combinations were lost. That was fixed.

• SR-2: Avoided an unnecessary error message about the creation of a temporary file at start-up in certain situations.

• SR-2: The data density/compression statistics window is now more likely in the visible range of a monitor with a low screen resolution.

• SR-2: Fixed an exception error that occurred when computing ed2k along with any other hash value at the same time. (also in v21.5 SR-10)

• SR-2: Fixed decrementation of the remaining execution count of insured dongles after automatic restarts. (also in v21.5 SR-10)

• SR-2: Fixed device type dependent application of OCR in certain situations. (also in v21.5 SR-10)

• SR-3: Simple checksums that are computed on a multi-byte accumulator, but byte-wise, are now presented in reverse hex ASCII byte order again like in v21.4 and earlier.

• SR-3: Fixed an exception error that could occur in v21.6 when creating a new evidence file container.

• SR-3: Works with more Tesseract versions.

• SR-3: Navigating back to a parent file by double-clicking the .. entry can no longer cause unintended viewing of the file.

• SR-3: Support for Windows 11 24H2 Prefetch files.

• SR-3: Fixed an error in the Undo command in v21.6.

• SR-3: The character adjustment feature did not work for indexing in v21.6. That was fixed.

• SR-4: Fixed decompression of certain WofCompressed files in NTFS with non-resident storage.

• SR-4: Support for longer paths and filenames in the progress notification function.

• SR-4: Fixed an error in the non-alternative method of TAR archive extraction in v21.4 and later, which occurred with certain TAR archives that contain nested archives.

• SR-4: Fixed an error that caused certain e-mails to be extracted from within MBOX archives with a size of 4 GB.

• SR-4: Prevented potential separation of the [XT] prefix and an actual message in the Messages window sent from an X-Tension that could occur with multiple threads.

• SR-5: Fixed a potential instability in mass picture processing.

• SR-6: SHA-512 was not usable as a hash for disk imaging. That was fixed.

• SR-6: Slightly more accurate representation of the existence status of deleted files and directories in exFAT whose respective first cluster is unknown.

• SR-6: Fixed preview of some rare $I recycle bin files with v8.5.7 of the viewer component.

• SR-6: Fixed BitLocker-to-go FAT16 file system detection.

• SR-6: X-Tension API: The flags XT_PREPARE_DONTOMIT and XT_PREPARE_TARGETFILESWITHUNKNOWNDATA combined now override the user interface setting to omit files whose first cluster of original data is known not to be available.

Become a certified user of X‑Ways Forensics
Become an X-PERT (X‑Ways Professional in Evidence Recovery Techniques)

Prove your proficiency in computer forensics in general and X‑Ways Forensics in particular with our certification program. After passing the challenging exam, you will be part of an exclusive circle and enjoy various benefits such as special recognition, training discounts, updated training material. For further details, please check here.

Thank you for your attention! We hope to see you soon somewhere at https://www.x-ways.net or on our Facebook page. You may also follow us on Twitter/X. Please forward this newsletter to anyone who you think will be interested. If you wish to subscribe with another e-mail address, please do so here.