WinHex & X-Ways Forensics Newsletter Archive

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)

This  mailing is to announce the release of another notable update with many interesting features, v17.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)

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

London, England, Apr 15-24, 2013
Kingston, ON, Canada, May 13-17, 2013
Chicago area, USA, May 20-24, 2013
More information

What's new in v17.0?

(note most changes affect the forensic edition of WinHex only, i.e. X-Ways Forensics)

Network Dongles

• Ability to unlock X-Ways Forensics 17.0 and later (also v16.9 SR-4 and v16.8 SR-10) with network dongles. Network dongles are available now as a substitute for regular dongles. A single network dongle can represent x licenses and substitute x regular dongles and allow the users to run X-Ways Forensics on x machines on the same network at the same time. The network dongle is attached to any of the computers on the network and made available to the clients by a dongle server program or service. If multiple network dongles are found by a client, the user may choose one of them when starting up X-Ways Forensics. If one of these dongles is already fully in use, according to the number of licenses that it represents, the user will see that and can choose another dongle. Conveniently, a network dongle can also be used locally just like a regular dongle or multi-user dongle when needed!
  
  You have the option to order new licenses with a network dongle instead of regular dongles, depending on the number of licenses either for free or at a surcharge. If you own many licenses already, we can offer you to test the network dongle and to swap many or all of your existing regular dongles for a single network dongle. For much more information on the dongles in general and network dongles in particular please see http://www.x-ways.net/forensics/dongle.html#types.

File System Support

• In newly taken snapshots of HFS+ volumes with hard links, you can now view hard-linked files directly and do not have to look up the corresponding so-called indirect node file manually (the one whose name contains the iNode number, which is specified in the Comments column).

• Newly taken volume snapshots now support a concept of "related" files, related in ways other than a parent-child or sibling relationship. For example, the related file for hard links in HFS+ is the corresponding indirect node file. The related file for files that were found in volume shadow copies in NTFS is the volume shadow copy host file. The related file for a volume shadow copy host file is the corresponding snapshot properties file (called "snapprop" in the Type column). More kinds of n:1 relationships are conceivable in future versions. Files for which a related file is defined get their icons marked with a small blue downward pointing arrow on the left-hand side.

• A new command in the directory browser context menu (Navigation submenu) allows to conveniently find the related file if one exists for the selected file. You may also press Shift+Backspace to navigate to the related file. This is similar to just hitting the Backspace key, which navigates to the parent file or directory.

• For files found by v17.0 and later in volume shadow copies, the Attr. column now points out the sequential number of the snapshot in which they were found, as indicated by the snapshot properties file.

• Avoids more irrelevant identical traces of files found in volume shadow copies.

• In newly taken volume snapshots of NTFS volumes, hard-linked files now get a special treatment. An additional hard link that merely provides a short filename to satisfy the 8.3 requirements of old Microsoft DOS/Windows versions is not counted any more as a hard link. Instead, such files get their hard link count marked with a ° in the Links column of the directory browser. That way, the hard link count more accurately reflects the hard links actually present in the volume snapshot of X-Ways Forensics, and normal files always have a count of 1, whereas 2 or more really means something more special.

• A filter is now available for the ID column, which makes it more convenient to find other hard links of a given file (except HFS+).

• When viewing a hard-linked file in file systems with direct support for hard links (not HFS+), the other hard links of the same file are now optionally marked as already viewed as well at the same time, just as known in previous versions for duplicates based on hash values.

• When creating report table associations for duplicates of the selected files at the same time, this now includes other hard links of the same file (except in HFS+).

• Support for more deeply nested subdirectories on Ext* volumes.

Searching

• In newly taken volume snapshots of NTFS volumes, all "real" hard links (i.e. hard links other than SFN) except for one can be conveniently excluded from logical searches and indexing . Nowadays on Windows installations often between 10,000 and 100,000 hard links of system files exist, for example 27 links to a file like "Ph3xIB64MV.dll" in directories such as
  \Windows\System32\DriverStore\FileRepository\ph3xibc9.inf_amd64_neutral_ff3a566e4...
  \Windows\System32\DriverStore\FileRepository\ph3xibc2.inf_amd64_neutral_7621f5d6...
  \Windows\System32\DriverStore\FileRepository\ph3xibc5.inf_amd64_neutral_2270382...
  \Windows\winsxs\amd64_ph3xibc9.inf_31bf3856ad364e35_6.1.7600.16385_none_a0a...
  \Windows\winsxs\amd64_ph3xibc5.inf_31bf3856ad364e35_6.1.7600.16385_none_9e7...
  \Windows\winsxs\amd64_ph3xibc12.inf_31bf3856ad364e35_6.1.7600.16385_none_64...
  etc. etc.
  By searching only in one hard link of a file, you can typically exclude several GB of duplicate data and yet don't miss anything if you search all other files. Those additional hard links that are excluded get their hard link count marked with an asterisk (*). Search hits in the only hard link that does get searched are marked with the hint "-> Links" in the Descr. column to remind you of the other hard links of the same file in case those search hits are relevant.

