WinHex & X-Ways Forensics Newsletter Archive

This mailing is to announce the release of another notable update with many important improvements, v19.0.

WinHex evaluation version: http://www.x-ways.net/winhex.zip (also the correct download link for anyone with a personal, professional, or specialist license)

Customers may go to http://www.x-ways.net/winhex/license.html for download links, the latest log-in data, details about their update maintenance, etc. Those customers whose update maintenance or license has expired can receive upgrade/renewal offers from there. The password for users of X-Ways Forensics will change soon!

Please be reminded that if you are interested in receiving information about service releases when they become available, you can find those in the Announcement section of the forum and (with active update maintenance) can subscribe to them, too, by creating a forum profile.

Please note that if you wish to stick with an older version for a while, you should use the last service release of that version. Errors in older releases of the same version may have been fixed already and should not be reported any more.

Upcoming Training

Ottawa, ON, Nov 7-10
Washington DC area, Dec 12-15
Miami, FL, Jan 23-27
London, England, Feb 20-23
Victoria, BC, Mar 21-28
Washington DC area, Apr 19-21

Please sign up for our training newsletter here if you would like to be kept up to date on classes in the USA, Canada, Europe, and/or Asia/Pacific.

What's new in v19.0?
(please note that most changes apply to X-Ways Forensics only)

Performance

• Analogously to the logical search, the file processing part of volume snapshot refinement now supports multiple threads (only if not applied to a selection). This is currently still considered an experimental option. Depending on the selected operations and the types of the files in the volume, and depending on I/O speed, this can double, triplicate or even quadruplicate the performance. The faster your mass storage solution (HDD, SSD, RAID) in terms of seek times and data transfer speed, the more time you save percentage-wise. This parallelization feature is still considered experimental and not complete yet, but the potential for time saving in one of the most important and most time-consuming functions of the program is already enormous.
  
  Selecting multiple threads has an effect only when searching in evidence objects that are images or directories, not disks. If you select just 1 thread, it will work as in X-Ways Forensics versions before 19.0. If you select 2 or more threads, processing is done in additional worker threads (as many as you select), 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 8, if your CPU supports that. If multi-threaded processing crashes, next time when you restart the program it cannot tell you which file presumably caused the crash. Please keep in mind if what you are doing is very I/O intensive such as hashing and your mass storage medium is slow, there is not much more to gain.
  
  File-wise processing conducted by X-Tensions (through calls of XT_ProcessItem or XT_ProcessItemEx) are also parallelized if the X-Tensions identifies itself as thread-safe. Processing of files in file archives is currently excluded from parallelization internally. Parallelization is currently not offered as an option if indexing is selected.

• The amount of time that volume snapshot refinement took is now shown in the Messages window if applied to selected evidence objects. Useful to run your own performance tests with single or multiple threads.

• For performance comparison tests you may find it desirable to discard all the file buffers that Windows maintains when it has more than enough memory, so that you can run the same operations on the same image again, without skewed results from the second attempt because less disk I/O is required. A function to recycle/exhaust excess main memory can now be found in the Options | Security dialog. Click the button with the recycling symbol.

• An unlabelled (but tooltipped) check box in the volume snapshot refinement dialog window can now make X-Ways Forensics reveal which suboperation is currently applied to the currently processed file. A 3-digit abbreviation will be displayed with the following meaning:
  
  Sig: file type verification
  Hsh: hashing
  Vid: capture sporadic still images from videos
  Idx: preprocessing original file contents for indexing
  Dec: text decoding for indexing
  IdX: preprocessing decoded text for indexing
  Emb: search for embedded data
  PDN: PhotoDNA database matching
  Pic: other picture analysis steps
  Eml: e-mail extraction
  Fuz: FuzZyDoc database matching
  Met: metadata extraction
  Enc: file format specific encryption test
  Ent: entropy check
  Arc: inclusion of files in archives into the volume snapshot
  
  This may be helpful for educational reasons, to give users a better idea of how computationally expensive certain suboperations are and how much time could be saved by not selecting them if not absolutely necessary. It may also prove useful for debugging purposes. Whether this option may slow down processing on certain computers has not been tested.

• A new option allows to not hash very large files. This can save a lot of time and disk I/O. Often no hash values are required for very large files (such as backups, virtual machine disk files, databases, pagefiles, $UsnJrnl:$J, ...) because many of them are quite unique and not what users are looking for based on hash values, nor are they usually included in known-files hash databases. A reason not to use this option for example perhaps would be if you are looking for high quality pirated copies of movies.

• Accelerated PhotoDNA matching by roughly 20%!

• PhotoDNA hash values are now computed and matched only if the picture contains a total number of pixels that is larger than a user-defined minimum (width times height). This avoids database look-ups that can be time-consuming in very large PhotoDNA hash databases and typically have no benefit for small garbage pictures. The minimum dimensions allowed as a condition are 50x50 pixels, and that was also the implicit condition in previous versions. The PhotoDNA algorithm intrinsically requires a certain minimum number of pixels to provide meaningful results.

• The minimum total number of pixels in a picture required to compute the skin tone percentage and check for black & white is now user-definable. If a picture has fewer pixels, it will show as "irrelevant" in the Analysis column, and a little bit of time will be saved by not checking the pixel colors. The minimum width and height used to be 16 pixels in all previous versions. The new default now is 32x32=1024 pixels in total.

• Processing of EDB databases was revised, for higher speed and reliability while using less system resources. Fixed a very rare occurrence of an infinite loop while processing WebCache databases.

• Ability to load larger parts of large hash databases into main memory when matching hash values against them, for higher performance, and the user may now customize how much of the available memory should be allocated.

• The option to avoid damaged hard disk areas when cloning disks, by skipping sectors once a bad sector was detected, can now perform much larger jumps and always jumps exactly by the desired sector count as specified by the user.

Technical Specifications

• Now up to 2³¹ hash values supported per hash set and per hash database instead of 2³⁰ in previous versions.

• Ability to view and preview files with the viewer component that are larger than 2 GB.

• 16-bit, 32-bit, and 64-bit checksums are now no longer computed byte-wise on an accumulator of the specified length, but are the sums of 16-bit, 32-bit, and 64-bit integer units, respectively.

• To better utilize widescreen monitors and to assist examiners in particular in Asia, who may encounter text encoded in many different character sets and code pages in the same case, it is now possible to see multiple text interpretations of binary data in the hex editor's text diplay at the same time depending on the license type. You can choose the character sets/code pages in the View menu separately for each column. This is also useful to walk through the raw data of Outlook PST files that use cipher coding, to be able to read encoded ANSI text, encoded Unicode text, and totally unencoded text at the same time.
  
  Personal license for WinHex: no more than 1 character set at a time
  Professional license for WinHex: up to 2 character sets at a time
  Specialist license for WinHex, X-Ways Investigator: up to 3 character sets at a time
  WinHex Lab Edition, X-Ways Forensics: up to 4 character sets at a time
  
  Please note that any text input from the keyboard is interpreted as being based on the ANSI code page that is active in Windows, except if the primary text column is set to the IBM/OEM/DOS code page 850 (Latin I), in which case input is based on that code page, just as in previous versions of WinHex/X-Ways Forensics.

Directory Browser

• New directory browser column "Existent" that shows whether a file is an existing file or a child object of an existing file or not (existing based on its point of reference, e.g. file system), either with a check mark or a mathematical symbol or in natural language, depending on the Notation options. A third state is "virtual". To filter for the existence status, please continue to use the Description filter. Remember you can group files by existence status using the directory browser options, or you can now sort by this new column.

• New separate directory browser column for the full path, i.e. the path including the name of the file or directory itself. Previously, it depended on a directory browser option whether the path was fully displayed or not. Remember that sorting by full path can yield a convenient order because child objects follow their respective parents.

• New directory browser column for the optional 2nd hash value, with a separate filter. Previously, a single column optionally showed both hash values.

• New directory browser column "Group". For newly taken volume snapshots that columns shows the ID of the assigned group of a file in Linux file systems.

• A new column named "FS offset" (specialist license or higher) shows the offset of the defining data structure of a file or directory in the file system, i.e. the structure that is the basis for the inclusion of a file in the volume snapshot. That offset is where you can check details manually in case there are any doubts about where X-Ways Forensics got the file system level metadata from. This is also where you may apply a suitable template to get an alternative interpretation and where you can point disadvantaged users of other tools to as they may not be able to find such a crucial location otherwise or don't even get certain deleted files listed. Carved files and files that are embedded in other files for obvious reasons do not have such an offset in the file system (or in the case of carved files at least it is not known to X-Ways Forensics). The file system offset is also where you navigate to when you use the dedicated context menu command to locate a file's FILE record/inode/file entry/catalog key etc., as known from all versions. The context menu command to sort by defining data structures' offsets has become obsolete now that users can sort by the new column.

