X-Ways Forensics 17.1 Log Out | Topics | Search
Moderators | Edit Profile

X-Ways User Forum » Public Announcements » X-Ways Forensics 17.1 « Previous Next »

Author Message
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Sunday, Apr 21, 2013 - 19:15:   

A preview version of X-Ways Forensics 17.1 is now available (32-bit and 64-bit edition). The download link can be retrieved as always by querying one's license status.

What's new?

* Extracts much more nicely formatted data from Skype main.db database files than before, such as phone calls, sent text messages (SMS) and chats.

* Improved file type verification of encrypted MS Office 2007/2010 documents.

* Better support for unusually deep subdirectory nestings in Ext file systems.

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

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

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

* 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 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).

* Russian translation of the user interface.

* Several minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Tuesday, Apr 23, 2013 - 19:37:   

Preview 2:

* 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 avoid any risk 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 of xwforensics.exe and xwforensics64.exe 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.

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

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

* Ability to interpret raw images whose segments have 4-digit filename extensions (.0001, .0002, ...), in addition to the conventional 3-digit extensions.

* Minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, Apr 24, 2013 - 16:52:   

Preview 3:

[see Preview 4 for a totally revised description]
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Thursday, Apr 25, 2013 - 21:13:   

Preview 4:

* [Description and functionality significantly updated since Preview 3:]

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 that contain only those sectors that are needed for certain purposes, while maintaining compatibility with other tools. Forensic license only. 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 already, when partition tables and boot sectors have to be parsed, so that these essential data structures that define partitions and identify file systems are included in the skeleton image.

So 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 actually taken. Again, all the sectors read from the source hard disk in the process are simultaneously copied to the image, and that is the file system data structures, e.g. $MFT in NTFS, all directory clusters in FAT, and the catalog file in HFS+. That adds considerably more administrative data and also metadata to your skeleton image, but still no or almost no user contents. 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 file A that you preview is not acquired by the preview action already although it turns out to be irrelevant. 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 (can be done in X-Ways Forensics using the Tools | File Tools | Copy Sparse command) 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, it is sufficient to hash the sector ranges again that were actually transferred, according to the .log file and compare the hash values to those according to the .log file. An automated function for that might be introduced in a future release. To verify whether the .log file is unchanged, it will hashed itself when closed, and the resulting valuable all encompassing hash value is stored in a .log.log file. It might be desirable to also verify that all unused areas in a skeleton image are still unallocated/filled with binary zeroes.

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, files in zip archives, 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

* Program help updated.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Monday, Apr 29, 2013 - 14:39:   

Beta 1:

* Skeleton image concept further updated and completed (description updated above). Program help also updated accordingly.

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

* Slightly improved treatment of remote network drives, network shares, and F-Response connector volumes.

* Some minor improvements.

* Same fix level as v17.0 SR-5.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, May 1, 2013 - 21:27:   

Beta 2:

* Ability to automatically verify skeleton images immediately after creation or at any later time. This is a special verification option that checks all the individual hashes for copied sector ranges according to the .log file, and also verifies that the .log file itself is still authentic by checking that file's hash values and comparing it to the one in the .log.log file (the log file about the log file, if such a secondary log file was created). Compared to ordinary hash computation and verification, this method can save a lot of time. It just depends on the amount of actually acquired data (e.g. 100 MB), not the total size of the source disk / nominal size of the image (e.g. 1 TB).

* 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 convert it to an unencrypted image.

* Ability to uncover JPEG 2000 pictures in PDF documents.

* Several minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Monday, May 6, 2013 - 21:49:   

Beta 3:

* Provides timestamps from Internet browser SQLite databases as events.

* New extraction methods for MBOX and DBX updated to also produce slim .eml files without embedded attachments.

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

* More information about exception errors in error.log files.

* 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).

* Some minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Thursday, May 9, 2013 - 20:15:   

Beta 4:

* PDF metadata extraction further revised.

* 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").

* Program help updated.

* Some minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Tuesday, May 14, 2013 - 7:39:   

v17.1 has just been released.

Some of the not yet announced improvements include support for certain LVM2 partition layouts that were not recognized before and a fix for an error in Intel Hex to binary conversion.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, May 15, 2013 - 21:51:   

SR-1:

* Fix for PDF metadata extraction.

* Fixed inability to manually carve data from slack space of files in File mode.

* E-mail extraction from DBX and MBOX slightly improved.

* Can share the same local dongle again with instances of old versions.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Friday, May 17, 2013 - 15:59:   

SR-2:

* Fixed certain exception errors of v17.1 that could occur when refining the volume snapshot, in particular when extracting metadata from executable files.

* Fixed potentially wrong attributes of e-mail messages extracted from MBOX and DBX e-mail archives.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, May 22, 2013 - 9:53:   

SR-3:

* Fixed "cannot read" error of v17.1 when opening volume snapshots saved by v17.0.

* Prevented exception error that could occur in v17.1 with e-mails of a certain format.

* Fixed inability of v17.0 and newer to open files with child objects in evidence file containers of the old format. (A new volume snapshot needs to be taken.)

* Timestamps in certain registry events were potentially off by some hours. That was fixed. (Events need to be regenerated.)

* Some minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, May 29, 2013 - 20:41:   

SR-4:

* Resolving hard links in HFS+ file systems has been accelerated.

* When matching hash values against the hash database, if the same hash values are found in hash sets of different hash categories, not only a warning is output in the Messages window, but also one such hash value as a reference.

* Fixed an instability error that could occur when processing thumcache*.db files.

* Fixed inability of X-Ways Investigator SR-3 to read pictures from evidence file containers of the old format in certain situations.

* With some rare Base64 format variants, the new extraction method for MBOX e-mail archives potentially missed some attachments. That was fixed.

* Some fixes for XML export.

* Some exception errors fixed.

* Some errors in PDF extraction fixed.

* Some minor improvements.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Tuesday, Jun 4, 2013 - 20:51:   

SR-5:

* Fixed an exception error that occurred when copying selected files to skeleton images (64-bit edition only).

* Fixed some other exception errors.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Tuesday, Jun 11, 2013 - 14:15:   

SR-6:

* Prevented exception errors when processing certain e-mails in MSG and EML format.

* Some other exception errors fixed.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Monday, Jun 17, 2013 - 13:37:   

SR-7:

* Fixed some errors that could occur during metadata extraction.

* In v17.0 and v17.1, thumbs.db files were not marked as having child objects once the contained thumbnails were uncovered. That was fixed.

* Fixed some other errors.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Friday, Jun 28, 2013 - 19:33:   

SR-8:

* Some errors fixed.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, Jul 17, 2013 - 21:19:   

SR-9:

* Some of the fixes and a few of the minor improvements introduced in later versions. Available on request and highly recommended to users whose update maintenance covered no more than v17.1.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Wednesday, Oct 30, 2013 - 17:44:   

SR-10:

* Some of the fixes and a few of the minor improvements introduced in later versions. Available on request and highly recommended to users whose update maintenance covered no more than v17.1. This is probably the last service release for v17.1.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Saturday, Jan 25, 2014 - 15:10:   

SR-11:

* Some of the fixes and a few of the minor improvements introduced in later versions. Available on request and highly recommended to users whose update maintenance covered no more than v17.1. This is the last service release for v17.1.

Add Your Message Here
Post:
Username: Posting Information:
Only registered users may post messages here, i.e. you need to have a profile.
Password:
Options: Enable HTML code in message
Automatically activate URLs in message
Action:
Forum operated by X-Ways Software Technology AG.