• Support for another artifically defined code page, which allows to search for and read UTF-16 text encoded by the MS Outlook cipher called compressible encryption.

• It is now possible to search and index in up to 6 code pages at the same time.

• The already previously supported non-Unicode artificial code page for MS Outlook compressible encryption now works based on a user-defined code page (by default equal to the code page active in your Windows system for non-Unicode programs), not just Latin 1. Potentially important for languages other than Western European languages. Outlook uses the Windows system code page in its old non-Unicode capable variant of PST.

• PST and OST files are now no longer omitted by logical searches and indexing if the recommended data reduction is active and e-mail and other Outlook data has been extracted from them, but MBOX files are.

• Search hits in all variants of UTF-16 that are not aligned at even offsets are now marked in the Descr. column as "unaligned", as a small hint and explanation why you can read the text only in the alignment-aware context preview of the Search hits column, and not in the text column.

• Logical searches now also specifically cover the transition area from uninitialized (but physically allocated) areas of files to immediately following free space, if the option to cover the transition from slack space to free space is in use.

• Ability to run a logical search in selected files via the directory browser context menu from the case root window.

File Format Support

• The "Uncover embedded data" function uses some special algorithms for certain file types (Windows.edb, thumbs.db, PLists) and byte-level carving for all other host file types. This carving was limited to embedded JPEG and PNG files in previous versions (+EMF in multi-page printer spool .spl files). Now embedded files of any type whose definition in the File Type Signatures Search.txt file comes with a tilde (~) algorithm and is marked with a new flag "e" (for "embedded") will be carved. As a very good example of this new flexibility, .lnk shortcut files are now carved within customdestinations-ms jumplists.

• Special extraction of objects (pictures and others) embedded OLE2 compound files such as MS Word .doc and MS PowerPoint .ppt, in which previously only JPEG and PNG were found and only through ordinary carving. Embedded pictures are now often output with their original name or designation in the document and are extracted correctly even if fragmented within the OLE2 compound file.

• Exploring the contents of 5 more usually irrelevant zip subtypes is now optional when refining the volume snapshot, compared to just JAR in previous versions.

• Exploring zip-based Office document files such as those of MS Office 2007/2010, LibreOffice, OpenOffice, iWork is now also optional when refining the volume snapshot. Useful if you or the recipients of evidence file containers that you create only wish to see the documents as a whole, no embedded pictures or XML files separately, and don't need to extract metadata from these XML files and can recognize nested documents (documents embedded in other documents) themselves if necessary.

• Support for binary PLists has been improved to include the undocumented CF$UID data type.

• Carving support for "Gatherer Transaction Log".

• Special support for carving thumbcache fragments (CMMM records) at the byte level.

• The resolution of videos is now displayed roughly in the Pixels column after at least one video still has been exported.

• The option to list items in registry hives recursively has been removed.

Disk Support, Disk Imaging

• The Technical Details Report now checks for certain read inconsistencies that can occur with flash media (for example certain USB stick brands/models, but not others) in data areas that have never been written/used, where the data is undefined. The data that is read in such areas, for example when imaging the media, may depend on the amount of data that is read at a time with a single internal read command. The result is mentioned in the report. If inconsistencies are detected ("Inconsistent read results!" in the report), you will see a message box, which offers to read sectors in smaller chunks from that device as long as it is open, which likely yields the expected zero value bytes instead of some random looking non-zero pattern data when reading such areas. Use of this option does not give you data that is somehow more accurate or original (undefined is undefined and does not mean zeroed out) or contains more or less evidence, it can just have a big impact on compression ratio achieved and reproducibility of hash values with other tools, which may use different chunk sizes for reading and thus produce different data and hash values. Note that it is possible that read inconsistencies occur that are not detected by X-Ways Forensics, because a complete check would be very slow. Again, these inconsistencies are not fatal and not the fault of the software, and they can be explained. Does it mean that you should invoke the Specialist | Technical Details Report command prior to imaging? No, the report is routinely created already when imaging starts.

• Since v16.3 it is possible to reconstruct RAID level 5EE by simply selecting a compatible RAID level 6 variant. Now it is possible to select RAID 5EE systems specifically and reconstruct them also if evencomponent disk is missing. RAID 5EE with forward and backward parity are supported.