• Option to classify files that you specifically attach to a certain directory or file as what they actually are, e.g. video stills produced outside of X-Ways Forensics, e-mails extracted from e-mail archives outside of X-Ways Forensics, OLE2 objects, attachments of various kinds (in particular of PDF documents), etc. etc. If properly classified as video stills, the attached pictures will be used as previews for the respective parent video file for example. The classification can be seen in the Description column.

• Files that are attached to their respective original counterparts in the volume snapshot automatically via Unique ID now adopt the classification of the original files. Except if the original files have no special classification, in which case the attached files will be marked as attached files.

Disk/Volume/Image Support

•  Ability to specify the internal description of an image and the examiner name when imaging media automatically through the command line interface. For example,
  :1 "|e01|G:\Test.e01|My description|My name
  will acquire the disk with the internal number 1 in Windows in .e01 evidence file format with the name "Test.e01" in the directory G:, with the "My description" as the description and "My name" as the examiner. The parameters are delimited with pipes and may contain spaces. The order of these parameters is fixed. Description and examiner name are optional.

• A new option for image verification immediately after creation allows to exhaust system memory prior to the verification to invalidate and thwart any file buffers employed by Windows so that the data of the image is read directly from the disk for the verification and not taken from the memory buffer. This option exists for small images and for somewhat paranoid or very diligent users. It is not required for images that are much larger than the physical amount of RAM that is installed in your machine because by the time when the final parts of the image have been written, the initial parts are no longer in the buffer, and once the final parts are about to be verified they are no longer in the buffer because at that time the initial parts are in the buffer as they have been verified just before. This option may have a small temporary performance impact on your Windows system, and verification may be slightly slower than normally.

• X-Ways Forensics now supports multiple images with the same name in the same case, for any case created by v16.1 or later. Useful for example for users who for some reason acquire media with an imaging device that assigns the same filename to all images. Also useful if you encounter multiple images with the same name within images (not uncommon for virtual machine disks used by a suspect) so that you do not have to individually name those files. Please note that you should not work with evidence objects affected by conflicting image filenames in v18.9 or earlier as these versions may load the wrong volume snapshot.

• New general option: Always request user input for raw images to specify the kind of the image (volume or disk), the sector size to assume and the path for potentially existing additional image file segments. Exactly what happens if you hold the Shift key while the image invoking image interpretation or while adding the image to a case. Usually not necessary if the image was created by X-Ways Forensics itself, but still some removable media (USB sticks and memory cards) may have been used and formatted as both volume and partitioned medium at different times. In such a situation interpretation as volume and as partitioned medium may reveal different file systems that overlap each other.

• The options to highlight free space and slack space for specialist licenses and higher have been moved to the General Options dialog window.

• Option to store already extracted metadata of files in evidence file containers, for the recipient to see immediately without having to extract metadata again.

• LVM2 container partitions are now recognized as such even if the designated partition type in the MBR or GPT is wrong.

• Ability to parse Ext* file systems with a block size that is smaller than the sector size of the surrounding physical image, as possible in Android devices.

• If the user forces the interpretation of a volume as NTFS because the boot sector does not identify the file system as NTFS any more and the backup boot sector is not present either, WinHex will now prompt you for the presumed cluster size so that you do not have to superimpose a dummy boot sector to get the location of file data right (assuming FILE records are found by the particularly thorough file system data structure search).

PhotoDNA

• A new button with a magnifying glass icon can now help you check the database for the presence of a specific hash value, specified in Hex ASCII or Base64 notation. If there is a hit, you will be shown the name of the hash collection that contains the hash value. If the matching entry in the database has a textual description, that description will be shown as well. Up to 19 matches are returned, and for each you will see how precise the match is (the higher, the more precise; same basic scale as the user-specified strictness for matching, i.e. level 1 means very rough match). You have the option to narrow down the result list to more precise matches by enforcing a higher minimum strictness level, which is useful if there are more matches than can be listed.

• Double-checks with the user if the lowest possible strictness level is selected for PhotoDNA matching (level 1), as that level is known to occasionally deliver false matches. That level is offered in X-Ways Forensics only because it is provisionally suggested by the original developers of PhotoDNA. The recommended and default level in X-Ways Forensics is level 3.

• Option to conveniently and freely select the path of the PhotoDNA database in the General Options dialog. Users may change from one database to the other at any time.

• Option to totally skip duplicate and consistency checks during PhotoDNA imports, to potentially save hours of time, with the disadvantage that matching during volume snapshot refinement will take more time and that for variations of the same picture you may get different classifications returned (only if the hash collections that you import are not very consistent internally or if they contradict each other).

• Recategorization of existing PhotoDNA database entries that match new entries during import is now more exhaustive and no longer only affects the best matching entry. This comes at the cost of slower imports.

• Option to mark selected PhotoDNA categories as "preferred", with a black star. That way they will get priority if for a picture in the volume snapshot matches are found with hash values in different categories. Such preferred categories will be reported as a match even if alternative matches with non-preferred categories are much closer matches. That is useful for example if you have categories in your database that you trust to be accurate and suitable and others that you trust less, for example because they are known to contain errors (e.g. the same picture classified as CP and non-pertinent at the same time) and/or because they are from a foreign source and based on different laws and jurisdiction.

• When importing new hash values into the internal PhotoDNA database and one of the new hash values is similar to an existing or another new hash value, X-Ways Forensics may choose to discard the previous hash value and and replace it with the new hash value, to keep the database compact and less redundant. This happens if the deviation between the two hash values is below a certain threshold. That threshold has been increased or in other words the strictness for redundancy reduction has been decreased, which means more hash values are now discarded if similar.

• The two strictness levels for redundancy reduction and consistency improvement during PhotoDNA database imports are now both user-definable.

• The import statistics at the end of a PhotoDNA import now also reveal how many previously existing entries in the database adopted a new classification.

• Ability to export selected hash collections from the internal PhotoDNA hash database into text files to share them with other users or to check which hash values are contained/which ones were deduplicated etc.

• Parsing of ODATA/JSON files was revised.

Case Report

• The cascading style sheet (CSS) definitions for the case report in the text file "Case Report.txt" now come with plenty of built in explanations that should make it easier to adjust the formatting to your liking.

• If .eml files are represented in HTML directly in the browser (the so-called alternative representation), attachments can now be optionally copied along with the .eml files and linked from the HTML representation.

• On a related note, presenting .eml files without headers and alternative .eml preview are now two separate options and can be combined with one another.

• Ability to see the description of report tables directly in the dialog windows for the report table filter and the creation and management of report tables and report table associations.

Search Hits

• Block hash matches can now be larger than ~ 64 KB. Thus longer matches no longer need to be split up into fragments of ~ 64 KB each.

• Physical search hits (i.e. those defined in Disk/Partition/Volume mode) may now be larger than ~ 64 KB as well, e.g. manually defined search hits (so-called user search hits).

• The comparison function of the File Tools menu has been moved to the Tools menu (as it is perhaps even more useful for disks rather than files) and was revised for users of X-Ways Forensics. It now has an option to output identified different or identical data areas as search hits (1 entry per matching area) instead of a text file (1 line per matching byte), for convenient review and navigation right within the program in the search hit list, similar to block hash matches. This option is only available if at least the 2nd data source is an evidence object. The result can be seen in the search hit list of that evidence object. Useful for example for users who wish to compare cloned disks with minor changes, if they have different hashes or one of them has been used a little more, to actually locate the differences and better understand what has caused them. Useful also to compare component disks of a hardware RAID level 0 system or a mirrored volumes, to check whether they are really absolutely identical, and if not to easily find the areas that differ, see how large they are, what kind of data these areas contain, and assess whether the second copy requires full treatment itself including carving, keyword searches etc. Please remember that to visually check the data in multiple data windows for differences at corresponding offsets, you can use the Synchronize and Compare command.

• The length of block hash matches, physical user search hits and comparison results in the search hit list is now shown in the Size column. This is useful for example to be able to sort block hash matches by the lengths and review more important (larger) matches first.

• Maximum number of search terms listed in the Search terms column increased from 25 to 50.

File Type Support

