Added support for decrypting passwords encrypted with app-bound encryption on new versions of Chrome (Version 3 of Chrome App-Bound Encryption)
Be aware: The new app-bound encryption (version 3) uses the Next Generation Cryptography API (CNG) to encrypt and decrypt the encryption key. Currently, the external drive feature cannot decrypt the CNG key and thus it fails to recover the passwords if you have the version 3 of Chrome app-bound encryption.
Added 'App-Bound Encryption Version' column.

Security bugfixes
OpenSSL DLLs updated to version 3.5.4.
Service-level multivalued options now override (rather than append to) global defaults, preventing unintended configurations.
Bugfixes
Fixed enabling/disabling of the default fips=yes property.
Missing OCSP stapling is no longer logged as an error.
Fixed a crash when a PIN was required due to the PKCS#11 CKA_ALWAYS_AUTHENTICATE attribute.
Features
Quantum-resistant hybrid key agreement X25519+ML-KEM-768 (X25519MLKEM768) used by default with OpenSSL 3.5+ and TLS 1.3.
Multiple cert sources are supported, allowing a certificate to be fetched from a provider while loading the chain from a file.
Android build switched to a 16 KB page size.

Fixed: The console program was not being updated in the 32-bit install.

Encryption/Decryption

X-Ways Forensics can now decrypt BitLocker volumes that are protected with a startup key if the right startup key is available. Startup keys are stored in .BEK files, which in turn are usually stored on removable USB storage devices. Whenever X-Ways Forensics encounters a .BEK file in any evidence object while taking the volume snapshot, it copies the .BEK file to the case directory and keeps it there. (The case directory, not the directory for cases.) In that directory .BEK files are automatically found whenever a BitLocker volume is opened to see if any of them fits. You can also manually copy .BEK files that you have found into the same directory to get X-Ways Forensics to try them.

Supports file systems other than NTFS in BitLocker partitions in regular (not "to go") style for internal decryption.

Tentative fix for only partially encrypted BitLocker volumes.

There is now an option to always prompt the user before decrypting a BitLocker partition when opening it. If declined, all data in all sectors will be shown exactly as they are stored on the storage device, i.e. usually (but not necessarily) encrypted.

Informs users that and why switching to any mode other than read-only mode is not possible with a decrypted BitLocker partition.

Ability to try the passwort collection of the active case (Passwords.txt) when prompted for the password of a BitLocker volume.

Before trying the password collection on a BitLocker volume, X-Ways Forensics now first attempts decryption with the passwords of other BitLocker volumes in the same case, if there are any, for which a password is known. For that reason it can be beneficial to unlock BitLocker volumes with a known password instead of with a known recovery key when prompted if you happen to have both.

The verified password or recovery key of a BitLocker volume is now saved in the Description box of the evidence object properties for your future reference.

Internal passwords/encryption keys, such as for encrypted .e01 evidence files and cases, now optionally support Unicode, depending on the state of the new check box "Encode internal passwords as UTF-8" in the Options | Security dialog window. Make sure the box is UNchecked if you have previously used passwords that contain non-ASCII characters to preserve compatibility.

Unicode support for password prompts of the viewer component.

Non-Latin 1 passwords are now supported when entering passwords manually to decrypt archives..

File Archive Support

When creating a container for selected files that you wish to acquire, store together in a separate place or share, you can now opt for a Zip archive instead of a regular file container (with a file system). Already created zip archive containers can be opened for further filling (only unencrypted ones). Many of the advanced properties of a regular evidence file container are not available that way, but using Zip archives has the following advantages:
+ The file contents can be encrypted immediately, which can be useful not only to prevent them from being read by unauthorized people, but also to prevent virus scanners from detecting malware that you intentionally wish to pack up/quarantine in a dedicated archive, for example with a password like "infected". This function is also called "secure export".
+ Ordinary tools that do not understand file systems at a computer forensic level as required for regular evidence file containers may be able to read zip archives and allow to view the included files. That includes the Windows File Explorer (which, however, does not support Zip archives with AES encryption).