• Ability to specify how many extra threads to use when creating .e01 evidence files, when clicking the tiny little button in the lower right corner of the Create Disk Image dialog window. By default X-Ways Forensics will use no more than 4, and it depends on how many processor cores your system has, but you could try to increase it to up to 8 or even 16 on very powerful systems with even more cores usually without problems, for a chance to further increase the speed.

• Detection of Windows dynamic volumes larger than 2 TB on GPT LDM partitioned disks.

Methodology

• Ability to rank file types by importance/relevance and filter by the rank using the Type Status filter. For example, filtering out those file types ranked #0 or #1 will exclude font files, cursors, icons, themes, skins, clip arts, etc. Files with a low rank are of importance just in very specific investigations, for example source code, in which you would not be interested when looking for office documents or pictures for example, but perhaps when hunting a virus programmer. Higher ranked file types are relevant in more cases. Generally the rank is useful in simple cases where you can expect to find what you are looking for in file types that are fairly well known. As another idea, you could make it a habit to only index files with higher ranks.

• Ability to assign file types to a so-called group, a new concept, which is not identical to a file type category. Useful for example if your standard procedure is to let examiner A check out pictures and videos, examiner B documents, e-mail, and other Internet activity, and examiner C operating system files of various kinds, because of their specializations. You can give these groups meaningful names and filter for them, also using the Type Status dialog window. The groups are displayed in the Type filter.

• The new definitions are all made in the "File Type Categories.txt" file. Existing files of that kind will continue to work as before. Suggestions for ranks are already predefined in the new standard file. Both ranks (from 0 to 9, where missing means 0) and groups (letters from A to Z) can be optionally specified following a tab at the end of a line, in any order, for example as "2P" or "DI3". So up to 10 rank levels are possible (but it is not necessary to fully utilize this range), and up to 26 groups (and you do not have to start alphabetically, the case of the letters is ignored). You can also define ranks and groups for an entire category, following a tab in a category line. To give a group a more descriptive name than just a single letter, insert group definition lines at the end of the text file that start with a equal sign, e.g.
  =P=Photos and videos for image group
  =D=Docs, e-mails and Internet
  =I=File types to index

Event Analysis

• Event extraction from carved fragments of Gatherer Transaction Log (.gthr2) and existing .NTfy.gthr files, and several other file types. Below is an overview of file formats from which events are currently extracted:
  .firefox (~55) fragments
  _CACHE_001_ and _CACHE_002_
  .lnk shortcuts
  .automaticDestination-ms
  .chrome Chromium cache data_1, data_2
  .usnjrnl fragments
  Registry hives
  .hbin Registry hive fragments
  .doc (last printed)
  .msg
  rp.log XP restore point
  INFO2 XP recycle bin
  .recycler Vista recyle bin
  .snapprop Vista volume shadow copy properties
  .cookie
  .gthr;.gthr2 Gatherer and Gatherer fragments
  .pf prefetch
  JPEG GPS
  OLE2 last modification

• Several events now have an individual description, for example events in the Windows registry and in Internet Explorer index.dat files.

• A filter for the event type column is now available.

Setup/Administration

• User-specific configurations are now stored in the Windows user profile, in a subdirectory of \AppData\Local\X-Ways. The configuration now becomes user-specific automatically when running X-Ways Forensics not as administrator from a directory on the C: drive where a user does not have write access, such as C:\Program Files. Otherwise by default X-Ways Forensics still runs with a non user-specific configuration so that it remains a portable program and does not unnecessarily alter live systems that you wish to preview/triage. For details please see http://www.x-ways.net/winhex/setup.html. Whether a user-specific configuration is active or not (and if active, for what reason and where it is stored) can be seen in the Help | About box. The reason can be "necessarily" if no write access to the installation directory is available or "forced" if a file named winhex.user is found in the installation directory or "for this user" if the user has an individual configuration already from previous executions for either of the other two reasons. The inconsistent use of Virtual Store subdirectories is now avoided.

Usability

• Ability to refine the volume snapshot for selected files only, via the directory browser context menu.

• Ability to store most filter and all sort settings in the active case and load them again automatically when a case is opened. See Options | Directory Browser.

• Ability to save filter and sort settings to a separate file and load them again at any time, by clicking on the Open/Save icons on the right-hand side of the caption line of the directory browser. Such files are given the extension ".settings".

• The selected file types of the Type filter are now also optionally stored in cases, like other filter settings. Note that collisions among file type designations become apparent when selections for the file type filter are loaded. For example if you had originally selected "mmf" = "MailMessage File" (category e-mail), then you will find that "mmf" is also selected as "Yamaha SMAF" (category Sound/Music). This is normal and does not change what the Type filter does. When in doubt, the Type filter always also includes other types with the same designation, to avoid that anything is overlooked.