• Generator signature coverage brought much further to perfection.

• Metadata extraction support for the spartan.edb database of the Edge browser. An HTML-formatted preview is generated and events will be added to the event list for all favorites and ReadingList entries.

• Extraction of Windows PowerShell events and their most important values from Windows event logs and output to the event list. These events include starting and stopping the console and execution of or failure to execute scripts (including their paths). Potentially useful for malware investigations.

• Internal file archive handling revised.

• Extraction of Exif metadata from Nikon cameras improved.

• MP3 metadata extraction revised. A reasonable subset will be output in the Metadata column to better distinguish between MP3 files of different natures/origins, for example voice recordings vs. commercial audio files. Please note that you can also try to sort by generic relevance to tell such files apart.

• Timestamps in the HTML previews of EDB databases are now output based on the user-defined timezone instead of UTC.

• Thank you for reading every single bullet point!

• The weight with which the currentness and the size of a file affect its computed generic relevance is now user-definable. 100% means default weight. 50% means half of that. 0% means the factor has no effect at all. The maximum is 255%.

• The computed generic relevance of files is now presented as a value.

File Carving

• Reduced the number of false file carving hits with presumed NTFS compression.

• If the file header signature search crashes when parsing the data starting from a certain sector, assuming a certain file format, previously only one such sector was remembered and automatically skipped when running the file header signature again. Now up to 8 such sector numbers are remembered, and they are stored in the evidence object properties instead of the volume snapshot, which means they do not get lost any more when taking a new volume snapshot. They can be seen and edited when clicking the new "..." button in the evidence object properties dialog window.

• File header signatures may now be optionally defined in the "File Type Signatures *.txt" files in direct (not GREP) notation, with the new flag "d". Useful for example if you are not very familiar with GREP notation or don't need GREP and just want to get all characters interpreted literally according to the code page that is active in your Windows system, without thinking much about whether the characters are considered special characters in GREP. For example, <?xml version="1 is a valid signature for certain XML files, but it works only with the new direct flag because the question mark has a special meaning in GREP, which results in a different byte value sequence for the signature internally if the entire expression is interpreted as GREP, and would not yield any matches if GREP interpretation is active.

• A new flag "L" in "File Type Signatures Search.txt" identifies links that merely link to other definitions. Useful for example to have an entry for OpenOffice files, which was missed by some users and whose absence could lead to the misconception that it is not possible to carve OpenOffice files with WinHex or X-Ways Forensics. If the entry for OpenOffice is selected for carving, this internally automatically selects zip archives for carving, which makes sense because OpenOffice files technically are zip files and can be carved as such. The disadvantage is just that other zip archives that are not OpenOffice files are also carved. However, those files will be distinguishable thanks to the internal file type detection, for example based on the automatically assigned filename extension.

X-Tensions API

• Defined flag to include comments and extracted metadata about files in evidence file containers.

• New X-Tensions API function: XWF_SetHashValue.

• Documentation updated.

Miscellaneous

• When importing hash values from NSRL RDS, if you categorize the hash set as irrelevant, hash values marked as special or malicious will be ignored (not imported). If you categorize the hash set as notable, only hash values that are marked as malicious will be imported. If you set the hash set to the uncategorized state, only hash values that are marked as special or have an unknown flag will be imported. If you wish to import all hash values, you can import the same NSRL hash set file three times, with different categorizations, and all hash values will end up in suitably categorized internal hash sets.

• Recover/Copy: Option to skip files if files with identical names already exist in the output directory.

• When starting up another instance, you are now shown which instances are already running with which cases loaded, and you can pick which exact instance you would like to analyze or recover, and you now have the option to kill a specific instance, just like with the Windows Task Manager (however, you can be more sure which instance you want to kill because you see the name of the loaded cases).

• Progress notifications are now optionally sent only if the workstation is locked, i.e. if the user has left his or her workplace.

• The Chinese translation of the user interface is now available with any license type.

• Many minor improvements.

• Some minor fixes.

• User manual and program help updated for v19.0.

Changes of service releases of v18.9

• SR-1: Fixed inability to convert certain old volume snapshots to the current format.

• SR-1: Fixed synchronization of report table associations for multiple examiners in the same case.

• SR-1: Fixed exception errors that could occur when viewing the SAM registry hive.

• SR-1: Inline files embedded in original .eml/.emlx files are now extracted and provided as child objects.

• SR-1: Avoided "Hash database not suitable for matching" error message in certain situations.

• SR-2: No longer ignores certain FILE records deleted by certain non-Windows NTFS file system drivers.

• SR-2: Fixed an instability issue that could occur when parsing certain olk14Message files.

• SR-2: Fixed problems with EDB database processing.

• SR-2: The Description filter option "list respective parent video as well" had a problematic effect when checked if the check box was invisible. That was fixed.

• SR-3: Fixed crashes that could occur when loading certain TIFF and olk14message files.

• SR-3: The creation of report tables for group IDs of files whose group permissions are different from the permissions of others (only v18.9) is now optional (see volume snapshot options), and should best be inactive when parsing Android Ext4* file systems because of the sheer number of defined user groups.

• SR-3: Quoted printable decoding in the alternative .eml preview now also for multi-part messages.

• SR-3: Creation timestamps in orphaned inodes of Ext4 file systems, where available, are now included in the volume snapshot.

• SR-4: Automatic hash verification of multi-segment images immediately after creation failed in v18.9 even though the images were fine. That was fixed.

• SR-5: In v18.6 SR-4 and later (but not v18.8), when trying to resolve conflicting categorizations in newly imported PhotoDNA hash values, the category of some existing hash values in the database may have been inadvertently changed. That was fixed.

• SR-5: Accelerated duplicate and consistency checks when importing huge PhotoDNA hash set collections.

• SR-5: PhotoDNA import logic generally slightly revised.

• SR-5: If during the import of a ProjectVic database it is discovered that the same picture is categorized as child abuse and child exploitation at the same time, this is still counted as an inconsistency, but such instances are no longer specifically brought to the user's attention. The first 10 encountered other conflicting classifications, if any, are still output in great detail, and the affected PhotoDNA hash values are now listed in Base64 notation instead of Hex ASCII, i.e. in the same encoding as used in ODATA JSON files for easier reference.

• SR-5: Classification inconsistencies are now reported also when importing X-Ways Forensics PhotoDNA hash databases.

• SR-5: Ability to import extracted metadata from evidence file containers as stored in containers by v19.0 and later.

• SR-6: The recommended data reduction no longer causes directory browser cells of red X files to be omitted from logical searches.

• SR-6: An exception error was avoided that could occur during assembler opcode interpretation by the Data Interpreter in v18.9.

• SR-6: Fixed a rare exception error that could occur when parsing .evt event log files.

• SR-6: The values of some integer fields in .evtx event log files were not output in the HTML previews. That was fixed.

• SR-6: With certain case report settings certain copied files were not linked. That was fixed.

• SR-7: A change of internal Windows behavior introduced with Windows 10 Anniversary Update caused instability when using Details mode. That effect is now prevented.

• SR-7: Fixed missing update of the gallery in certain situations when the listing of files in the directory browser was changed.

• SR-8: X-Tension API: A new flag (XT_PREPARE_TARGETZEROBYTEFILES) now allows an X-Tension to tell X-Ways Forensics that it wishes to be called also for files with a size of 0 bytes.SR-8: The "Other" option of the Owner filter did not always work correctly for files from file systems other than NTFS. That was fixed.

• SR-8: The option to jump to a specified absolute disk sector number within its respective partition did not work quite right if partitions overlapped. That was fixed.

• SR-8: Fixed problem of missing date in the 2nd timestamp column of weekly index.dat files.

• SR-8: Fixed an exception error that could occur when taking a snapshot of Ext3/Ext4 volumes with WinHex Lab Edition or WinHex with a specialist license.

• SR-8: Some other exception errors fixed.

• SR-9: In the registry viewer in v18.9 some rare values or keys were not displayed or triggered an exception error. That was fixed.

• SR-10: Fixed an exception error in the Export List command that occurred when not working with a case.

• SR-10: Fixed instability resulting from SQLite databases with 100,000 embedded binary objects or more.

• SR-10: Selecting values in the registry viewer that are stored beyond the first 64 MB of a registry hive did not update the block in the underlying data window and or the information in the lower right corner of the registry viewer. That was fixed.

• SR-10: Timestamps extracted from registry hives were not presented correctly to local time for the event list. That was fixed.

