|#152: X-Ways Forensics,
X-Ways Investigator, WinHex 19.0 released
Oct 17, 2016
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. The password for users of X-Ways Forensics will change
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.
Ottawa, ON, Nov 7-10
area, Dec 12-15
Miami, FL, Jan 23-27
London, England, Feb
Victoria, BC, Mar
area, Apr 19-21
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.0?
(please note that most changes
X-Ways Forensics only)
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
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
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
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
Sig: file type verification
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
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.
Now up to 231 hash values supported per
hash set and per hash database instead of 230 in previous
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.
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
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
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.
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
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
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).
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
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
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
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
Parsing of ODATA/JSON files was revised.
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
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.
Block hash matches can now be larger than ~ 64 KB.
Thus longer matches no longer need to be split up into fragments of ~ 64
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
SR-10: Fixed an exception error that could occur when
running a file header signature search on a partitioned disk with
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