|#153: X-Ways Forensics,
X-Ways Investigator, WinHex 19.1 released
Jan 19, 2017
This mailing is to announce the release
of another notable update with many important improvements,
WinHex evaluation version:
(also the correct download link for anyone with a personal, professional, or
Customers may go to
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.
NEW: If when querying your licenses you do not
receive any e-mail message at your work address because your organization
is blocking the sending server, you now have the option (here)
to get the e-mails sent from an alternative server (different domain,
different IP address), for a second chance to actually receive something.
Please be reminded that if you are interested in receiving information about
service releases when they become available, you can find those in
Announcement section of the
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.
|Feb 27-Mar 2
||X-Ways Forensics, X-Ways Forensics II
||X-Ways Forensics II
||Washington DC area
||X-Ways Forensics II, XFS
||New York City
||X-Ways Forensics, NTFS/XWFS2
Please sign up for our training newsletter
if you would like to be kept up to date on classes in the USA, Canada, Europe,
What's new in v19.1?
(please note that most changes
X-Ways Forensics only)
File Type Support
Support for Google's Chrome sync database, where
information can be found that is synchronized across devices, such as
bookmarks, form history, typed URLs, synced devices and much more. A
preview HTML file is generated, and events are output to the event list.
Ability to view upside-down Bitmap pictures with the
internal graphics display library and in the gallery. (To see them
flipped vertically, you currently have to view them with the viewer
TAR archive processing revised.
Fixed inability to process BZ2 archives.
More reliable detection of pictures as screenshots
(output as report tables "Screenshot" and "Screenshot?").
New report table "Scan" for PDF and JPEG files that
contain a scan. The detection is based on generator signatures
"PDF/Scan" and "JPEG/Scan".
Most JPEG pictures that were transcoded by Facebook
and downloaded from Facebook are now identified as such in the Metadata
column by their generator signature.
PDF metadata extraction improved especially for
Acrobat 10 PDF files.
Tentative extraction of Exif metadata fields that are
damaged in a certain way.
Revised metadata extraction for JPEG. ICC profiles
are evaluated, including timestamps.
New file type signature for .0tx Tobit e-mail
Generator signature table further revised.
The type status "mismatch detected" now has an effect
on the assumed relevance of a file.
The relevance of a file now more reliably takes into
account whether or not a picture is a screenshot.
Improved stability while processing EDB databases.
Users of v18.8, v18.9, and v19.0 may replace their copy of the file
EDBex.dat with the new version that at first is tentatively included in
Sender and recipients are now also shown for MSG
files to which e-mail processing was applied, not only for the extracted
File System Support
Extended attributes in HFS+ are now optionally
included in the volume snapshot as child objects of the files or
directories to which they belong (in X-Ways Forensics only) depending on
a new 3-state volume snapshot option. If fully checked, extended
attributes are presented as child objects even when they have been
specially interpreted already by X-Ways Forensics internally. If half
checked (default setting in X-Ways Forensics), they are presented as
child objects only if they are not specially interpreted by X-Ways
Forensics assuming that the user might want to check them out manually.
Ability to open files with resident/inline storage in
Ability to recognize and open compressed files in
HTML previews are now generated during metadata
extraction for the GZ archives that contain Apple FSEvent logs.
Event extraction from Apple FSEvent logs.
Recognition of new file system level compression
style in NTFS under Windows 10.
In newly taken volume snapshots, alternate data
streams now show hard link counts in the same way as their parents, so
that the alternate data streams of additional hard links can be
optionally omitted from searches etc.
The descriptive text file that is generated for
images now points out the exact sizes in bytes of all segments of raw
images files and the exact chunk counts in all segments of .e01 evidence
files. If for whatever reason one or more segments get lost or
corrupted, this allows to create artificial placeholder segments of the
right capacity to fill in any gaps, such that all the data in subsequent
segments will have the correct logical distance from the data in
preceding segments, to preserve validity of pointers within the data
(partition start sectors in the partition table, cluster numbers in file
system data structures) as long as the original image file segments that
contain source and destination are available.
Ability to conveniently create dummy/makeshift
segments for .e01 evidence files that can substitute
missing/lost/corrupt original segments, with the File | New command. The
user specifies the required chunk size and the number of chunks as well
as a filename for the desired segment (must be with the correct
extension, identifying the segment number, not number 1). The data
written into the chunks is a recurring textual pattern ("MISSING IMAGE
FILE SEGMENT!" when running X-Ways Forensics in English), so that you
know that you are looking at a gap in between available data when
browsing the interpreted combined image later. The idea of such an
artificial dummy segment is that if correctly created it can serve as a
placeholder that ensures that data in subsequent segments has the
correct logical distance from the data in preceding segmented. Of
course, the hash of the entire image cannot be successfully verified any
more if the original data is not present, and of course, this
functionality should be used only as a last resort if there is no backup
of the missing segment file and if data recovery fails etc., and
creation and usage of such a dummy image file segment should be properly
documented. (forensic license only)
When interpreting an .e01 evidence file that contains
dummy segments, you will be notified, and the total number of
placeholder chunks are noted in the evidence object properties when the
image is added to the case.
If you require a placeholder for a single missing
segment of which you don't know the chunk size and chunk count because
the image was created without the new information in the descriptive
text file, this is how to find out: Change the filename extension of the
penultimate segment to that of the missing segment so that there is no
gap. Then rename the last segment to the now missing penultimate
segment. (If the missing segment actually is the penultimate one, the
last step is sufficient; if the missing one is the last, no renaming is
required at all.) Then add the image (first segment) to a case in X-Ways
Forensics as usually. X-Ways Forensics will bring the misnamed segment
to your attention in the Messages window, which can be ignored. Check
the evidence object properties for the chunk size as well as the
expected chunk count and the actually referenced chunk count. Subtract
the actually referenced chunk count from the expected chunk count. Now
you know how many chunks are missing. Change the filename extension back
to what it was before, and then create the missing dummy segment with
the correct chunk size, correct chunk count, and correct extension.
With a variation, this approach also works if multiple consecutive
segments are missing, just you rename more available segments to fill
the gap in the first step, and you create as many dummy segments as
necessary to fill the gap. Which dummy segment exactly contains how many
surrogate chunks is not important as long as the total number of
surrogate chunks must account exactly for the total number of missing
chunks. If multiple discontiguous segments are missing, suitable dummy
segments can only be created with the new information from the
descriptive text file.
Volume Snapshot Refinement
Multi-threading: Option to set the number of worker
threads to 1, which means that one extra thread is started for
processing, separate from the main thread, so that GUI interaction is
possible without time lag. Useful for example on a terminal server with
many concurrent users, where you should not start too many threads, but
may want to be able to at least use the GUI quickly. If the number of
additional threads is set to 0, that means processing is done like in
v19.0 with 1 thread or generally in v18.9 and before by the main thread
itself, so that GUI interactions may be slow.
Ability to pause multi-threaded operations with the
It is now possible to omit not only known irrelevant
files, but also known relevant files from further volume snapshot
refinement. Useful for example if in large cases you have or expect
really many such files and having proof of their presence is sufficient
for you and you don't need to extract their internal metadata, don't
need to compute their skin tone percentages or PhotoDNA hashes, and
don't need to check them for embedded data etc.
If matches are returned from regular hash databases
as well as the PhotoDNA hash database at the same time with conflicting
categorizations, the "more severe" category prevails: unknown < known
good < known, but uncategorized < known bad
The option to mark a file as already viewed when it
gets categorized as irrelevant is now applied to the combined result of
ordinary hash database and PhotoDNA hash database matching.
Internal metadata is now extracted into the Metadata
column only from files of selected categories.
Options | Security | "Collect information for crash
report" is now a 3-state check box. If fully checked, should volume
snapshot refinement crash the program, restarting the program will also
point out which suboperation exactly was applied to the problematic
file(s) when the program crashed. It has not been tested whether this
enhanced granularity of logging might cause any noticeable slowdown.
There may be multiple candidates for the problematic file that triggered
the instability if multiple worker threads were active at the time of a
crash. Unlike in v19.0, all of them are now logged, and they are now
presented with the help of the Int. ID filter upon restart.
When checking for duplicate files based on hash
values, identical files can now optionally be grouped in dedicated
report tables so that you can conveniently list each group of duplicates
in the directory browser with the report table filter, for example to
find out which copy of the file was created first, which was was touched
last, which one might be of most evidentiary value based on metadata
such as path etc. Unlike marking duplicates as so-called related items,
report table grouping works even across evidence object boundaries, so
you are not limited to comparing duplicates within the same evidence
Report tables that represent groups of duplicate
files are highlighted in turquoise. In total there are now 5 different
kinds of report tables: 1) user-created report tables, for example for
report purposes, 2) report tables created by X-Ways Forensics to make
the user aware of special properties of files, 3) report tables
representing search terms that are contained in a file, 4) report tables
representing hash sets in which a file was found, 5) report tables
representing groups of duplicate files.
The maximum number of report tables in a case was
increased from 256 to 1000.
To avoid a bloated list of report tables available
for selection during report creation, report tables are now offered in
that dialog window only if they are actually intended for report
purposes. That is assumed by default for all user-created report tables.
And you can toggle the report purpose of each report table in the report
table association dialog window, by assigning or removing the "star"
When taking a new volume snapshot, all report table
associations in that evidence object are discarded. If that completely
empties a report table that is not marked as intended for report
purposes, such a report table will now be automatically deleted from the
case at that occasion.
Usability & User Interface
Options | Viewer Programs now offers grayscale
thumbnails for true-color pictures in the gallery. This option is meant
for law enforcement users whose job is to review child pornography
photos, to reduce the mental impact and stress level.
A new 3-state check box in General Options prevents
Windows screensavers from starting and potentially requiring to re-enter
the current user's password, either only during operations that show a
progress indicator window (if half checked) or generally while the
program is running (if fully checked). This option has an effect no
matter whether the main window is visible or whether the program is
running in the background. Useful for example when acquiring a live
system of which you don't want to lose control during imaging, or if you
wish to keep an eye on the progress indicator on your own machine from
another corner in your office.
More user-friendly behavior when trying to change the
edit mode in data windows where that is not allowed because of not
running X-Ways Forensics as WinHex or because of the strict drive letter
Convenient option to automatically open the output
directories of Recover/Copy after completion.
In Edit | Define Block it is now optionally possible
to enter the size of the block instead of its end offset. And it is now
possible to enter the start and end of a block in terms of sector
numbers instead of offsets directly.
The option to use the viewer component also for
pictures is now presented as an easy-to-reach button in Preview mode,
named "VC", so it is now much quicker to switch between the internal
graphics viewing library and the separate viewer component. Previously,
users had to go to the Options | Viewer Programs dialog window for that,
for example to get a second opinion in case of corrupt pictures. Also,
some users probably had this option always enabled simply because they
thought it was a "must" to view pictures with the viewer component, to
get pictures displayed at all, not knowing that pictures are by default
displayed by the internal graphics viewing library in X-Ways Forensics.
Directory icons for evidence objects that are
directories, in the Case Data window, so that they can be distinguished
Under Windows Vista and later, attachments are now
conveniently linked from the alternative e-mail representation in
Tidied up Case Data context menus.
French translation of the user interface updated.
(Not guaranteed to be error-free.)
Check boxes with long text labels in Romance
languages that get truncated because of the limited space available now
automatically come with tooltips that reveal the complete text when
hovering the mouse cursor over the control.
The Navigation | Go To menu commands are now
available in File mode.
"Display SHA-1 & TTH192 in Base32" is now a Notation
Some dialog windows are now slightly more clearly
- The XWF_CreateFile function now supports a new flag, which allows to
create files in the volume snapshot with data as provided in a buffer.
The Full path column now comes with a filter.
New options when importing or creating hash sets in
the ordinary hash databases and the block hash database. Duplicate hash
values that are already contained in the hash database can either be
removed from the newly created or newly imported hash set or from all
existing hash sets, to keep the hash database more compact/less
A new command in the Case Data window's context menu
allows to mark an evidence object with a light bulb icon as a visual aid
to locate it if important.
Another new command in the Case Data context menu
allows to conveniently make a backup of the selected evidence object's
volume snapshot. Backups can be restored at any later time with the same
command, and they can also be deleted with the same command (right-click
an item in the list of backups to get the Delete command). Such a backup
is like a snapshot of the volume snapshot. Useful if you think you might
want to revert to a certain processing stage later (i.e. undo changes to
the volume snapshot), for example after having carefully tagged
thousands files that you don't want to lose, before running a file
header signature search with experimental settings that might produce a
lot of garbage files, before attaching external files with options that
you had never tried before, before running an X-Tension made by a 3rd
party, before totally removing excluded items from the volume snapshot
Report table associations, events, and search hits are also included in
the backup. Search hits can be restored from a backup only if the search
term list of the case did not change in the meantime. Indexes are not
included in the backup, but can be manually backed up, of course.
The same command applied at the case level
(right-click the case title in bold for that) allows to make a backup of
the entire case, covering all evidence objects' volume snapshots, all
report tables, events, search terms, search hits, indexes, image file
paths, etc. etc. Such backups can be restored from the same dialog
window. Such backups can also be opened directly with the Open Case
command if necessary, as they are complete copies of a case. (Backup
.xfc file are created with the "hidden" attribute, though, as they are
meant to be dealt with within X-Ways Forensics only.)
Duplicate files can now also be recognized by the
secondary hash value.
Duplicate files can now also be recognized by
identical start sectors (within the same evidence object).
It now possible to optionally ignore additional hard
links when checking for duplicate files.
Option to print selected fields on the cover page in
bold letters and in a different color, to point the attention of the
reader to a certain aspect.
New upper/lower case conversion option for textual
data in UTF-16 (Edit menu).
Separate notation options for the case report just
like for exported lists.
FYI, two users confirmed independently that the
anti-virus software Webroot SecureAnywhere causes random crashes
(program terminations) in X-Ways Forensics. So it is not recommended to
use the two on the same computer at the same time.
Many minor improvements.
Some minor fixes.
User manual and program help updated for v19.0.
Changes of service releases of v19.0
SR-1: Fixed inability of v19.0 to recognize a few
file types (those with the "x" flag), including SQLite 3.
SR-1: Fixed an instability problem in the registry
SR-1: Fixed crashes that could occur since v18.9 when
extracting metadata from certain Linux PNG thumbnails.
SR-1b: Fixed an error in File mode in X-Ways
SR-2: Fixed inability of v19.0 to read a few sectors
on very large hard disks.
SR-2: Fixed error in file type verification and
uncovering embedded data when run with multiple threads.
SR-2: Fixed an error where attachments were not
extracted from certain .eml files.
SR-2: Fixed new option to link attachments from HTML
previews of e-mails in the case report.
SR-2: Fixed potentially wrong time zone translation
of timestamps in transcoded Nikon photos.
SR-3: Fixed a volume snapshot data corruption problem
in multi-threaded picture analysis and processing.
SR-3: More complete extraction of Chrome web history
in some cases.
SR-4: Fixed an exception error that could occur when
providing the alternative e-mail representation for certain e-mail
SR-4: Fixed a potential exception error that could
occur when running a file header signature search on physical,
SR-4: Fixed inability of X-Ways Forensics 19.0 to
view contained files in separate windows from within representations of
the viewer component.
SR-5: Fixed an I/O error that could occur when the
case auto-save interval elapsed while refining the volume snapshot with
SR-5: Report table descriptions were not handled
correctly when deleting a report table. That was fixed.
SR-5: Fixed a crash that could occur with certain
SR-5: Fixed a rare exception error that could occur
during multi-threaded relevance computation.
SR-5: Fixed an exception error that could occur when
exporting search hits with context in TSV format.
SR-5: Extraction of certain embedded pictures in .eml
SR-6: The hash filter did not correctly target the
2nd and 4th hash value if the hash type was 2 or 4 bytes in size (e.g.
CRC32). That was fixed.
SR-6: Fixed an I/O error that could occur in v18.9
and v19.0 when applying File Recovery by Type to an uninterpreted image
SR-6: The internal graphics viewing library now
represents Windows Bitmaps with 32 bits per pixel in correct colors.
Fixed skin tone computation for certain Bitmaps with 8 bits per pixel.
SR-6: Fixed a potential infinite loop that could
occur during a file header signature search for Zip archives when data
of JNX files was found.
SR-6: Upward searches did not run correctly in v19.0.
That was fixed.
SR-7: Support for previously unsupported SQLite
SR-7: Multi-threaded operations generally more
SR-7: When matching the files in a volume snapshot
against hash databases more than once, previous matches according to the
"Hash set" column are now automatically discarded. The hash category
remains. This is for performance reasons. Keeping previous and new
matches consistent and free of duplications potentially took a lot of
time and was not optimized. Users of v18.7 through v18.9 have the option
to discard hash set matches and categorizations for selected files with
Ctrl+Shift+Del first to accelerate re-matching.
SR-7: Fixed problems when loading certain GIF files
that contain extension blocks.
SR-7b: Fixed error in hash database matching with
SR-8: Fixed a crash that could occur when exploring
certain keys in registry hives.
SR-8: Fixed an exception error that could occur when
uncovering embedded data in certain executable files.
SR-8: Fixed a rare exception error that could occur
when verifying the type of zip archives.
SR-8: Sorting by filename extension is now
SR-8: Fixed a crash that could occur in v19.0 when
extracting e-mails/attachments from MBOX e-mail archives and original
SR-8: Prevented unnecessary inclusion of traces of
existing files from volume shadow copies in the volume snapshot in
SR-8: Fixed a cause for multi-threading instability.
SR-8: Improved stability with special GIF and TIFF
SR-9: For some few JPEG/TIFF files the extracted
"Content created" date was wrong or incorrectly marked as local time.
That was fixed.
SR-9: There was a problem with the multi-threading
option on VMDK images and in Ext* file systems. That was fixed.
SR-9: Prevented potential instability with carved
.lnk shortcut files.
SR-9: Warns the user of GUID conflicts among Windows
dynamic disks if open at the same time, to prevent wrong volume-disk
SR-10: Fixed inability of v19.0 SR-8 and SR-9 to make
certain changes to PhotoDNA databases.
SR-10: The category of PhotoDNA hash database matches
no longer supersedes that of regular hash database matches during the
same snapshot refinement run.
SR-10: Fixed a potential crash that could occur when
extracting metadata from $UsnJrnl:$J.
SR-10: Fixed an exception error that could occur when
uncovering embedded data from PE executable files.
SR-11: Newly identified 3GP files were erroneously
assigned to the category "Other/unknown type" by the file type
verification in v19.0 SR-1 and later. That does no longer happen now.
SR-11: X-Tension API: Two new kinds of evidence
object IDs can now be retrieved with the XWF_GetEvObjProp function
(nPropType 3 and 4).
SR-11: Fixed inability of v19.0 to copy certain files
along with the case report under certain circumstances if the type
status was "newly identified".
SR-12: Fixed an I/O error that could occur when
extracting e-mails from e-mail archives while multiple threads were
SR-12: Full filename matches in the Type filter did
not count if the type status was "newly identified" or "confirmed". That
was fixed. In v18.8 and later, full filename matches should have been
ignored only if the type status was "mismatch detected".
SR-12: Fixed an exception error or crash that could
occur under certain circumstances when opening partitions in X-Ways
Investigator without opening the parent disk first.
SR-12: LVM2 container partitions are now interpreted
properly even if the designated partition type in the MBR or GPT is
Thank you for your attention! We hope to see you soon somewhere on
http://www.x-ways.net or on our
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
X-Ways Software Technology AG