• SR-10: Fixed an exception error that could occur when running a file header signature search on a partitioned disk with overlapping partitions.

Thank you for your attention! We hope to see you soon somewhere on http://www.x-ways.net or on our Facebook page. You may also follow us on Twitter! 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 release of another notable update with many useful improvements, v18.9.

WinHex evaluation version: http://www.x-ways.net/winhex.zip (also the correct download link for anyone with a personal, professional, or specialist license)

Users of X-Ways Forensics/X-Ways Investigator/X-Ways Imager please go to http://www.x-ways.net/winhex/license.html for download links, the latest log-in data, details about their update maintenance, etc. Licensed users whose update maintenance has expired can receive upgrade offers from there. Note that licensed users of X-Ways Forensics and X-Ways Investigator with active update maintenance can conveniently find older versions for download from there if needed. Licensed users of other products can usually receive older versions on request (but not guaranteed).

Please be reminded that if you are interested in receiving information about service releases when they become available, you can find those in the Announcement section of the forum and (with active update maintenance) can subscribe to them, too, by creating a forum profile.

Please note that if you wish to stick with an older version for a while, you should use the last service release of that version. Errors in older releases of the same version may have been fixed already and should not be reported any more.

Upcoming Training

New York City, Jul 18-22
Washington DC area, Jul 25-28
Seattle area, Sep 26-29
Chicago, IL, Sep 27-30
London, England, Oct 11-14

Please sign up for our training newsletter here if you would like to be kept up to date on classes in the USA, Canada, Europe, and/or Asia/Pacific.

Viewer Component

A new version of the viewer component (v8.5.3) is available for download to licensed users of X-Ways Forensics and X-Ways Investigator with active update maintenance since May 5, 2016.

The major goals of this release according to Oracle are
* improved rendering fidelity in several key target formats,
* improved general font selection for all rendering products, and
* increased format coverage.

Other undisclosed customer requested enhancements and bug fixes are also included in the release, according to Oracle. The viewer component seems to be more stable with PDF files now.

v8.5.3 of the viewer component now requies the MS Visual C++ 2013 Redistributable Package instead of 2005, i.e. the same version also required by Dokan. The 2013 package is not necessarily found in all installations of Windows. Installing the v8.5.3 update is recommendable, but you may want to keep v8.5.2 with you for use in situations when you wish to run X-Ways Forensics on machines that are not your own, e.g. live systems that you need preview.

What's new in v18.9?
(please note that most changes apply to X-Ways Forensics only)

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:
  xwforensics64.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 changes to nearly all relevant file system structures, including a new Inode version with more timestamps, and new directory data structure variants.

• 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.

Thank you for your attention! We hope to see you soon somewhere on http://www.x-ways.net or on our Facebook page. You may also follow us on Twitter! 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 release of another notable update with many useful improvements, v18.8.

WinHex evaluation version: http://www.x-ways.net/winhex.zip (also the correct download link for anyone with a personal, professional, or specialist license)

Users of X-Ways Forensics/X-Ways Investigator/X-Ways Imager please go to http://www.x-ways.net/winhex/license.html for download links, the latest log-in data, details about their update maintenance, etc. Licensed users whose update maintenance has expired can receive upgrade offers from there. Note that licensed users of X-Ways Forensics and X-Ways Investigator with active update maintenance can conveniently find older versions for download from there if needed. Licensed users of other products can usually receive older versions on request (but not guaranteed).

Please be reminded that if you are interested in receiving information about service releases when they become available, you can find those in the Announcement section of the forum and (with active update maintenance) can subscribe to them, too, by creating a forum profile.

Please note that if you wish to stick with an older version for a while, you should use the last service release of that version. Errors in older releases of the same version may have been fixed already and should not be reported any more.

Upcoming Training

London, England, Apr 25-28
Miami, FL, May 23-27
Ottawa, Canada, May 24-27, 2016
Halifax, Canada, May 30-Jun 3, 2016
Kingston, Canada, June 6-10, 2016
London, England, Jun 14-17
London Heathrow, England, Jul 4-8
New York City, Jul 18-22
Washington DC area, Jul 25-28
Seattle area, Sep 26-30

Please sign up for our training newsletter here if you would like to be kept up to date on classes in the USA, Canada, Europe, and/or Asia/Pacific.

New videos

Quick Start Guides  •  Settings & Setup

What's new in v18.8?
(please note that most changes apply to X-Ways Forensics only)

File Format Support

