|Posted on Sunday, Jan 21, 2024 - 15:38:
A preview version of X-Ways Forensics 21.1 is now available. The latest download instructions including password can be retrieved by querying one's license status, as always.
What's new in v21.1 Preview 1?
* Better support for larger volume snapshots, suitable for more than 500 million items in a single volume, assuming an average filename length of 16 characters. With shorter filenames theoretically 1 billion items or more are possible. This is subject to sufficient RAM, only works in the 64-bit edition, and assumes you have enough time to wait for the completion of the volume snapshot. If only the space for filenames is exhausted, more files can still be included in the volume snapshot, but they will be shown with a dummy filename (a question mark character).
* Slightly accelerated volume snapshot creation for large NTFS file systems.
* Two kinds of proactive filters, based on names and timestamps, can now be activated in the properties of a case. Proactive filters allow you to restrict the initial volume snapshot. Files that don't pass these filters will not be included in any volume snapshot that is taken while such filters are active. Directories are still included. This pertains only to partitions/volumes and file archives that are evidence objects, and all the files that are found in them directly, following the defining data structures of the file system or the archive. It does not restrict the addition of files that are found in any other way, for example by a file header signature search or when checking files that are already contained in a volume snapshot for embedded data etc.
Proactive filters are special in that they can prevent files from involuntarily getting into a volume snapshot, files that you do not need or want to be there or that you are not supposed to see. Either if your task or search scope is limited to specific files whose names or timestamp ranges are known beforehand or if the evidence object (image or file archive) is so big that by avoiding hundreds of millions of other files you save time and main memory or can make the volume digestible at all (i.e. keep the volume snapshot size within the supported boundaries). The creation of the volume snapshot itself may be noticeably accelerated that way if the evidence object is an image file, plus all subsequent steps (navigating, listing, sorting, filtering, volume snapshot refinement) are less computationally expensive if you proactively prevent the inclusion of large numbers of unwanted files.
A count of how many files are proactively omitted during the creation of the volume snapshot is displayed in the progress indicator window. After completion, the total number of such files can always be checked in the status of the volume snapshot in the dialog window for volume snapshot refinement. A warning that a proactive filter is active is output in the Messages window once per session, when a volume snapshot is taken.
* Report HTML files are now generated automatically for the Windows Registry hive files NTUSER.DAT, SYSTEM, SOFTWARE, SECURITY, and SAM as part of metadata extraction. These files are stored as child objects. The benefit is that they can serve as human-readable previews of selected interesting values, and they contain some encoded text in plain text such as UserAssist entries, so that the logical search can find them.
* Ability to decode .json files for logical searches, indexing, and Text Preview mode, including files with specially encoded Unicode characters from the Basic Multilingual Plane (e.g. Chinese).
* error.log file entries are now stored in UTF-8 instead of the ANSI code page active in Windows.
* Improved error message when encountering non-standard internal timestamps in .e01 evidence files.
* More consistent and thorough error and plausibility checks of user-provided file masks.
* "Social media" was one of multiple possible values of the processing state in the Summary table of JPEG files in Details mode. It has now instead become one of the possible values of the reported software class.
* Other new possible values of software class are now "stock" (for stock photos), "Amazon" (for product photos from Amazon's shopping web site), "Mastodon" (the Twitter/X competitor), and "MS Office". About 75% of all JPEG and PNG (plus some WEBP) pictures now get a software class assigned.
* Some iPhone-related generator signatures are now properly identified as iPhone.
* Various minor improvements.
|Posted on Sunday, Feb 4, 2024 - 16:35:
* Volume snapshots of extraordinarily huge volumes now support files that are defined in the file system at offsets beyond 131 TB or have their data starting more than 131 TB into such a volume. The new limit is 262 TB.
* Ability to recognize SquashFS compressed file systems and treat their contents like file archives. The supported compression algorithms for SquashFS in X-Ways Forensics are GZIP/zlib, LZMA, LZO and XZ.
* Support for some more TIFF picture variants with the internal graphics display library.
* 27 software classes are now supported for JPEG and WEBP pictures: Firmware, Adobe, PHP, Apple, Windows, Facebook/Instagram, Android, General, WordPress, Editor, Social Media, Google/Picasa, Scanner, WhatsApp, Video still, Website builder, Stock, Twitter, Amazon, Screenshot, Pinterest, Content, Camera, LinkedIn, Beautifier, Bing, MSN.
* Output of Exif metadata in WEBP pictures in addition to XMP metadata.
* Improved output of metadata for ICC color profiles.
* Several minor improvements.
* Same fix level as v21.0 SR-2.
|Posted on Monday, Feb 12, 2024 - 9:53:
* Directory listings obtained from the operating system ("OSDirList"), which you get for example when adding a directory or a single file to a case as an evidence object, can now be made to NOT show any timestamps from the file system or only the modification timestamp. That is a volume snapshot option and useful if the timestamps of the files rather reflect when you collected the files and not what timestamps they had when at their original location and thus do not have the usual significance.
* When X-Tensions add directories to a case as an evidence object, they can choose to have X-Ways Forensics ignore any of the four regular timestamps of NTFS.
* In new installations the default setting of the volume snapshot option "Newly identified names as main names" is now half selected, which means only for original .eml files, for which it's useful to see the subject instead of a potentially unhelpful generic filename.
* Block hash matches are now displayed with their sizes in the search hit column.
* Option to define the block size for block hash databases. 512 bytes is still the default and recommended unless you are certain of what you are doing. A larger block size of 4 KB for example can be compatible with volumes/partitions that have a cluster size of 4 KB and hard disks with a sector size of 4 KB physically and logically, but thwarts any attempt to find the data that you are looking if the clusters in the target file system are not aligned at 4 KB boundaries themselves from the point of view of the evidence object. The latter may be the case for example because the file system has an irregularly sized header area before the first cluster (like FAT) or because you apply the block-wise hashing (only) to a partitionable storage device in which the partitions are not aligned at a 4 KB boundary. The good news, however, is that, just like the file header signature search, block-wise hashing is applied specifically to partitions if partitions are known on a partitionable storage device (or image thereof), and only the area outside of known and explorable partitions is processed at the level of the partitionable storage device.
* CRC32 hash values are now supported in ordinary hash databases. This is useful (only) if you really only know the CRC32 values of files that you are looking for, no more advanced hash values and not the full original file contents, for example from encrypted zip archives as such archives have the CRC32 values of the unencrypted data in the metadata. If you find CRC32 matches and the file size is the same as known from the metadata in such an encrypted zip archive, then it is very likely that you have found an unencrypted copy of the very same file.
If you wish to import CRC32 hash values from a text file (with "CRC32" in the first line, followed by one checksum in hex ASCII per line), please note that their hex ASCII values are expected in big-endian ("human-readable") byte order, as displayed in software like 7-Zip and WinZip and also X-Ways Forensics itself, which unlike MD5, SHA-1 etc. is not the byte order in which they are stored in binary, in X-Ways Forensics internally as well as in zip files themselves and presumably elsewhere.
* When interpreting a file as a raw image that does not have a multiple of the presumed sector size as the file size, the extra data at the end that doesn't add to another full sector is now included, unlike in previous versions, which affects hash computation and potentially file carving. You will still get a warning about the unexpected file size when interpreting such an image, unless you have suppressed it for an evidence object. You may also get read error messages when operations that are applied sector-wise try to read the last (incomplete) "sector".
* Extracts Microsoft Teams messages stored in certain PST archives that were exported via the Admin Center of Microsoft 365.
* Several minor improvements.
|Posted on Tuesday, Feb 20, 2024 - 10:34:
* Ability to extract e-mail messages from OLM databases of Microsoft Outlook for Mac.
* Some minor improvements.
* Same fix level as v21.0 SR-4.