Regular evidence file containers still have these unique advantages:
+ ability to distinguish between existing and deleted files
+ store an incredible amount of other metadata
+ protection against duplication (user adding the same file multiple times)
+ Ability to include file slack or only the slack or only the selected block or to only include metadata.
+ files as child objects of other files
+ original file system data structures for directories,
+ pass on labels, comments, hash values
+ embed attachments in .eml e-mail messages

When adding spanned/segmented file archives in WinZip style (.z01, .z02, ..., .zip) to a case, you do not need to make sure any more to select the first segment (.z01) as stated in the documentation. If you add the last segment (.zip) instead, which is intuitive because of its well-known extension, that will now also work, i.e. all segments will be found and internally concatenated as needed. This also works if the extension of the last segment is .ufdr instead, i.e. in the case of a spanned Cellebrite UFDR report.

Slightly improved handling of .fctar files as evidence objects.

File System Support

Redundant timestamps from 0x30 attributes in NTFS FILE records are now included in newly taken volume snapshots and no longer rejected as irrelevant already at the time when the file system is parsed. Now you can decide in the Notation settings whether redundant timestamps should be displayed/output or not. By default, they are hidden, just like in previous versions, in order to not unnecessarily clutter up the screen, with the goal in mind to require the user's time and attention only for timestamps that actually contain additional information. However, if you feel you temporarily need to see all timestamps to double-check or if the recipients of exported lists that you are sharing wish to see all timestamps, you can now selectively enable redundant timestamps for where they are needed. A middle setting allows to see redundant timestamps dimmed in a light gray color in the directory browser just like previously known from never updated last access timestamps. (The middle setting is not available in the Notation settings for case reports, the Export List command or the Recover/Copy command.) Filters and sorting used to treat redundant timestamps as non-existent in previous versions because they were simply not included in the volume snapshot. Now they are treated like any other timestamps, no matter whether they are currently visible or not. If a timestamp filter specifically targets a column with redundant timestamps, those timestamps will be displayed and highlighted even if they were otherwise invisible.

If you wish to see timestamps in the volume snapshot of an NTFS file system with more than 4 digits after the decimal point (fractions of seconds), you do not have to point the Data Interpreter any more to the timestamp in the 0x10 attribute of a FILE record, but can now simply open the file of interest or switch to File mode for the selected file and refer to the Info Pane for the maximum of 7 such digits. This full precision is also available in the Info Pane for files in an evidence object that is a directory in an NTFS file system as well as for files opened directly with the File | Open command.

The threshold above which backdating is brought to your attention in the display of a timestamp column in the directory with the clock+arrow icon and a brief representation of the time discrepancy and which is used for the backdating filter can now be set in the directory browser options.

The detection of backdating activities in NTFS timestamps can now be limited to instances where the subsecond part of the timestamp (the digits after the decimal point) is zeroed out, with the expectation that backdating was performed manually by some timestomping tool that did not bother to create randomized subsecond digits and rather set those parts of the timestamps to zero. (Malware that tries to cover its tracks and backdates files automatically and algorithmically may be better than that.)

Suitable timestamp precision in the directory browser and in the Info Pane display for files listed by the operating system if the underlying file system is FAT, not NTFS.

APFS: More extended attributes (EA) will generally be picked up and output in the Metadata cell of a particular file if the volume snapshot option "Output simple EAs as metadata" is enabled. That means fewer child objects and more EAs showing as legible text in the Metadata cell of the file that the EA actually belongs to. Some additional data are parsed that way and presented in legible form, for com.apple.assetsd.UUID, com.apple.assetsd.timeZoneOffset and the timestamp in the com.apple.quarantine EA. If "Output simple EAs as metadata" is disabled, an EA child object will have the same information in its Metadata cell. For the output of com.apple.quarantine EA, the check box "HFS+/APFS: Complete output of EA" needs to be at least be half checked. Any timestamps found in quarantine EAs will be output as events of the type "Operating system: Quarantine" in newly taken volume snapshots, and associated with the file that the EA belongs to. If the quarantine entry contains an application name, and perhaps even a GUID, those end up in the event description.

Storage Device Support

That the username of the logged-in user who creates an image is included in the descriptive text file is now optional. Fully unchecked even the examiner name known in X-Ways Forensics is not included.

Support for more LVM volume groups open at the same time.

More tolerant of certain corrupt GPT partition tables.