• The type status "newly identified" was split up into "newly identified" (in a weaker sense, for example meaning that X-Ways Forensics had no idea about the file type before verification because the file didn't have any filename extension) and "mismatch detected" (which indicates a misleading filename extension, more suspicious). The type status "newly identified" from volume snapshots that were refined in previous versions is automatically adopted as "mismatch detected".

• File type signature definitions may now exploit the first 1024 bytes of a file (previously only the first 512 bytes).

• Identification of the zip subtype appx, which in newly initialized installations is now defined as part of the special interest group of archives (along with jar, apk, and ipa) and thus processed optionally.

• File type verification generally further improved.

• Chrome cache extraction revised and improved especially for large caches. Support for a recent extension of the file format. Support for multiple streams of the same cache entry: The HTTP response (named .chrome1) is output as well as, if present, as are compiled JavaScript entries (.js1). If a no-cache directive was sent by the web server, at least the HTTP response is still cached. In Preview mode you can see a special representation of HTTP responses.

• Chrome caches can now also be processed if their index is not available, for example if cache fragments have been carved or if the cache was partially deleted or corrupted. It may be possible in some cases that a better extraction result can be achieved without the index, even if it is present. To try that, if the index has not been processed before, you can have the uncover function process "data_4" files and omit the index. data_4 is now part of the optional "special interest" group.

• Firefox cache extraction revised.

• Algorithmic identification of URL-encoded ESC files from browser caches, and human readable representation in Preview mode. Contains metadata of video streaming services.

• Processing of iPhone backups of newer iOS versions as part of metadata extraction.

• File type "locky" is now defined, nowadays relatively widespread thanks to the ransom ware "Locky". Such files are automatically marked as encrypted for easier recognition.

• Extraction of ranks from jump list entries as well as from jump lists as a whole. These are floating-point numbers that are roughly proportional to the access frequency and therefore potentially relevant information. The ranks are computed by Windows.

• Specific support for jump lists of Windows 10, including a very recent new version.

• Support for the new thumbcache_idx.db format of Windows 10.

• Support for $I files of Windows 10.

• Prevented an infinite recursion in certain rare damaged registry hives.

• Ability to uncover embedded files from .p7m S/MIME files.

• Information about the audio sound quality in videos (sampling frequency and number of channels) is now extracted when capturing still images from videos. "No audio" is output if the video does not have audio. This allows to filter for videos that have or have no audio.

• File type category entry for .dash video streaming files in browser caches. It's an MP4 subtype, but needs to be converted to be playable with regular video players.

• Support for the new file type "service_worker", which is part of the new Chrome Offline Cache. Such files can now be type-checked, carved and metadata and embedded files can be extracted.

• File archives of additional types are now represented in the directory tree on the left once their contents have been included in the volume snapshot.

• Revised support for TAR archives. Ability to extract from certain TAR archives that could not be processed before. More exact representation of files in TAR archives. Faster processing, and caching of TAR archives in GZ archives.

• Ability to confirm and extract GZ archives with the "extra" flag.

• Revised internal file archive handling and fixed some rare errors. Improved processing of certain corrupt file archives.

• Greatly improved carving of XML files (almost all subtypes). Simplified XML definition in FTSS.txt and FTSCO.txt.

• Improved context sensitivity for better XML, CSV and Base64 file carving results.

• Rudimentary CSV file carving.

• File carving support for Microsoft ONE files.

• File carving definitions for OECustomProperty objects, which may contain e-mail metadata from MS Outlook, often stored as alternate data streams.

• Ability to carve fragments of Windows.edb from Windows 10 containing Internet browsing events (cf. "special interest" group).

Picture Support

• Ability to display incomplete JPEG pictures with progressive compression with the internal graphics viewing library.

• Fixed an exception error that could occur with certain corrupt or very large GIF pictures.

• JPEG generator signature representation revised. A plain text description is now provided in addition to the hex notation for almost all signatures.
  
  The generator signature is an experimental concept that can help identifying the origin of files of certain types. It is used in X-Ways Forensics for JPEG files. The signature is based on the JPEG quantization table and some other invariant features. It is output in Details mode and in the Metadata column.
  
  If the generating software library is identified, a textual description is included in addition to the raw hex signature. The most common JPEG generator is the IJG library, but there are more than 10,000 others. "Photoshop" und "Photoshop Web" are also common, for example. "Photoshop Web" identifies a JPEG file generated by Photoshop with optimization for use on the web. Other generators identified by X-Ways Forensics are iPhone, Apple 75, Apple 90, Kodak, Adobe Fireworks, Nikon, Sony, Blackberry, Canon EOS, Canon EOS fine, Canon norm, Canon fine, Canon superfine, Canon PowerShot, HP Scanjet, HP PhotoSmart, HTC, CASIO, Quicktime Med, ImageGear 84, and LEAD Technologies. The quality setting used to generate a JPEG file is also output ("Q=..."). That is a number in the range from 1 to 100 (for the regular Photoshop generator just between 1 and 12). The higher this value, the stronger the compression and the lower the image quality.
  
  Generator signatures are used in X-Ways Forensics to name carved JPEG files if no "better" metadata is available (e.g. camera model and timestamp from the Exif data). If the metadata extraction for existing files cannot find any "better" metadata, the generator signature at least allows you to identify groups of files that belong together because they likely have the same origin. Verifying whether the generator signature and available Exif metadata are consistent with each other may tell you whether a picture was edited and saved again.
  
  In particular the generator signature allows to identify files produced by scanners, as there are only a handful of generators commonly used in scanners. That allows to reliably identify scanned images even if they are not black and white or not 100% using gray scale colors only.

E-Mails

• Option to filter for recipients specifically on Cc: and Bcc: or just Bcc: or just To:, in e-mail messages and attachments where the recipients were extracted by v18.8. Useful for example if in your jurisdiction e-mails sent to a lawyer on Cc: or Bcc: are less protected by attorney-client privilege than e-mails addressed specifically to a lawyer.

• Metadata extraction from e-mail messages slightly more precise.

• Extracts e-mail messages and attachments from .olk14message files of MS Outlook 2011 for Apple Mac OS X.

• Quoted printable is now decoded in the alternative .eml preview/presentation.

• Fixed an exception error that could occur when extracting metadata from certain .eml files with malformed quoted printable encoding.

Case Report

• New CSS definitions supported for thumbnails in the case report (RTpicthumb and RTdocthumb, for thumbnails representing pictures and non-pictures, respectively).

• Option to limit metadata output in the case report to Name and Comment specifically for video still images.

• "Make copy of pictures for inclusion in report" will now also copy one still image per video if available and show it directly in the report to represent the video. The video itself is not copied with this setting, to save drive space, only if "Make copy of files for inclusion in report" is fully checked.

• Manual log entries now support Unicode. Option to output only manual entries in the log.

Usability

• The Recover/Copy dialog window has been more clearly structured. The option to embed e-mail attachments in .eml files no longer depends on the option to also copy child objects or on the explicit selection of the attachments, which makes it more intuitive and easier to use.

• New option of the Recover/Copy command to create a 2nd copy of all selected files in a separate directory. Useful if you need to provide two parties with copies of relevant files and wish to save time. The logging option is for the 1st copy only, though.

• When identifying duplicate files, pairs of duplicates in the same volume snapshot can now be optionally linked as so-called "related" items, so that it's easy to navigate from one such file to at least one duplicate. Excluding all duplicates but one in a group is now optional, too, and marking the files as duplicates in the Description column is also optional.

• Identifying duplicate pictures based on stored PhotoDNA hash values is now much faster than before, depending on main memory availability and number of processor cores.

• Disk imaging: You may now specify an overflow location in advance where further image file segments will be stored should space on the primary output drive be exhausted. If you leave that field blank or if even the overflow location has no more space left, you will be prompted for a new path as before when needed. If an overflow location is specified in advance and at the same time you chose to create two copies of the image, then please note that the overflow location is used only for the first image copy that runs out of space, if any. For the other image copy you would be prompted if space is scarce.

• Hash values of raw images that were created by X-Ways Forensics are now taken automatically from the accompanying descriptive text file if available and shown in the evidence object properties.

• The Description filter for still images from videos now has an additional option that allows to also list the corresponding video, directly preceding its stills. That way it is easy to see in the gallery which still images belong to which video, and you can comment on the video or add the video to a report table without navigating back and forth and without using the slightly less intuitive way to apply report table associations to an item that you cannot see (with the "for parent file" option). The tiles that represent the videos may act as visual delimiters if you disable auxiliary thumbnails in the gallery options, so that you can easily see where still images of the next video begin.

• Description filter for files that were indexed in X-Ways Forensics.

• When multiple users share an installation of X-Ways Forensics or X-Ways Investigator, with individual configurations in the user profiles, error.log files are now no longer created in the installation directory if it's writable, but in the user profile as well, in case other users are not supposed to see some of the metadata from evidence objects that may end up in the error.log file. Similarly, the msglog.txt file is now also created in the user profile if messages are output while no case is active (but still in the case's log subdirectory if a case is active).

• NOT option for the Name filter.

• Modulo setting for the internal ID filter now more flexible.

• Clicking the caption of the text column (where the name of the currently active code page is displayed in light gray) now allows to quickly change the active code page).

• If the text column shows text in a code page that is not the active code page in your Windows system and if you copy some data from the hex editor display into the clipboard, WinHex now asks you whether you would like the text to be converted from the code page active in the text column to UTF-16, for pasting in external programs.

• The advanced full path sort option is now a display option of the directory browser. It can still be used to achieve a sort order where child objects follow their respective parents, but now also has a visual effect in that the path now optionally includes the name of the object itself, for example if needed to copy it directly from the Path column in a single step.

• Option in the case properties to show the search term list in a single column next time when it is created. This enables you to scroll the list vertically instead of horizontally. Might be beneficial for example if your search terms are rather long.

Miscellaneous

• Evidence file containers now specifically remember the RVS status of the files that they contain, e.g. whether still images have been captured already from a video or whether embedded data already has been uncovered from a file. If you choose to accept and trust this status, which is a new volume snapshot option, these files will not be processed again if you decide to refine the volume snapshot of the container. You may occasionally not want to accept the RVS status of files in containers, to avoid missing something, if you suspect that the original examiner did not apply as thorough settings as you would or that they may have used an older, less capable version of X-Ways Forensics to process the files. Adopting the RVS status is also a must to get videos within a container represented in the gallery with rotating captured still images.

• When attaching external files to a volume snapshot, X-Ways Forensics can now optionally adopt the timestamps of these files as well (creation, modification and/or access), if you are sure that they are original and not the result of any file copy activity.

• The Data Interpreter now respects the Big Endian setting also for FILETIME structures. That is useful because FILETIME timestamps can be found in big endian in Windows Storage Spaces.

• Underflows and overflows in timestamp columns in the directory browser (timestamps outside of the supported range) are now marked with the text "out of bounds" and can be distinguished and properly sorted and filtered. (The supported range is May 5, 1829 through May 14, 2514.)

• Showing the file size in white tiles in the gallery is now optional, to reduce unnecessary screen cluttering for users who do not usually need this information.

• Now re-detects the file system of volumes without re-opening them when taking a new volume snapshot if sector superimposition is active.

• Ext journal parsing has been optimized. The result now looks better if the option is half checked, and that is the new default. Rare problems with a full selection of this option should not longer occur.

• Can now employ the fast search algorithm even when you get close to the maximum number of search terms per simultaneous search, i.e. around 8190. (Please note that the total number of accumulated search terms in a case is also limited to ~8190.)

• The X-Tension API function XWF_GetHashValue can now be used to retrieve PhotoDNA hash values if those were computed by X-Ways Forensics and stored permanently in the volume snapshot.

• The X-Tension API function XWF_GetItemType now allows to alternatively retrieve the category that the type of a file belongs to.

• Italian translation of the user interface updated.

• Many minor improvements.

• Some minor fixes.

• Program help and user manual updated for v18.8.

Changes of service releases of v18.7

• SR-1: If multiple images were added to a case simultaneously, they had to be closed and re-opened in v18.7 to get the volume snapshot taken. That was fixed.

• SR-1: File type recognition of certain lose Hotmail e-mails improved.

• SR-2: Fixed blank Owner column in v18.7 for NTFS file systems.

• SR-2: Fixed inability of 18.7 to maximize the detached lower half of a data window in most modes.

• SR-2: Edit box histories now accessible additionally by scrolling with the mouse wheel and by pressing the Down cursor key.