• If you choose to not sort the directory browser initially after start-up, there will now also be no sorting when turning off all filters with a single mouse click, to avoid longer delays when suddenly all files are listed again recursively.

• Ctrl+A now works in all edit boxes and all multi-selection list windows in dialog windows.

• The check for updates can now be found in the Help | Online menu.

• Ability to filter for "unequal to" in the ID and internal ID filters. Useful should the volume snapshot refinement crash with a file that was not part of the volume snapshot when it was last saved during the refinement. In that case you can filter out and omit the offending file with the future assigned internal ID in advance when you try again.

• New Attr. filter option for other virtual files, which includes for example human-readable HTML representations of Internet browser databases, event logs etc.

• Activating Sync mode now automatically deactivates all filters if filters keep the directory browser from listing the file that the current cursor position in Partition/Volume mode is contained in. As always you can click the Back button to return to the previous listing in the directory browser, but remember that this works only if the directory browser has the input focus, not the lower half of the data window where you navigated in Partition/Volume mode, where jumps from one offset to the other can be undone or redone with the Back & Forward functionality.

Miscellaneous

• Includes the contents of the Pixels column in evidence file containers of the new type.

• If the option to Recover/Copy child objects of selected files is half selected, that now means that the only child objects that will be copied are e-mail attachments.

• When copying files or alternate data streams or other objects that do not have any or all timestamps with the Recover/Copy command, X-Ways Forensics now approximates the fact that a timestamp is not available by setting the corresponding timestamps of the output files to ~0 (Jan 1, 1601 in NTFS). This behavior was already active in versions before April 2012. It can be avoided by holding the Shift key when clicking OK in the dialog box, for example if you wish to use some other programs with these files that do not want to open files with such timestamps (it has been reported for VLC).

• Ability to extract video stills reliably using recent MPlayer releases. MPlayer 1.1 for use with v17 is now provided as a download.

• Directory browser option to display tag marks as check marks.

• The option "Display file sizes always in bytes" can now be found in Options | General | Notation. The alternative .eml preview option can now be found in Options | Viewer Programs.

• Tools | File Tools | Delete Recursively can now automatically delete files for which you do not currently have the right to delete (for example because "Trusted Installer" is the owner), but for which you can get all rights (if you are running WinHex with administrator rights).

• Minimum memory requirements for loaded volume snapshots reduced. More data of volume snapshots can now be kept in memory optionally for higher performance.

• More compact internal organization of certain files in volume snapshots (extracted e-mails, video stills, virtual attached files).

• Volume snapshots from v16.3 (released in October 2011) and later can be imported, from v15.8 (October 2010) to v16.2 as well if no e-mail was extracted by those versions. Incompatible volume snapshot will be identified and not converted.

• Memory requirements for search hits reduced by 17%. Old versions cannot load search hit lists saved by v17.0 and later.

• Many minor improvements and some minor fixes.

• PDF user manual and program help revised and updated for v17.0 in English and German.

Changes of service releases of v16.9:

• SR-1: Ability to force user-specific WinHex*.cfg configuration files by creating an empty file named "winhex.user" in the installation directory.

• SR-1: Fixed two errors with the Export List command for event lists.

• SR-1: The column Sender and Recipients are now populated for e-mail extracted from MBOX and DBX e-mail archives with the new extraction method.

• SR-1: Fixed inability of X-Ways Investigator 16.9 to open images/containers.

• SR-2: More tables extracted from previously supported SQLite databases.

• SR-2: Chinese translation of the user interface updated.

• SR-2: Fixed an exception error that could occur when attempting to find deleted directory entries while taking a snapshot of XFS volumes.

• SR-2: Prevented a theoretically possible issue where a few random characters could have been appended to an (otherwise correct) file name in XFS.

• SR-2: An exception error could occur when the "Search Terms" filter was active when opening an evidence object that had search hits. That was fixed.

• SR-2: Fixed an exception error that could occur under certain circumstances when parsing PLists.

• SR-2: Fixed a rare exception error that could occur when parsing index.dat files.

• SR-2: Fixed thumbcache*.db processing error.

• SR-2: Prevented a rare SHA-256 computation error in disk imaging that if it occurred was revealed by hash verification later.

• SR-3: The file carving flags u and U now also carve in unpartitioned areas and partitions with an unknown file system.

• SR-3: The new option for separate print jobs did not work on all systems. Fixed now.

• SR-3: Ability to trigger the check for updates online at any time.