Improved detection of GPT-partitioned disk data occurring paradoxically within a partition when opening such a partition. Can happen for example with level 1 MD-RAIDs. An automatically generated comment advises the user how to get such data interpreted correctly: You can right-click the virtual file that spans the entire partition and open it, and because it is like a raw image of a partitioned storage device, you can afterwards interpret it as a disk and add it to the case as an additional evidence object by right-clicking its tab..

Picture File Support

The list of recognized picture generating devices was updated.

A propensity score is now only output for pictures that were not known to have been generated by a sensor-based device.

The status "disseminated" is now also defined for WEBP and PNG files. The status "edited" can be detected in some WEBP files (they can now edited in Photoshop or GIMP).

Extraction of creator/author names from certain JPEG files like in older versions of X-Ways Forensics.

No more extraction of blank "light values". Whether a "light value" is presented in the metadata column now depends on whether the output of indoor/outdoor is selected for the picture content analysis.

Metadata extraction from AVIF picture files.

Generator signatures are now defined for AVIF files. Device types are assigned. A new generating software class is defined specifically for AVID: Airbnb.

Improved identification of original (unaltered) and editied JPEG files produced by Xiaomi, OPPO and OnePlus devices.

Labeling of JPEG, PNG and WEBP pictures as pictograms where applicable. Such pictures also get a lower generic relevance assigned.

Extended detection of certain AI-generated pictures. Certain pictograms, AI-generated pictures and graphical elements are now shown with the device type "no device" to show that they were not generated by any image capturing devices.

Improved information about color profiles (ICC).

Slightly improved output of PNG metadata..

Volume Snapshot Refinement

Updated detection of eCryptfs-encrypted files on Linux file systems as part of the "File format specific and statistical encryption test".

Indexing engine slightly revised.

X-Ways Forensics no longer needs to resort to a single thread when restarting itself after a crash in order to single out a problematic file, omit it and label it as the reason for the crash. This will improve performance.

Whether detections of the picture content analysis shall be used for categorizations based on rules that the user defines can now be decided separately for notable and irrelevant content.

When the metadata extraction finds out that multi-media files in the MP4 container format contain only audio, no video, it now confirms the file type as M4A (an audio-only file type) so that users that are interested in the video category do not need to invest time checking out those files.

User Interface

Regular filters (which internally can be combined with AND or OR) can now be combined with the FlexFilters (which internally can be combined with AND or OR) with a logical OR in addition to a logical AND.

The Description filter dialog window now has an option to focus on non-trivially hard-linked files.

Another Notation option has been introduced for the "Existent" column. Users can now describe the "existent" or "non-existent" status in their own words. Particularly useful for example for the Export List command to match the expectations of a 3rd party and for the Recover/Copy command when grouping files by their existence/deletion status so that you get directories named accordingly.

There is now a dedicated symbol (a lower-case i in a circle) in the caption line of the directory browser where you can left-click to get a textual summary of all active filters with their settings.

The icon with the keys next to a BitLocker partition in the case tree as well as in the directory browser is now grayed out if the right password or key for decryption is already stored in the case, to confirm that the encryption is no obstacle any more. For similar reasons, BitLocker partitions with clear-key encryption are presented with the same icon.

The Override command line parameter for unsupervised automated processing can now skip the BitLocker password prompt, with either value 1 or 2, or it can make X-Ways Forensics try the internal password collection (in Passwords.txt) if a value of 4 is combined with the usual 1, which gives Override:5. [Note that Override:5 is not compatible with earlier versions of X-Ways Forensics.]

More intuitive options to select the gradient colors for tag marks and for the "already viewed" status.

Miscellaneous

Exporting and importing selected label names as UTF-16 text files now not only includes the optional descriptions, but also the type of label (e.g. "user-defined") and the label settings (the check marks on the right-hand side of the dialog window to manage labels).

Templates now support a new modifier called "hidden", which identifies variables whose values you wish to set during parsing and may need for subsequent calculations, but do not want to show to the user. Also useful for constants that you define and use in calculations that the user should not be distracted with.

Fixed an error where OCR was involuntarily executed retroactively after picture content analysis was applied to selected files.

The program help and the user manual were updated.

Many minor improvements.