• SR-2: Fixed bad quality carving of NTFS-compressed files in recent versions.

• SR-2: Improved interaction with MPlayer.

• SR-3: Fixed inability of v18.7 to extract files from large GZ archives completely.

• SR-3: Avoided a condition in which no still images were captured from videos.

• SR-3: Fixed an exception error that could occur when extracting metadata from certain huge AVI video files.

• SR-4: The Unique ID filter now allows to enter a list of unique IDs consisting of up to 2,000,000 characters instead of 30,000 characters before. (Characters = digits, dashes, and line breaks).

• SR-4: Thumbnails in thumbs.db were extracted without original filename if the names were very long. That was fixed.

• SR-4: The Sender and Recipients filters are now applied to e-mail attachments again as well.

• SR-4: Fixed an exception error that occurred in v18.6 and v18.7 when ending the program if unlocked with a network dongle.

• SR-4: Fixed jump to wrong offset when clicking certain embedded files in Partition mode. Fixed incorrectly displayed 1st sector values for the same files.

• SR-5: Fixed an exception error that could occur in v18.7 when adding entries to the history of edit boxes.

• SR-5: The scope of the file header signature search on a physical, partitioned evidence object now includes very small auxiliary partitions that do not contain any known file system and that have not been added to the case as evidence objects.

• SR-5: Fixed an error that could occur when opening evidence objects without accessible disk or image.

• SR-5: When exploring archives with subdirectories without computing hash values at the same time, the primary hash value was set as all zeroes. That was fixed.

• SR-6: Fixed an exception error that could occur under certain circumstances when copying data from a data window with no directory browser.

• SR-6: Fixed an error that occurred in v18.7 when reading from reconstructed RAID5 systems with a missing component.

• SR-6: Fixed a potential exception error with CAB files that are smaller than 256 bytes.

• SR-6: Fixed a potential infinite loop when carving JNX files.

• SR-6: Fixed a rare volume snapshot anomaly where the files of a certain directory became part of "Path unknown" although the path should have been known to X-Ways Forensics.

• SR-6: Fixed a rare exception error that could occur in the Export List command in the registry viewer.

• SR-7: Fixed inability to import PhotoDNA hash values from certain current ProjectVic ODATA JSON files.

• SR-7: Some other aspects of PhotoDNA hash value imports improved.

• SR-7: Fixed a miscategorization issue when importing conventional hash values from certain current ProjectVic ODATA JSON files.

• SR-7: Ability to import hash values from JSON files belonging to previously unexpected, newly defined category numbers 4 and 5.

• SR-7: Avoided certain unnecessary messages about corrupt directory entries in exFAT.

• SR-7: More convenient option to have a user-specific configuration only for selected users of a shared installation, by creating an empty file named winhex.user.[username] in the installation directory for every user that shall be allowed to maintain his or her individual configuration, while using a shared configuration for everyone else, e.g. using a write-protected general WinHex.cfg file with predefined settings as deemed appropriate for your organization.

• SR-8: Ability to import hash values from current Project Vic/Hubstream ODATA JSON files.

• SR-8: Accepts category numbers up to 9 in ODATA JSON files.

• SR-8: Search hits in the case report could be empty or garbled depending on the Export List options for search hits. That was fixed.

• SR-8: Fixed an exception error that occurred when running a logical search immediately after removing items from the volume snapshot.

• SR-8: Prevents annoying, lengthy and unnecessary font cache initialization in MPlayer versions from 2015.

• SR-8: Alternative e-mail preview: Fixed encoding error in the header representation at the bottom.

• SR-9: Fixed an exception error that could occur in v18.7 when extracting metadata from XML files.

• SR-9: Fixed a rare floating point exception error that could occur when dealing with timestamps in certain formats.

• SR-9: Less false positives and fast processing of full file encryption test.

• SR-9: BLOBs (binary data chunks) are now also optionally provided as child objects for SQLite database of an unknown purpose/subtype.

• SR-10: Now preserves the original filename extension when naming original single .eml files after their subject lines.

• SR-10: Support for .evtx event log files larger than 2 GB.

• SR-10: Fixed problems with PhotoDNA hash databases that contain no hash values.

• SR-10: Fixed output of Boolean values in BPLists.

• SR-10: More stable when processing corrupt BPList files.

• SR-10: Prevents occurrence of zeroed out primary hashes in volume snapshots in certain situations.

Thank you for your attention! We hope to see you soon somewhere on http://www.x-ways.net or on our Facebook page. You may also follow us on Twitter! 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 release of another notable update with many useful improvements, v18.7.

WinHex evaluation version: http://www.x-ways.net/winhex.zip (also the correct download link for anyone with a personal, professional, or specialist license)

Users of X-Ways Forensics/X-Ways Investigator/X-Ways Imager please go to http://www.x-ways.net/winhex/license.html for download links, the latest log-in data, details about their update maintenance, etc. Licensed users whose update maintenance has expired can receive upgrade offers from there. Note that licensed users of X-Ways Forensics and X-Ways Investigator with active update maintenance can conveniently find older versions for download from there if needed. Licensed users of other products can usually receive older versions on request (but not guaranteed).

Please be reminded that if you are interested in receiving information about service releases when they become available, you can find those in the Announcement section of the forum and (with active update maintenance) can subscribe to them, too, by creating a forum profile.

Please note that if you wish to stick with an older version for a while, you should use the last service release of that version. Errors in older releases of the same version may have been fixed already and should not be reported any more.

Upcoming Training

Austin, TX area, Feb 22-Mar 1
London, England, Feb 29-Mar 3
London, England, Mar 15-23
Washington DC area, Apr 5-8
Southern California, Apr 11-19
Miami, FL, May 23-27
Ottawa, Canada, May 24-27, 2016
Halifax, Canada, May 30-Jun 3, 2016
Kingston, Canada, June 6-10, 2016
London, England, Jun 14-17

Please sign up for our training newsletter here if you would like to be kept up to date on classes in the USA, Canada, Europe, and/or Asia/Pacific.

What's new in v18.7?
(please note that most changes affect X-Ways Forensics only)

File Format Support

• Revised hiberfil.sys support for 64-bit Windows.

• hiberfil.sys slack (compressed data from previous usage of a hiberfil.sys file, as found near the end, if the last usage achieved stronger compression than the previous usage) is now automatically extracted and decompressed as part of "Uncover embedded data in various file types" and provided as a child object in its decompressed form.

• Accuracy of file type verification further improved. Fewer file types with generic extensions are now unnecessarily marked as "newly identified", but confirmed if the full filename is appropriate for the file type.

• Verification of many more file types supported. In total the file type verification can now recognize more than 3,000 file types.

• File carving methods implemented for .cwm (screen capture videos) and Windows 8's .accountpicture-ms files. .accountpicture-ms files are now by default targeted for uncovering embedded files.

• Type verification supported for .thumbdata3 files (Android files that are found for example on SD cards).

• E-mail extraction adjusted in such a way that certain Base64-encoded e-mails are shown correctly by external programs after Recover/Copy.

• Support for certain old Outlook PST e-mail archives with previously unsupported text encoding. Requires that you select the correct regional ANSI code page in the case properties and check the unlabelled box next to it, the one that has a tooltip saying "Assume this code page in Outlook PST".

• If e-mail messages have a Sender: line in addition to a From: line, then the sender according to the Sender: line is now shown in the Sender column of the directory browser additionally, after the From: sender, if actually different. They are delimited by spaces and a pipe (|). For example, an English language MS Outlook shows such e-mails as having been sent "on behalf of" someone else (by the Sender: sender on behalf of the From: sender). You can filter for such e-mails by entering a pipe as a substring for the Sender column. Analogously, different kinds of recipients ( To:, Cc:, and Bcc: ) are now delimited by pipes in the Recipient column.

• Fixed a potential exception error that could occur when processing damaged OLE2 compound files.

• Prevents crashes when dealing with certain EDB databases.

Picture Support

• Gallery screen space is now much better utilized as thumbnails are no longer forced to be squares. You can now specify your preferred thumbnail width and height separately, in the Options | Viewer Programs dialog. The specified dimensions will be dynamically adjusted (increased) to best fill the available screen space without partial thumbnails being visible. Since most photos and practically all videos are shot in landscape format, you may want to select width and height accordingly (width larger than height) when viewing pictures. Document thumbnails can often be freely adjusted to any rectangle shape, for example those representing word processing documents or spreadsheets, but not presentations. For most documents other than presentations, portrait format feels like a more natural way of representation. The aspect ratio of the width and height that you specify is displayed in the options dialog to quickly give you a rough idea how compatible the measures will be with ordinary photos, videos or documents.