• SR-3: The display in the Path column was truncated in v16.9. That was fixed.

• SR-3: Fixed hanging when applying the "List clusters" command to certain directories in XFS.

• SR-3: Fixed an instability that could occur in v16.9 when parsing $UsnJrnl:$J.

• SR-4: Ability to use the new network dongles just like in v17.0.

• SR-4: File system level timestamps of directories are now also output as events.

• SR-4: Regular expressions with \nnn where \nnn is a decimal number were not processed correctly in previous versions. That was fixed.

• SR-5: .lnk shortcut files that were extracted from jump lists were erroneously marked internally as e-mail attachments. This was fixed.

• SR-5: No metadata extraction was performed by a fresh install unless the suboptions had once been confirmed by clicking OK. That was fixed.

• SR-5: Avoids an exception error that could occur when parsing volume shadow copies.

• SR-5: Improved communication with the network dongle server.x.

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)

This  mailing is to announce the release of another notable update, v16.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 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 v16.9 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

Washington DC area, USA, Mar 11-20, 2013
London, England, Apr 15-24, 2013
Kingston, ON, Canada, May 13-17, 2013
Chicago area, USA, May 20-24, 2013
More information

What's new in v16.9?

Methodology

• Ability to generate a list of events from timestamps that can be found at the file system level as well as internally in files and in main memory, when extracting metadata. Conceivable sources include browser histories, Windows event logs, Windows registry hives, e-mails, etc. An event list works exactly like a search hit list and can be displayed by clicking a new button which is located next to the search hit list button, with a clock icon on it. Just like a search hit list, an event list comes with additional columns: the event timestamp, event type, event category, and optionally a file offset.
  
  When an event list is sorted chronologically, by timestamps, it works like a timeline, which may allow you to figure out a sequence of events of different kinds stored in different places (e.g. e-mail received, attachment saved, application started, document printed, file deleted) that otherwise could not be seen together in context. As usual, you may see events from different evidence objects at the same time from the case root window, explore recursively or by path, sort by event type or event category, see all the usual file properties, view files, navigate to the definition of an event within a file (if a relative offset is available) and filter for certain date ranges.
  
  Event-based analysis instead of file-based analysis is a progressive new approach with a totally different perspective that may lead to knowledge about activities recorded on computers that otherwise could not be gained. You may see connections (related activity) that otherwise could be overlooked, and may be able to better explain the logic behind what has happened. The sources of events that are exploited by the metadata extraction in this release are still limited (file system, index.dat, e-mails, processes in memory dumps). More will be covered in future releases.

• Option to work with an adjusted virtual free space file that is net of clusters that were identified as belonging to previously existing files, to minimize the amount of space in file systems that is read twice for logical searches and indexing. After changing the option (in Options | Volume Snapshot) the virtual file is updated when it is opened next time, for example selected in File mode or when it is that file's turn during a logical search. Relative offsets of search hits in this virtual file become wrong when the file changes, so they cannot be used to navigate to the search hits in File mode.

• New flag U for file header signatures that will cause files (or records) of this type to be carved only in net free space. Useful especially for internal entries of Zip files, RAR archives, Internet Explorer index.dat files, and Firefox URL records, to avoid numerous duplications.

• The file carving flags b (for byte granularity) and g (for greedy allocation) can now be combined. Useful when carving records of files for which an internal algorithm is available that can combine multiple contiguous records in a single carved file. The g flag makes sure that those records that have been included already will not be found and carved again separately.

File Format Support

• Extraction of all tables (with all columns except binary data) from all other SQLite databases besides the already supported various Internet browser databases as part of metadata extraction. The first extracted table will also serve as a preview of the SQLite database file itself.

• File header signature and internal algorithm for $UsnJrnl:$J records. A single file is carved that is composed of multiple contiguous records outside of known $J ADS and can be nicely viewed in Preview mode (still testing). Viewing such a single file is much more efficient than viewing separately carved records.

• Ability to display certain non-standard GIF pictures in the gallery and in Preview mode using the internal graphics viewing library that caused exception errors in v16.7 and before and were not attempted to display by v16.8.

• Signatures and algorithms for file type verification and file header signature search considerably revised.

• Preview of .pf prefetch files improved.

• Revised processing of PLists.

• The metadata extraction for index.dat files (HTML preview generation and event extraction) is now also applied to carved fragments of index.dat files (Internet Explorer URL records).

• Menu option to display text in the text column in big-endian UCS-2/UTF-16 Unicode. Useful especially to correctly see East Asian characters for example in HFS* file systems and in binary PLists.

• Carved files are now defined to have slack space if they happen to start at a cluster boundary.

Disk Support, Disk Imaging

