| #133: WinHex, X-Ways
Forensics, X-Ways Investigator 17.1 released
May 14, 2013 |
This mailing is to announce the release
of another notable update with many interesting features, v17.1.
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 can go to
http://www.x-ways.net/winhex/license.html
for download links, the 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 all older versions for
download from there if needed, others can usually receive older versions on
request.
Please be reminded that if you are interested in receiving information about
service releases of v17.1 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.
Please note that if you wish to continue to use an older
version, 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 X-Ways Forensics & File Systems Training
Kingston, ON, Canada, May 17, 2013
Chicago area, USA, May 24, 2013
Washington DC
area, USA, July 9-12, 2013
Seattle, WA area, USA,
July 15-19, 2013
London, England, Oct
14-18, 2013
More information
What's new in v17.1?
(please note that most changes affect
the forensic edition of WinHex only, i.e. X-Ways Forensics)
Disk Imaging
-
Another typical X-Ways feature that cements X-Ways
Forensics' position as the tool that gives its users the greatest amount
of control when selecting/targeting/filtering data at any conceivable
level: The ability to create forensic physical skeleton disk images,
which contain only those sectors that are needed for certain purposes,
while maintaining compatibility with other tools. These can be sectors with partition tables, file system data structures,
their neighboring sectors as well as sectors with file contents or any
sectors in unpartitioned no man's land. A skeleton image is typically
sparsely populated with data, with vast areas in between remaining
undefined, so that it makes sense to utilize NTFS sparse file technology
for it. Unwritten areas in the skeleton image will act as if zeroed out
when read later.
You start skeleton imaging by invoking the File | Create Skeleton Image
menu command. Which sectors from then now will be copied into the image
is defined indirectly, by making X-Ways Forensics read those sectors
from the source disk that are needed for a certain purpose. When the
target image is open in the background, next you typically open the disk
or partition or open and interpret the image that you wish to acquire
partially. That way it will be automatically defined as the source, and
that way even read operations during the important opening or
interpretation step are triggered, when partition tables and
boot sectors are parsed, so that these essential data structures
that define partitions and identify file systems are included in the
skeleton image without having to select the relevant sectors manually.
After opening a partitioned physical disk, you have a "basic
skeleton" in your target image: Partition tables pointing to partition
boot sectors or nested partition tables, whose function is to support
all the other data in between (file system data and user data). If you
also wish to ensure that from the skeleton image it is possible to take
a volume snapshot of a certain partition, i.e. get a listing of all
files and directories referenced by the file system in that partition,
then you open that partition from the source hard disk so that a volume
snapshot is taken. Again, all the sectors read from the source
hard disk in the process are simultaneously copied to the image, and
those contain the file system data structures, e.g. $MFT in NTFS, all
directory clusters in FAT, the catalog file in HFS+ etc. etc. That adds
considerably more administrative data and also metadata to your skeleton
image, but still no or almost no user content. Unrelated sectors that
are not used by the file system are not read and therefore not copied.
That also means that the ability to find previously existing files in
the skeleton image will be limited.
If you wish to include an arbitrary range of sectors in the image, you
only need to find a way to make X-Ways Forensics read those sectors. For
example, to include sectors from number 1,000,000 to 1,000,999, define
those 1,000 sectors as a block and hash that block (in Disk mode) using
the Tools | Compute Hash command, or run a physical search in that block
only. Or, to acquire an unusually large partition gap between partition
1 and 2, you could hash the virtual file representing that gap. You can
also manually navigate to any single sector of interest that you want to
be included (e.g. Navigation | Go To Sector) or use any of the file
system navigation menu commands. All of that works because reading
sectors triggers their acquisition.
However, if you wish to specifically acquire selected files, that is
easier, and it might be a good idea to turn off the indirect acquisition
of any sectors that are read for whatever purpose along the way, so that
for example a file that you preview and that turns out to be irrelevant is not acquired by the preview
action already. For that, you can
change the state of the skeleton image that is open in the background to
"idle", using the State command in the File menu. In "idle" mode, only
the "Add to [name of the skeleton image]" command in the directory
browser context menu allows to acquire selected files (by temporarily
activating the image and triggering read operations), .
If you wish to include some operating system files, for example, such as
Windows registry hives, explore the partition recursively from the root
directory, filter for those files and invoke the "Add to" command in the
directory browser context menu. (Only available if no evidence file
container is open in the background for filling at that time.) The
examiner who only has the resulting skeleton image will consequently be
able to view the hives and create a registry report about them, assuming
you had already copied the file system data structures which are
required to find out which sectors contain the data of the file.
The dialog window to change the state of the target image also allows
you to close it, i.e. stop the acquisition for the moment or finalize
the image. The same skeleton image can be further completed at any later
time by selecting it again with the "Create Skeleton Image" command, but
then you choose to not overwrite, but to update it.
As you see, you have full control over what data will make it into the
image. The methology just assumes that you have some understanding of
what data you want/need and, should that data not be stored in ordinary
easy-to-select files, where to find it/how to get it physically. The
sectors can be targeted in any order. Multiple reads of the same sectors
don't change anything in the skeleton image and have no negative effect,
except they may cause unnecessary duplicate lines in the optional log
file that X-Ways Forensics can produce. Such a log file is created in
the same directory as the skeleton image and will list all sector ranges
that were copied, optionally along with the hash value of each sector
range, which allows to manually verify the data in certain areas should
there ever be doubt about it. If you use the "Add to" command to copy
files to a skeleton image, the name of each such file will also be
output in the log, followed by the sector ranges that correspond to to
it (more than one if the file is fragmented or if X-Ways Forensics
simply chooses to copy sectors in multiple chunks).
You may want to convert the resulting raw skeleton image into a
compressed and/or encrypted .e01 evidence file and hash it or compress
it with WinRAR or 7Zip etc. before passing it on to other users. The
compression rate will be unusually high if the skeleton image is only
sparsely populated, and the speed of reading extremely high because
undefined/unallocated areas do not have to be read from the disk. For
your own use, you can just keep it as is since it does not use as much
drive space as the nominal file size suggests thanks to NTFS sparse
storage. If you wish to copy the raw skeleton image, be sure to copy it
as a sparse file (see below) so that the copy will also be a sparse file
and only takes as much drive space as the original file. A conventional
copy command would copy even the vast unused and unallocated areas
within the sparse file as binary zeroes.
To verify that the data transferred to a skeleton image has not changed,
such an image can be hashed entirely, just like an ordinary image.
Alternatively, and much quicker, you can use the command "Verify
Skeleton Image" to hash only those sector ranges again that were
actually transferred, according to the .log file (reading from the
skeleton image), and compare the hash values to those in the .log file.
Then, to verify that the .log file has not changed, it will be hashed
itself, and the resulting highly valuable all encompassing master hash
value is compared to the hash value stored in the optional .log.log
file, if that file was created. It might be desirable to additionally
verify that all unused areas in a skeleton image are still unallocated
or at least filled with binary zeroes. This is not done by this
function.
Benefits of skeleton images:
- Partial image, saves drive space.
-
Quick to create, especially when acquiring remote
hard disks through a slow network connection using F-Response.
-
Transports/reveals only specifically targeted
data, excludes unrelated data, as may be required by law, common
sense, time pressure or the customer.
-
Ideally suitable for technical data structures
(partition tables, file systems) and files in a file system as well.
-
Ability to acquire all essential file system data
without knowing anything about the file system and in which sectors
its data structures are stored.
-
Result works exactly like a conventional raw
image of the disk for all the intended purposes if adequately
prepared, with original offsets and relative distances between data
structures preserved (unlike in an evidence file container).
-
The file format is universal, and all forensic
tools that support raw images have a chance to understand the data,
unless they need more data than was included or already don't
understand the partitioning method or file system etc. of the
original complete disk/image.
Caveats:
-
Note that a search hit list on the screen with
context previews around the search hits for example will cause a lot of
read activity, so you may want to change the state of the skeleton image
to idle mode when it is open in the background in certain situations.
-
To avoid that the start sectors of files or
directories that you merely click in the directory browser in
Partition/Volume mode are copied to the skeleton image (because such a
click automatically jumps to the respective 1st sector), you can
navigate the directory browser in Legend mode instead, or have to change
the status of the image to "idle".
-
Reading data from most extracted files such as e-mail
messages, attachments, video stills, pictures embedded in MS Excel
spreadsheets etc. do not trigger corresponding read operations at the
disk level, so they cannot be copied. Skeleton images are suitable only
for files at the file system level, not at any other level seen in
volume snapshots. Use evidence file containers instead for such
purposes.
-
Note that to an unsuspecting examiner a skeleton
image may look very much like an ordinary complete image. Such an
examiner must be made aware of the incomplete, sparsely populated nature
of the image. Unlike in a logical evidence file container, files whose
contents are not contained in the image are not specially marked as such
in a volume snapshot taken of an incomplete physical image. X-Ways
Forensics v17.1 and later informs the examiner of the nature of an image
when it's added to a case, if it detects a skeleton image.
A comparison of evidence file containers and skeleton
images can be found here:
English:
http://www.x-ways.net//investigator/containers_vs_skeleton_images.html
German:
http://www.x-ways.net//investigator/Container_vs_Minimalsicherungen.html
-
Option to prevent unencrypted copies of AES-encrypted
.e01 evidence files. Can be useful if you are afraid that recipients of
an encrypted image handle it without care and for reasons of convenience
or to share it with users of other forensic software convert it to an unencrypted image.
-
Ability to interpret raw images whose segments have
4-digit filename extensions (.0001, .0002, ...), in addition to the
conventional 3-digit extensions.
-
Previously, it was possible to open VMKDs only if
their name was recorded correctly in the VMDK descriptor. For
self-contained VMKDs, this requirement led to the effect that VMDKs
would no longer be opened if renamed without updating their internal
descriptor. While this requirement continues to stand for VMDKs
consisting of multiple parts (the names of the remaining parts must be
recorded correctly), this is no longer required for VMKDs consisting of
only one part or in the case of multi-part VMKDs, it is no longer
required for the first part.
File Format Support
-
Extracts much more nicely formatted data from Skype
main.db database files than before, such as phone calls, sent text
messages (SMS) and chats.
-
Uncovers individual cookie files embedded in Firefox
and Chrome SQLite databases, as child objects in the volume snapshot, in
addition to the TSV cookie overview that the metadata extraction still
can provide. The metadata column lists the path, host and expiration
timestamp for each of these individual cookie files.
-
Provides timestamps from Internet browser SQLite
databases as events.
-
Option to add more Windows registry events to the
event list, when generating registry reports. These events depend on the
selected report definitions and are much more specific than the generic
registry hive events (which are mostly "Key changed").
-
New extraction methods for MBOX and DBX updated to
also produce slim .eml files without embedded attachments.
-
Improved file type verification of encrypted MS
Office 2007/2010 documents.
-
X-Ways Forensics now uncovers any kinds of files in
PDF documents that are marked as embedded. Those can be Office
documents, videos or flash files, for example. They can be embedded for
example as so-called attachments. JPEG pictures are extracted as before.
Additionally, Acrobat form files in XML format and JavaScript objects
are uncovered. Based on the JavaScript files it is easier to decide
whether a certain PDF document should be considered malware. If
JavaScript is found in a document, that will also brought to your
attention in a new metadata field named "JavaScript". Protected PDF
document are not yet processed. Ability to uncover JPEG 2000 pictures in
PDF documents.
-
PDF metadata extraction revised.
-
Fixed an error in Intel Hex to binary conversion.
Usability
-
When restoring the last window arrangement upon
start-up, X-Ways Forensics now also restores search hit list and event
list mode if applicable and reselects the last search hit or event that
was selected, so that you can resume even review work in search hits and
event lists right where you left it, even in the case root window.
-
Ability to turn on or off usage of the copy log file
and configure the copy log right in the Recover/Copy dialog window. That
the copy log is written to the _log subdirectory of the case is now
optional. It can now also be written to the selected output folder along
with the copied files. This is more convenient if you wish to pass the
copy log on to others.
-
For reasons of convenience, after exploring an object
from a recursive list, the .. item is now marked with a "Back" arrow and
allows to return to the previous recursive list, just like the Back
button in the toolbar, and does not navigate to the parent directory of
the explored object. If in some rare situations you do want to navigate
to the parent directory of the explored object, just use the Navigation
submenu of the directory browser context menu or press the Backspace key
on your keyboard.
-
Ability to highlight search hits for GREP expressions
in documents in Preview mode just like ordinary search hits, as long as
the viewer component can find it (not if the search hit is located for
example in the document metadata which the viewer component does not
represent in Preview mode).
-
When printing files with a cover page, the header
line that specifies which user and which program and version created the
print job is now optional. Useful if you wish to show the cover page to
witnesses or the suspect who should not know the username of the
examiner.
Setup
-
For historical reasons, licensed users of X-Ways
Forensics were always provided with the option to execute a special
winhex.exe file instead of xwforensics.exe. This special WinHex version
combines the best of both worlds: Full disk editing and data wiping
functionality, as known from WinHex with merely a professional or
specialist license for example, embedded in the complete forensic
feature set of X-Ways Forensics. X-Ways Forensics itself, being a pure
forensic analysis program, never ever allowed to edit data in disk
sectors or interpreted images or to wipe files or free drive space areas
etc.
For more than 1 year now licensed users of X-Ways Forensics were
provided with four different .exe files, X-Ways Forensics and WinHex,
each in a 32-bit and 64-bit edition. To avoid the complex, inefficient
and unnecessary maintenance of different .exe files that are 99.9%
identical, to make the downloads more than 25% smaller, and to reduce
risks of version mismatches in the same directory, no more WinHex
executables will be distributed in addition to X-Ways Forensics.
Instead, from v17.1 onwards, those users of X-Ways Forensics who
occasionally need the special capabilities of WinHex, may simply copy
their xwforensics.exe file or xwforensics64.exe and name the copy
winhex.exe or winhex64.exe. Or even cooler, create hard links with these
names. Those users who use the setup program do not need to do anything,
as the setup program creates hard links with these names automatically.
When you execute an X-Ways Forensics .exe file with "WinHex" in the
filename/name of the hard link, the program will identify itself as
WinHex everywhere (in the user interface, case report, case log, image
descriptions, and all screenshots) and work exactly like that special
WinHex version known for many years, while with no "WinHex" in the
filename the same program continues to run as X-Ways Forensics without
any disk editing or data wiping capability.
-
Russian translation of the user interface available
(change via Help | Setup)..
Media Support
-
Now supports non-standard (non-Adaptec/JetStor
typical) parity start components for RAID level 6 with backward parity
when internally reconstructing RAIDs, as seen in Synology hardware.
-
Now supports backward parity dynamic for RAID level
6, with standard or non-standard parity start components.
-
Supports certain LVM2 partition layouts that were not
recognized before.
-
Better support for unusually deep subdirectory
nestings in Ext file systems.
-
Slightly improved treatment of remote network drives,
network shares, and F-Response connector volumes.
Miscellaneous
-
New menu command Tools | File Tools | Copy Sparse
introduced, which can copy any selected file, but preserves the sparse
nature of an NTFS sparse file in the destination file. That means for
example when copying a 1 TB skeleton disk image that only has 100 MB of
data allocated, the copy process will finish almost instantly because
only 100 MB out of 1 TB of data has to be copied. Conventional copy
functions do not preserve the sparse nature of a file and copy the
entire nominal file size.
-
Ability to change the detected sector size of a
physical hard disk that WinHex works with, via Tools | Disk Tools | Set
Disk Parameters. Remember you should also adjust the sector count
accordingly. For example, if you change the detected sector size from
512 bytes to 4 KB (i.e. you multiply it by 8), then you also need to
divide the total number of sectors by 8 to keep the same total detected
disk capacity (assuming the capacity was detected correctly).
-
More information about exception errors in error.log
files.
-
Many minor improvements and some minor fixes.
-
PDF user manual and program help revised and updated
for v17.1 in English and German.
Changes of service releases of v17.0:
-
SR-1: Extraction of pictures from .xls documents
supported.
-
SR-1: Improved e-mail extraction from Exchange EDB.
-
SR-1: Fixed a rare exception error that could occur
when opening FAT volumes with a certain layout.
-
SR-1: v17.0 did not apply information from
Windows.edb to thumbnails extracted from thumbcache*. That was fixed.
-
SR-1: An exception error was fixed that could occur
when extracting large amounts of e-mail or embedded files from other
files.
-
SR-1: An exception error was fixed that could occur
when extracting events from Windows registry hive fragments.
-
SR-1: The options to exclude JAR, APK, IPA etc. from
archive exploration did not work reliably in v17.0. That was fixed.
-
SR-1: Now when about to convert the old volume
snapshot format of v16.9 and before to the new one, the software highly
recommends to make a backup of the case and all its subdirectories
first, as apparently some conversions are not successful.
-
SR-2: All operations with EDB database files now also
work under Windows 8.
-
SR-2: Fixed exception errors that could occur when
first uncovering embedded data in miscellaneous files and then running a
simultaneous search in the same session.
-
SR-2: Selection error for more than 5 type groups in
the Type Status filter dialog fixed.
-
SR-2: Ability to convert a network dongle to a "pure"
network dongle that even if connected locally can only be used through
the network interface, which can be enforced as described in the network
dongle package.
-
SR-3: More thorough exploitation of volume shadow
copies.
-
SR-3: Fixed error "Cannot open '...\External". Please
check the path and your access rights." when processing PLists.
-
SR-3: v17.0 did not always automatically include the
contents of archives if they were misnamed. That was fixed.
-
SR-4: Forces MPlayer to use the directory for
temporary files for the export of video stills.
-
SR-4: Can share the same local dongle simultaneously
on the same machine with instances of v16.5 SR-14, v16.6 SR-11, v16.7
SR-11, v16.8 SR-11, v16.9 SR-6 (not older releases), and v17.1 if
executed by the same user.
-
SR-4: More consistent treatment of garbage timestamp
values.
-
SR-5: When creating report table associations for the
parent file of the selected file, if the direct parent is no file, but
the grandparent or great grandparent etc., then the grandparent will get
the association. E.g. XML file in a directory in a ZIP-style Office
document.
-
SR-5: Fixed an error message that occurs when not
keeping .xfc backup files.
-
SR-5: Prevents a rare error message that could occur
when processing empty e-mail messages in unusually named directories
within in Outlook PST e-mail archives.
-
SR-5: Fixed a rare error that could occur with
corrupt FAT32 boot areas.
-
SR-5: XFS support improved to better recognize and
ignore corrupted file system data that might otherwise cause issues.
-
SR-6: Non-deterministic "The specified resource name
is not found in an image file" error fixed in Chinese and Japanese user
interface.
-
SR-6: Some of the radio buttons in the case report
options did not behave as they should. That was fixed.
-
SR-6: The export of report table associations for
multiple selected evidence objects was potentially incomplete if one of
the selected evidence objects did not have any report table
associations. That was fixed.
Thank you for your attention! We hope to see you soon somewhere on http://www.x-ways.net or on our Facebook page.
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.
Kind regards
Stefan Fleischmann
X-Ways Software Technology AG
Agrippastr. 37-39
50676 Cologne
Germany
Legalities
Register of commerce: AG Bad Oeynhausen HRB 7475
CEO: Stefan Fleischmann
Supervisory board: Dr. M. Horstmeyer (chairwoman) Competition is
normal and healthy. Patents and court battles about rectangles and finger movements are not.
Please reconsider before buying Apple products. Don't support malevolent
companies. Thank you. |