• Previews and views of pictures (with the internal graphics library, not the viewer component) now additionally show the names of associated report tables in the upper left corner and the names of matching PhotoDNA categories in the lower right corner.

• As part of the volume snapshot refinement, X-Ways Forensics can generate thumbnails of high-quality digital photos to accelerate the gallery. It is now possible to select the resolution (maximum width or height in pixels) and quality (JPEG compression factor) in the user interface. However, the maximum amount of data that can be stored in the volume snapshot for a thumbnail is limited, to 64 KB, so if a generated thumbnail gets larger than that, X-Ways Forensics will automatically reduce the user-defined resolution accordingly.

• New internal report table for animated PNG pictures.

• Extraction of embedded data in PNG files (e.g. GIF pictures) supported.

• New internal report table for PNG pictures that are likely mobile device screenshots. That assumption is based solely on typical smartphone screen resolutions. Useful in case such screenshots do not have the typical filenames (if they were carved, received via apps, copied to other media and renamed by the user, or takes by certain apps and stored in the cache of that app).

• Fixed slight and rare inaccuracy in the representation of GeoTagging coordinates of JPEG files.

Video Processing

• A new context menu command has been introduced to extract all frames specifically from a defined section of a selected video. Useful if a certain part of a video is of high interest and you need to carefully check visual details in certain frames or include them in the report. You can specify how many consecutive frames to extract and starting from which second. The number of frames that you need to cover a certain period of time can be deducted from the frame rate as shown in the Metadata cell (fps = frames per second). Please note that the start second may be interpreted very roughly only, depending on the frequency of keyframes (a.k.a. I-frames in MPEG) in the video. MPlayer can seek into a video file only based on keyframes. If for example a certain video file contains keyframes only every 4 seconds for example, then the start second of the extraction may be off by up to 4 seconds. Keep this in mind when you enter the number of frames that you need or the start second. That is, to be on the safe side, extract more frames than you may actually need and perhaps from an earlier start second.
  
  The frames are saved as JPEG files in a directory of your choice on your own drive, where you can review them outside of X-Ways Forensics. If you like, you can of course attach the most relevant frames to the original video file in the volume snapshot as child objects. The frames are not stored within the volume snapshot by default so that the size of the volume snapshot does not unreasonably inflate with potentially mostly irrelevant and redundant pictures. If the output directory already contains extracted frames, files with identical relative frame numbers will be overwritten. Relative frame numbers always start with 00000001 for each extraction and increment with each frame. You may adjust the JPEG compression if necessary for stronger compression or better quality. (Of course you usually cannot expect a very good quality because videos are typically highly compressed already.) The volume snapshot refinement operation to produce representative still images from videos (sporadically, in certain larger intervals) has been renamed to point out the difference from the new context menu command for exhaustive frame extraction.

• More metadata is now extracted from videos when exporting stills, usually coding/compression format, resolution, bits per pixel, frames per second, data rate per second for video data.

• A new 64-bit edition of MPlayer from 2015 is now downloadable from the web server in addition to the 32-bit edition from 2014. The only video extraction program supported is now MPlayer.

File System Support

• Enhanced Attr. filter settings for Unix style file permissions. You can now filter for any of the 9+3 bits specifically and combine them with OR, AND, or EQUAL. EQUAL requires a status of all 12 bits exactly as selected (whether set or not set). AND means you require ALL of the checked bits to be set, but don't care about the others. OR means you are satisfied already if ANY of the checked bits is set. SUID and SGID bits can now be combined with a logical OR or AND as well (previously they were always OR'ed). Please remember that if you are interested in directories with the sticky bit, you will need to include directories when exploring recursively and apply filters to directories, too (not the default setting). Please note that the logical operator for permissions should not be usually set to EQUAL because that will result in active filtering for permissions even if no permission bits are selected in the dialog box at all, unlike the OR or AND operators. EQUAL with no permission bits selected means to filter for files that have no permission bits set or files whose permissions are unknown.

• iNode* files (indirect node files) in HFS+ now point to one of their hardlinked counterparts as a "related item" in the volume snapshot, so that it is very convenient to locate at least one of those hardlinks and see the actual use and location of the file. To find other hardlinks for the same iNode* file, you can for example sort by the column "1st sector".

• HFS and HFS+ resource forks are now presented as child objects, analogously to alternate data streams and extended attributes in NTFS.

• Attribute filter for resource forks added.

• Loose $MFT files can now be directly and conveniently interpreted as if they were NTFS volumes, to get at least a full listing of all files and directories, with their paths, timestamps and attributes. It's possible to open resident files (files whose contents is small enough to fit into the FILE records), but no other files, of course. Useful if in special situations all you have is the $MFT, not the entire volume. Also useful for example for $MFTs from volume shadow copies.

• Option to omit additional hard links for the same file in NTFS/HFS+ from volume snapshot refinement just as from logical searches previously, to save time and reduce the number of redundant identical child objects etc. This can make a big difference on partitions with Windows installations that have a lot of hard links and HFS+ partitions with Mac OS X Time Machine. Which hard links are considered the "additional" hard links internally can be seen in the "Link count" column as before (gray number means to be omitted) and now also in the Description column, which identifies all hard links (i.e. files with a hard link count of 2 or more) and the additional ones in particular textually. The hard link that is not marked as "optionally omitted" in the Description column is considered the "main" hard link internally.

• Rename events from $J and fragments thereof are now output to the event list.

• Files with only partially initialized contents (valid data length < logical file size) are now marked in the Attr. column with the # sign, and an explanation of the # sign can be found in the legend.

• In newly refined volume snapshots, the "1st sector" column now points out that certain figures are approximate, for example for embedded files, using gray color and a tilde.

• When clicking a file in Partition/Volume mode, the jump to the start of the data of certain files is now more precise, for example for resident files in NTFS it leads directly to the body of the 0x80 attribute and for certain embedded files directly to the start of the data. Sorting by the "1st sector" column reflects the physical start location of files more precisely now for certain unaligned files.

• Finds more sessions of multi-session CDs/DVDs with CDFS immediately, without having to run a particularly thorough file system data structure search.

• Avoids session duplication on CDs/DVDs with CDFS where additional sessions are found only through a particularly thorough file system data structure search.

Disk & Image Support

• Tentative support for older VirtualBox VDI virtual disk images from Sun Microsystems.

• Prevented an error that could occur in simultaneous computation of two hashes when imaging media in very special configurations that involve a specific hardware write blocker model and Windows version. The data in the images was OK anyway.

• Reports the total number of unreadable sectors in the disk imaging log in addition to the affected sector ranges.

• Imaging now aborts after media disconnect error.

Case & Report Settings

• Smaller versions of pictures can now optionally be generated specifically for the report, to greatly reduce the memory requirements of the Internet browser or word processing application when loading the HTML report, and to accelerate loading. This can make a big difference for reports with many high-resolution photos. The JPEG compression factor is user-definable. The resolution depends on the specified "maximum dimensions of pictures".
  
  The checkbox that represents this option is a 3-state checkbox. If half checked, the smaller versions of the pictures are used only for the preview directly in the HTML report. If fully checked, even when clicking the picture in the report you will only see the smaller version, and the original larger file is not included in the report at all. This can be beneficial if your main concern is the drive space requirement of your report with linked files, not the output quality of pictures.

• The report can now optionally also show previews/thumbnails of non-picture files, e.g. Office documents, e-mails, web pages, programming source code, etc. etc., similar to the gallery. You can shrink the preview representation slightly or a lot or not at all, to either be able to read some of the text right in the report without opening the document or to get a better impression of the overall formatting of the text and just see logos etc.

• If you output one specific report table in the case report, the suggested report name is now automatically based on the name of that report table.

• In the properties of a case you can now specify whether you prefer to have X-Ways Forensics use the case-specific directory of temporary files (the _temp subdirectory of that case) instead of the general one, when that case is active.

• Purely physical user search hits (defined in Disk/Partition mode, not File mode) can now also be output in the report, in the section about the evidence object to which it belongs. File-related search hits are still output in the report table section about that file along with all the selected metadata. If the file that a search hit selected for the report belongs to is not output with a report table, the search hit can now be seen in the section about the evidence object.

• Option to output incrementing numbers in the case report, for each item in a report table, to uniquely identify a file in that report.

User Interface