• Superimposition of sectors on top of disks or interpreted images that are opened as read-only. Useful when you need to make minor temporary adjustments to data in sectors within the program to get it interpreted correctly internally, but do not want to or are not allowed to alter the sectors on the disk or in the image itself (or cannot because it is not a raw image, but an .e01 evidence file), and also do not want to make another complete working copy of an image that is e.g. 2 TB in size if just 1 byte needs to be changed. Such adjustments can be necessary for example in cases of partitioning or file system metadata corruption, where just a missing magic number keeps WinHex from detecting the file system or just one flipped bit keeps WinHex from finding $MFT in NTFS or just one wrong nibble in the partition table keeps WinHex from recognizing a partition as an LVM2 container partition etc. etc. In these situations you can manually provide and superimpose the corrected data and then hopefully work with the disk or image with no further problems, getting all partitions and files listed immediately as if nothing was wrong. This functionality is intended for advanced users that do not give up easily when at first they see "nothing" and have some understanding of low level data structures and know how to fix them.
  
  You can enable and disable superimposition for the disk or partition in the active data window using the Edit | Superimpose Sectors menu command. This command allows you to select any file with the raw contents of disk sectors. For example, you can create such a file by selecting one or more sectors as a block, copying the block into a new file, making the necessary adjustments (possible even in X-Ways Forensics because ordinary files unlike disks or interpreted images can be edited) and saving that file. When applied, the contents of this file are superimposed to the sectors starting with the sector in which the cursor is located, or if the file is named "*.n.superimposition", where n is a number, it will be applied to the sectors starting with sector n, and all other files in the same directory matching the same mask with the same base name will also be applied to sector numbers as indicated within the filename. You will immediately see the superimposed data when navigating to the affected sectors, and can continue making adjustments to the imposed raw data file if you keep it open in a separate window. As soon as you have saved changes in that window, they will take effect in the data window that represents the disk or partition whose data you are trying to fix when you refresh the view, take a new volume snapshot, define the start of a partition, try again to open a file with a corrupt FILE record etc. etc.
  
  Please note that only complete sectors, not partial sectors, can be superimposed. Superimposition can be active only for one disk or disk partition or image at a time. If desired, you can make a copy (image or cloned disk) of the virtually repaired disk or image with the usual commands while the superimposition is in effect, so that the copy will have the superimposed sectors directly embedded.

• Support for PC-compatible BSD disklabel partitioning.

• Ability to image a physical device (e.g. local hard disk or remote hard disk or RAM opened through F-Response) automatically via the command line. The first parameter should start with a colon and then specify the number of the device in Windows (e.g. ":1" for hard disk No. 1). 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"). The third parameter can be "auto" to automatically exit X-Ways Forensics after imaging. (That command has always been available in WinHex and X-Ways Forensics, just like you were always able to open files through the command line or execute .whs WinHex scripts.)
  A powershell script that automates imaging physical memory on remote machines with F-Response Enterprise and X-Ways Forensics using the above-mentioned new command line options has just been posted here.

• Simultaneous creation of 2 copies of .e01 evidence files was unsuccessful if they were given different names. That was fixed.

• Reports the total number of CRC errors in the evidence object properties for each hash computation if chunk CRCs are being verified when reading from .e01 evidence files (see Options | Security).

Search Functions

• Easy to use settings for the alphabet that defines word boundaries when searching for whole words only in Latin-based languages. The setting for the most thorough search results remains the default. Users that are overwhelmed by garbage hits for short keywords in non-text data such as Base64 or binary garbage may want to try the other two options. These other two options could lead to valid search hits being missed in some constellations (depends on the file format), but can still be justifiable as a great time saver for searches in text documents.

• Ability to use GREP syntax specifically for some search terms only, while others are keywords in a natural language. For this setting make sure that the GREP syntax box is half checked, and prepend GREP expressions with "grep:".

• Similarly, when not using GREP syntax, you can now search for only some search terms as whole words, also by checking the corresponding box half only, and by indenting search terms that you want to find as whole words only, i.e. prepend them with a tab character.

• X-Tensions API: New flags XWF_SEARCH_WHOLEWORDS2 and XWF_SEARCH_GREP2 to reflect the new search options. New XT_PrepareSearch function supported that allows X-Tensions that monitor search hits to also monitor some search settings and adjust search terms.

• Maximum number of contained search terms listed in the Search Term column of the directory browser is now 25 instead of 10.

Usability

• In Gallery mode scrolling using the mouse wheel now always scrolls by exactly one page of thumbnails for reasons of convenience. Everywhere else the mouse wheel scrolls by as many lines as specified in the Windows Control Panel since v16.7. In v16.6 and earlier that was an option in the General Options.