• All edit boxes throughout the program (except for password edit boxes and column width boxes) now remember a history of up to 10 last entries. The history can be seen when clicking the tiny button that appears in an edit box for which a history is available. Alternatively, you can press the F4 key just like in a normal drop-down box (combo box). If you select a previous entry from the pop-up menu, it will be inserted into the edit box automatically. Users who wish to delete these histories or pass them on to others, please be advised that they are stored in the file History.dat when the program is ended. If you do not wish to keep histories between sessions, you can create an empty file named History.dat yourself and render it read-only.

• A new keyboard shortcut, Shift+Ctrl+Del, allows to remove matches with ordinary hash sets, FuzZyDoc hash sets, and PhotoDNA categories from selected files in the volume snapshot, which even if the hash sets are deleted from the hash database are not discarded otherwise.

• Pressing Ctrl+C in the directory browser now copies the textual data of the selected items into the clipboard, with the same notation as in the directory browser itself, otherwise similar to the Export List command.

• The colors of tag marks (if they are not represented by check marks) are now slightly different, and they are now user-definable in Options | Directory Browser. Useful for example if you prefer stronger colors or if the default colors conflict with pictures that you are viewing in the gallery (e.g. many outdoor photos with blue sky at the top). If you liked the slightly more unobstrusive colors of previous versions, you can get them back manually: Color 1 = RGB 225, 225, 255 (for the upper left corner) and Color 2 = RGB 163, 163, 255 (for the lower right corner).

• The colors that mark files as already viewed are now user-definable as well, via Options | Viewer Programs | Keep track of viewed files | .... If you liked the colors of previous versions, you can get them back manually: Color 1 = RGB 233, 225, 223 (for the upper left corner) and Color 2 = RGB 145, 250, 103 (for the lower right corner). In v18.7 they have been simply swapped.

Search Functions

• The "1 hit per file needed only" option of the logical simultaneous search now no longer skips the slack of a file once a hit in the logical part has been found if "Open and search files incl. slack" is fully checked. It will check the slack for at most 1 additional hit as well.

• Lists purely physical user search hits in the case root window, even if in that window you cannot navigate to the sector contents by clicking the search hits.

• There is now an option to limit the search for lost partitions on physical media to the sectors that follow the current cursor position.

• Fixed misinterpretation of literally specified # character in square bracket sets in GREP expressions.

• Prevents overlapping GREP search hits in directory browser cells.

Miscellaneous

• When excluding duplicates based on hash value or name, X-Ways Forensics now prefers to keep the copy whose owner is known.

• Recover/Copy and Create Report now even name embedded .eml files after their unique ID if the corresponding option is selected.

• Lifted internal limitation on the amount of data extracted from files per volume snapshot (previously 1 TB). Volume snapshots saved by v18.7 cannot be opened in v18.6 and earlier any more.

• Larger files can now be attached to the volume snapshot.

• For the record presentation of the hex editor, records are now numbered starting with 0 instead of 1 by default. 1-based record numbers are still available optionally. The record size is now specified in hexadecimal if hexadecimal offsets are active in the user interface.

• New X-Tension API function GetEvObj().

• Ability to convert assigned hash sets to report table associations, in the dialog window for report table associations, where you can also convert contained search terms to report table associations. This can be useful for example if you wish to recreate your hash database from scratch or delete your hash database, and do not only wish to preserve the hash category of known files in the volume snapshot, but also the exact matching hash set names. Also useful if you wish to add files to an evidence file container and wish to let the recipient know the original hash set matches, not only the hash category. These auxiliary report tables are highlighted in a different color to distinguish them from 1) ordinary user-created report tables, 2) internally created report tables that make the user aware of something special, and 3) search term based report tables. Associations with hash set based report tables can also be created on the fly when copying files to an evidence file container.

• Including comments and/or report table associations of files in an evidence file container is now optional for each copy action and does not have to be decided up front once and for all when creating the container.

• The main executable files are now digitally signed.

• Windows 10 is now officially a supported platform.

• Many minor improvements.

• Some minor fixes.

• Program help and user manual updated for v18.7.

Changes of service releases of v18.6

• SR-1: Improved FuzZyDoc matching results for PDF documents.

• SR-1: Time zone awareness of timestamps now defined on a per-file basis in exFAT.

• SR-1: Ability to find the virtual allocation table of virtual UDF partitions on certain non-standard (incomplete) disk images as produced by other software.

• SR-1: Fixed an exception error that occurred in v18.6 when carving files in a data window that represents a single file with no volume snapshot and no directory browser.

• SR-1: Fixed effect of unselected "List internal file system files" option for files in archives.

• SR-1: Fixed unsuccessful conversion of certain Base64 code.

• SR-1: Prevented an extremely rare exception error that could occur when matching hash values against the hash database.

• SR-2: Fixed inability of X-Ways Imager 18.6 to image disks.

• SR-3: Fixed occasional incomplete extraction of embedded JPEGs in PDF documents.

• SR-3: Fixed potential time zone information error in the properties of evidence objects with a Windows installation.

• SR-3: Fixed an exception error that could occur with certain corrupt Zoom Browser files (Canon).

• SR-4: Fixed time zone conversion in the second column of previews of certain index.dat files.

• SR-4: Fixed occasional incomplete exclusion of duplicates based on hash values.

• SR-4: Deduplication of multiple very similar PhotoDNA hash values now even when importing them into an empty (newly created) PhotoDNA hash database.

• SR-4: Since v18.6, if a new PhotoDNA hash value is close enough to be considered a match for an existing one, but different enough to warrant a separate entry in the PhotoDNA hash database, the existing entry is updated and the new one added. This double entry previously did not happen if both similar hash values were added during the same import operation, but now does.

• SR-5: Fixed size detection of Ext* partitions larger than 2^32 blocks in situations where they are not referenced by any partition table.

• SR-5: Fixed memory leak in HFS file system support.

• SR-5: Fixed inability to deactivate all filters with a single mouse click in SR-4.

• SR-6: Fixed an exception and instability error that could occur when extracting metadata from certain documents in OLE2 format.

• SR-6: In Ext4 file systems, some very rare files with uninitialized parts were previously read with partially incorrect data. That was fixed.

• SR-6: Fixed parsing of FAT32 file systems with cluster sizes of 128 KB or more in X-Ways Forensics.

• SR-6: Ability to show rough pixel counts for pictures that have PhotoDNA database matches.

• SR-6: investigator.ini options related to the new Description filter did not work in v18.6. That was fixed.

• SR-7: Fixed a rare exception error that could occur when generating HTML previews of files of certain types.

• SR-7: Fixed potential inability to select thumbnails in the gallery while viewing pictures with the viewer component.

• SR-7: Improved stability for processing of SQLite databases.

• SR-7: Improved imaging behavior after media disconnect error.

• SR-7: Prevented way around investigator.ini option +51 in v18.6.

• SR-8: Fixed potential incomplete listing of partitions in the directory browser when more than one partition was semi-automatically detected starting from the sector pointed at by the user.

• SR-8: Fixed an error that could occur when reading from partitions with a file system based on a sector size different from the sector size of the physical disk.

• SR-8: Fixed incorrectly displayed file size for huge files in UDF file systems.

• SR-8: Fixed a rare error in symlink resolving.

Loss of Dongles

There are still a few customers who ask about a replacement for lost dongles even if their dongles were not insured, although we and the X-Ways Forensics software itself have confirmed over and over again that we do not offer replacements for lost dongles if not insured, because these dongles can still be used to unlock the software, by whoever, even by yourself it the dongles show up again. With immediate effect, we will ignore requests for dongle replacements if no insurance was in place. We provide only 1 dongle per license, not as many dongles as customers would like to have.

Viewer Component

Oracle has provided a "critical patch update" for v8.5.2 of the viewer component. The updated version is downloadable from our web server. It is probably recommendable for security reasons.

Oracle's description of the patch update as always claims to have information about what was fixed, but doesn't:

What this Update Fixes:
January 2016 Critical Patch Update for Outside In
This patch is cumulative with all previous Outside In 8.5.2 Critical Patch Updates

A 3rd party web page describes the fixed security issue as follows: "A local user can exploit a flaw in the Oracle Outside In Technology Outside In Filters component to cause partial denial of service conditions." The only file that has actually changed is sccfnt.dll. That file is responsible for fonts.

Thank you for your attention! We hope to see you soon somewhere on http://www.x-ways.net or on our Facebook page. You may also follow us on Twitter! 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.