• When attaching an external directory to the volume snapshot, usually X-Ways Forensics creates virtual files in a new virtual directory. Now there is an option to accommodate the files in existing directories in the volume snapshot of the same name at the same position in the directory tree. Useful if you copy an entire directory structure off the image to convert/decrypt/translate/... files outside of X-Ways Forensics, and then want to bring the results back into the volume snapshot and see the files next to their original counterparts in the same original subdirectories. This can help for example if you wish to OCR and convert PDF documents that X-Ways Forensics has deemed non-searchable using Adobe Acrobat.

• When attaching an external directory to the volume snapshot, you are now prompted whether the selected directory itself should also be attached (that was the standard behavior in earlier versions) or just its contents.

• It is now possible to "unsort" the directory browser by clicking the header of the column that represents the primary sort criterion while holding the Shift key.

• The Print command in the directory browser context menu now has a convenient option to print any child objects after the selected file(s), e.g. e-mail attachments together with their respective e-mail message.

• Ability to print multiple selected files optionally in separate print jobs like in v16.3 and earlier.

• It is now easier to enter dates in the timestamp filter dialogs. You can click buttons to get a calendar control in which to pick a date using mouse clicks.

• Several other user interface elements were improved.

• New icon for renamed/moved directories in FAT and exFAT volumes.

• Some more statistics in the evidence object properties.

• Ability to check for updates online occasionally (Options | Security). This can report the availability of later versions or new service releases of the currently used version and allow to start the download. Does not send any data from within the program to the Internet, for example no system or user information or dongle ID, neither directly nor encrypted nor anonymized, of course no case data, not even the currently used version number, nothing. This option is active by default only if the program determines that it is running on the examiner's own system (if it is executed from the C: drive or if it was installed using the setup program). The check does not occur when running the program for the first time, so that you definitely have a chance to turn off this option before anything happens. Given the fact that most systems on which X-Ways Investigator and X-Ways Forensics are run do not have an Internet connection, this feature has a limited effect only.

• Whether new report table associations for selected files are created for the selected files only or also for their child objects or duplicates etc. is now a setting that is individual to each report table.

• The View | Refresh View menu command now also refills the directory browser if the directory browser has the input focus. Useful for example when a filter for tagged items is active and you remove the tag marks of some of the listed files, if you wish to update the listing in the directory browser and get rid of those files that are no longer tagged.

• Buttons that allow to expand or collapse all categories in the file type filter dialog. Expanding all categories can be useful if you would like to quickly find a certain file type by typing its letters while the tree view window has the input focus.

• New verbosity option: If totally unchecked in Options | Security, only exception errors with a potentially serious impact (like considerably incomplete analysis results) will be brought to your attention in the Messages window. If fully checked, all of them will be output, like before, even those that occur typically with corrupt files only and have no negative impact on other analysis results. The new default option is a reasonable compromise.

Miscellaneous

• Ability to copy up to ~4 GB of data into the internal clipboard in the 64-bit edition (~2 GB before and still in the 32-bit edition).

• New hash type available: Adler32

• The values of the bits in the volume attributes of HFS+ file systems are now output in the Technical Details Report.

• Option to only make a copy of tagged files for inclusion in a case report instead of all or none. Useful if you wish to reference all notable files with their metadata in your report, but show only a subset of those.

• Sorting by path accelerated.

• Many other minor improvements.

• Some minor fixes.

• Program help and user manual revised and updated for v16.9.

Changes of service releases of v16.8:

• SR-1: Search hits in the decoded version of files were erroneously highlighted in File mode, with their artificial offsets. That was avoided.

• SR-1: Fixed an error in the way that the 64-bit edition read exFAT file systems.

• SR-1: Fixed an error that could occur when copying e-mails with extremely long subject lines and attachments to an evidence file container.

• SR-1: Avoided warning about evidence objects in use in some situations where it is not necessary.

• SR-1: Fixed incorrect checkmark states in the Type filter dialog after double-clicking that could occur in Windows versions newer than XP.

• SR-1: X-Ways Imager download updated with v16.8. Now includes a 64-bit edition, which is very useful as a powerful disk imaging and disk cloning program for the 64-bit edition of the lightweight Windows PE or FE.

• SR-2: A 64-bit edition of the ordinary (not dongle-based) version of WinHex is now available to users with a professional or specialist license. Memory requirements of WinHex are very low, so that the extended logical memory address space of the 64-bit edition does not count as an advantage. However, unlike the 32-bit edition, the 64-bit edition can be executed from a 64-bit Windows PE such as the one that you can boot from your 64-bit Windows 7 or Windows 8 installation CD or that you can boot from your hard disk with a Windows 8 installation in case of problems. This is useful for example if you wish to edit/repair or wipe sectors in the partition that contains your installation of Windows, which are otherwise write-protected by Windows Vista or later. More information about Windows PE. Licensed users can retrieve the download link of the additional 64-bit files from the usual web page. The setup program remains a 32-bit program. As a portable application, WinHex does not need to be and should not be installed using the setup program.

• SR-2: Avoided an infinite loop that could occur in v16.8 when running a file header signature search for index.dat records in free space.

• SR-2: Fixed an exception error that could occur when loading old variants of the old evidence file container format.

• SR-2: Prevented a rare exception error that could occur when taking snapshots of Ext file systems.

• SR-3: Fixed an exception error in the 32-bit edition of X-Ways Forensics 16.8 that could occur after taking a snapshot of FAT volumes.

• SR-3: Creating many thousands of report table associations at a time or importing them from an evidence file container could be very slow in v16.8. That was fixed.

• SR-3: Intelligent naming for prefetch files in file header signature search.

• SR-4: Some issues in X-Ways Imager were fixed.

• SR-4: The owner ID of files originating from NTFS volumes was not passed on from 1st generation evidence file containers to 2nd generation containers. That was fixed.

• SR-4: Sorting by evidence object no longer sorts alphabetically, but by the position of the evidence object in the case tree. This is much faster and perhaps even expected or desired by most users.

• SR-4: The "Do not sort list" command now automatically refills the directory browser with the same items in the order in which they are referenced by the volume snapshot(s). Useful especially for users of X-Ways Investigator who are used to working with an unsorted list, accidentally click a column header and do not know how to refill the directory browser.

• SR-4: Detects certain non-standard GIF pictures that can cause exception errors and does not try to process them any more to avoid problems.

• SR-4: Ability to supply your own bitmap (16x16 pixels) that marks files as already viewed in the directory browser if you do not like the standard light green color. Provide it as a file named 9.bmp in the same directory where the .exe file is located.

• SR-5: Improved ability to extract sender and recipient fields from artificial PST e-mail archives created by SysTools NSF to PST conversion.

• SR-5: Minor improvements in Exchange EDB extraction.

• SR-5: Registry report for Windows 8 registry hives as complete as for earlier Windows versions.

• SR-5: X-Tensions that are invoked via Tools | Run X-Tensions are now applied by default to the active data window if a data window is open, just like via Specialist | Refine Volume Snapshot.

• SR-5: Avoided certain situations where tagging a large number of files in large volume snapshots was extremely slow. (Please report back if you continue to have such a problem.)

• SR-6: Fixed an error that could occur when extracting e-mail from Exchange EDB databases.

• SR-6: Since v16.4, the Type and Category filters did not reliably address all numeric file types such as .123, .000, .001. That was fixed.

• SR-6: Fixed an exception error that could occur under certain circumstances when creating previews for index.dat files.

• SR-6: Fixed a rare exception error that could occur when extracting e-mail from MBox e-mail archives.

• SR-6: Fixed freeze that could occur when processing certain files named cache.db.

• SR-6: Improved compatibility of evidence file containers of the new format mounted with Mount Image Pro when copying directories using Windows Explorer.

• SR-7: File type verification signatures slightly updated.

• SR-7: Fixed an error that could occur when processing SQLite databases.

• SR-7: Fixed some errors that could occur when processing certain corrupt files.

• SR-7: Prevented a situation where the 64-bit edition could hang when using the option "Skip and exclude data in free clusters" in disk imaging.

• SR-7: Fixed an error in v16.8 that in certain situations (more often on computers with many processor cores) created a small amount of invisible surplus data at the end of compressed .e01 evidence files which could lead to a wrong verification hash and a read or CRC error message in other tools although all the data that was presented and user-accessible in the same tools was 100% correct.

• SR-7: Fixed errors that could occur when reaching the limit of ~176 million search hits.

• SR-8: Fixed a data error that occurred when imaging media with more than 4,294,967,295 sectors.

• SR-8: Avoided an exception error with certain non-standard volume labels in FAT file systems.

• SR-8: Fixed an exception error that could occur in the 64-bit edition when processing .evtx event log files.

• SR-8: Fixed an exception error that could occur when processing certain MSG files.

• SR-9: E-mail extraction from MSG files improved.

• SR-9: Prevented distorted text proportions that could occur on cover pages when printing multiple files with the viewer component at the same time.

• SR-9: Fixed an error in the search function of the registry viewer.

• SR-9: Fixed crash of the Recover/Copy function with overlong file paths in the not dongle-based version of WinHex.

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)