Forensics Question: | |
OS Version: | |
Tools: |
Validation of X-Ways Forensics Evidence File Containers
Purpose
The purpose of this paper is to document testing to determine whether X-Ways Forensics Evidence File Containers are a verifiable option for the purpose of creating custom data images from a digital device.
Background
The traditional forensic approach to digital evidence examinations includes powering down the computer, imaging the entire storage device, and processing the image for analysis. This approach has become complicated with the ever-increasing size of data storage devices. In the current business environment, it is common for small businesses or small municipalities to maintain multiple servers, dozens of desktops and laptop computers, employ external storage devices such as USB thumb drives, and issue numerous smartphone/tablets to employees. The full forensic imaging and processing of a single 1 terabyte hard drive can require up to a full day. Even with this dramatic increase in data storage, the SANS Institute claims, “99% of forensic analysis focuses on 1% of the data” (Lee, 2018, p. 24). The concept of custom or triage data acquisition has been accepted within the forensic community to assist in addressing the problem. Custom or triage acquisition involves the capturing of selected data from a digital device so the selected data can be processed and analyzed more quickly. Rather than performing full forensic imaging and analysis on all computer devices, the smaller custom triage acquisition could be processed to identify those computers relevant to the overall investigation. A decision could then be made as to whether the relevant computers would be subjected to a full forensic analysis, or if the custom triage acquisition was sufficient for the investigation needs.
In addition to expediting review and analysis of multiple digital data storage devices, other reasons have emerged for the creation of custom data images. Given the current emphasis on privacy and data protection, a custom data image can be successfully used to limit the over-collection and over-sharing of irrelevant data. Consider the situation where a computer has multiple users, but only one of those users is the subject of the inquiry. A custom image can be created including only the relevant user’s profile thus excluding those users not relevant to the investigation. This technique could also be useful in situations where a subpoena or court order may limit the data which can be extracted and reviewed from a digital storage device.
X-Ways Forensics (XWF) is a commercial forensic software program which offers the option to produce a custom data image. XWF refers to its custom data image as an Evidence File Container. An XWF Evidence File Container is considered comparable to the more recognized Custom Content Image created by Access Data’s FTK Imager. Due to its cost (free) and compatibility with other forensic tools, FTK Imager is one of the most commonly used computer forensic tools employed to create triage custom data images. In comparison to FTK Imager’s Custom Content Image, the creation of an XWF Evidence File Container requires a paid XWF license. Also relevant to this analysis is XWF’s failure to recognize a FTK Custom Content Image; therefore, the use of XWF to create and analyze smaller custom data sets is incumbent upon the Evidence File Container1. Comparisons between FTK Imager’s Custom Content Image and XWF Evidence File Containers will be made throughout this paper.
Creating an Evidence File Container
XWF Evidence File Containers, like FTK Imager’s Custom Content Image are created in a logical image format which contain only files and folders selected by the analyst. XWF claims that Evidence File Containers preserve those included files with practically all their external metadata. XWF Evidence File Containers are unique and not to be confused with other forensic image formats. An XWF Container File is not a sector image format (i.e., DD or E01), and are created as raw logical images with the special X-Ways File System 2 (Shavers & Zimmerman, 2014, p. 34). XWF allows Evidence File Container raw images to be converted to the .e01 file extension, but using the .e01 file extension with containers can be confusing. According to the X-Ways website, this conversion to an .e01 extension does not convert the image to the universally acceptable sector level Expert Witness (E01) image format. Placing the .e01 extension on the container may lead other examiners to believe the image is the more compatible Expert Witness sector image format instead of the logical image format of the Evidence File Container.
Creation of an Evidence File Container is straight forward for an XWF user with a base understanding of the software. To begin creation of an Evidence File Container, select Specialist > Evidence File Container > New from the menu, and provide a name for the container (Shavers & Zimmerman, 2014, p. 34). Only one Evidence File Container can be open at a time, so to open a new container, the current container must be closed. This feature of Evidence File Containers will become significant as the testing underlying this paper proceeds. The default option for creating a raw Evidence File Container will have a .ctr file extension. Once the container is created, it is available to receive copies of files and/or directories. Files can be identified for inclusion in the Container either by manually browsing through the drive/image to locate files to be included, or by using XWF filtering options to identify files. To use the manual method, navigate to the file(s) to be included in the Container, right-click on the item(s) from the directory browser and select “Add to Container name.ctr”.
To use filtering options to add specific file types to the Evidence File Container, the analyst should first recursively list all files in the drive/image by right-clicking on the Case Root in the Directory Tree viewing pane. This right-clicking action will open a context box where the recursive listing of all files in the drive/image is offered. Next, the analyst should open the Directory Browser filter options by using the menu item Options > Directory Browser. The Directory Browser Option and Filters dialog box will appear. As an example, to filter for all Prefetch files in the drive/image, the analyst will select the Filter icon next to Type > expand the Windows Internals listings > then check the radial box by ‘pf – Prefetch’. Once the Prefetch file type is selected, the analyst will press the Activate radial button. These steps will display all the Prefetch files on the drive/image in the Directory Browser pane. The analyst could then select all or a portion of the Prefetch files in the Directory Browser for inclusion in the container. To include files in the container, right-click the highlighted files then select “Add to Container name.ctr”.
Once all the files are selected for inclusion in the Evidence File Container, the Container file should be closed. To close the Evidence File Container, select Specialist > Evidence File Container > Close. Once the container is selected for closure, XWF provides two options for creating the container image. The container can remain in its default raw (.ctr) format, or the option is presented to convert the container with an .e01 file extension. Creating a raw image container does not calculate a hash value for the container and no container acquisition log file is generated. When compared to FTK Imager’s Custom Content Image, FTK Imager creates an image acquisition log and a verification hash value for the entire Custom Content Image. The calculated hash value contained in the log is important for digital forensic analysts. The analyst can use the acquisition hash verification value to perform a post-examination comparison of the Custom Content Image’s hash value. This comparison will validate no changes had been made to the Custom Content Image during the examination processing. Since no acquisition log or calculated hash value is included with XWF Evidence File Container in the raw format, the analyst will have to perform the extra step of manually calculating a hash value for the .ctr image. The analyst should also store this calculated hash value in a created text file for later comparison with the calculated post-examination hash verification value.
As previously stated, the Evidence File Container converted to the .e01 file extension can be confusing if the container is passed to another examiner who mistakes the container for the traditional E01 (Expert Witness) image format. However, the Evidence File Container with an .e01 file extension does offer some advantages. The container converted to the .e01 file extension allows for compression of the container, the splitting the container into segments, encryption of the container, and generating a hash verification value for the Container. The .e01 container format also generates a container acquisition log which includes the acquisition hash verification value. When using the container converted to the .e01 file extension for Evidence File Containers, the container can also be ‘frozen’ which will prevent more files or folders from being added to the container. When frozen, the Evidence File Container becomes read-only which can be advantageous in a forensic environment.
Once closed, container files in the raw (ctr) format or the e01 format can be added to an XWF case like any other evidence item (Shavers & Zimmerman, 2014, p. 36).
Content of the Tested XWF Evidence File Containers
For the purpose of creating a test Evidence File Container data set, a WINDOWS 7.E01 full forensic image was used. The WINDOWS 7.E01 image was loaded into XWF version 19.9, service release 1, x-64 edition as an evidence item. The full WINDOWS 7.E01 image was created from a 500-gigabyte internal hard drive with the Windows 7 Ultimate operating system installed. Creation and validation of this complete forensic image required 3 and a half hours using a TD3 Tableau Forensic Imager. While an Evidence File Container could be created from a live system loaded into XWF, using the ‘dead box’ E01 forensic image as the original evidence for creating the test Evidence File Containers was selected. Using the ‘dead box’ E01 full forensic image as a baseline ensured each of the Evidence Container Files created during testing would include identical data for comparison. If the testing was performed on a live system, data on the system could change between the creation of multiple containers making comparison between containers more difficult. To limit the size of the data set to be tested, the following data artifacts were selected for inclusion in the Evidence File Container tests:
Registry Hives including the ntuser.dat, the UsrClass.dat, the SAM, the SOFTWARE, and the SYSTEM files;
Internet Explorer version 10+ browser data contained in WebCacheV01.dat;
LNK files, and Jump List files; and
Prefetch files from the folder contents at Windows\Prefetch\.
The verification and validation testing plan used as the basis for this paper included the creation of containers in both the raw (.ctr) format, and those converted to the .e01 file extension. Once those containers were created, a new XWF case would be opened with each separate container loaded as evidence. Comparisons would be performed for both the entire containers as well as with the individual files within each container. To accomplish the validation of all the individual files within each container, the original WINDOWS 7.E01 image was used to create a hash set2 within XWF. The hash set was named ‘XWF_Container_Test,’ and included all the files used in the creation of each of the Evidence File Containers. The hash set contained SHA-1 hash values from the 279 selected files to be included in each container.
Verification and Validation Standards for Custom Images
In order for XWF Evidence File Containers to be a viable option for the collection of custom images, they ideally should be verifiable at both the complete container and individual file levels. The following testing plan will be used to verify and validate the various Evidence File Containers:
Verification of the files contained in the container as exact matches with those files taken from the original WINDOWS 7.E01 source;
Comparison of container acquisition hash verification values for each created container with the post-analysis verification hash value of the container. Matching verification values will validate that no files or data contained within the container were changed during analysis of the container; and
Since each container will be comprised of the same files from the original source, a comparison will also be made between hash verification values of the created containers to determine consistency between containers.
Verification and Validation of XWF Evidence Container Files
Raw Format Container Creation, Verification and Validation
Using the listed files in Section IV above, an Evidence File Container was created in the default raw container format (.ctr file extension). When creating a container in the raw format, only a single file was created (XWF_Container_Test.ctr). As previously stated, when creating a container in the raw format, no container acquisition log file is created. The creation of XWF_Container_Test.ctr was completed in less than five seconds, so the time required to create the container was significantly less than the three plus hours required to create the full forensic image for WINDOWS 7.E01. The file size of XWF_Container1.ctr was 188,014 KB.
Since no hash verification value was initially calculated by XWF in the creation of XWF_Container_Test.ctr, the third-party tool Hasher (version 1.9) was used to calculate the Base-16 SHA-1 hash value for the container. The calculated hash value was EBCF201F33D26A7ED1C45FC6F82E7208A7238C80. This acquisition hash verification value was saved to a text file for later comparison.
A new XWF case was begun with XWF_Container_Test.ctr added as the evidence item. Using the Refine Volume Snapshot (Specialist > Refine Volume Snapshot) options, SHA-1 hash values were calculated for all files within XWF_Container_Test.ctr. After the hash values were calculated, these calculated values were compared to the hash values in the previously created ‘XWF_Container_Test’ hash set. After this comparison, XWF determined all 279 files within XWF_Container_Test.ctr matched the SHA-1 calculated hash values of the respective original files from the WINDOWS 7.E01 forensic image. In the screenshot below, notice the Hash Set column where all files match the XWF_Container_Test Hash set.
Figure 1 – Individual Files from Container Matching XWF_Container_Test Hash Set
With the XWF_Container_Test.ctr case still open, XWF was used to view the properties for XWF_Container_Test.ctr To view the evidence properties, the XWF_Container_Test.ctr evidence item was right-clicked from the Directory Tree viewing pane. Selecting the Properties option opened a Properties dialog (see Figure 3 below). No hash values were initially listed as calculated for this container. To calculate hash values within XWF, the Compute Hashes button within the Properties dialog was selected. XWF calculated the SHA-1 hash verification value for XWF_Container_Test.ctr as EBCF201F33D26A7ED1C45FC6F82E7208A7238C80 which matched the Hasher calculated value (See Figure 2).
Figure 2 – SHA-1 Calculated Hash for XWF_Container_Test.ctr
After XWF calculated the hash value for the XWF_Container_Test.ctr evidence item, the properties of the container were again viewed. Now, the calculated SHA-1 hash value for the XWF_Container_Test.ctr evidence item displayed in the Properties dialog box. A screenshot of the XWF_Container_Test.ctr Properties panel after calculation of the hash verification value is provided:
Figure 3 – XWF_Container_Test.ctr Properties Pane Now Showing SHA-1 Hash Value
As will be seen later (see Figure 8 below), the Compute Hash verification value was added to the Description panel of the container Properties dialog. This logging of subsequent hash verification values is similar to, but slightly different when compared to subsequent hash verification of FTK Imager’s Custom Content Image. When FTK Imager creates a Custom Content Image, an image acquisition log including the hash verification value(s) is generated. Any subsequent image verification using FTK Imager is appended to the original acquisition log3.
From this initial test of the raw format Evidence File Container, the individual files contained within the container were determined to be exact matches to those files from the original source. Testing also validated the entire container could be verified using both XWF and third-party hash verification tools. Finally, testing determined that the contents of the container were unaltered during the analysis phase.
.e01 File Extension Container Verification and Validation Using Compression
Using the same procedures as detailed above to create the raw (.ctr) container, a new Evidence File Container was created. When this second container was closed, the option to convert the Evidence File Container to the .e01 file extension format was selected. When selecting this option, a pop-up dialog panel appeared. Below is a screenshot of the pop-up dialog. As previously stated, the pop-up dialog warned the user, “Note that such a conversion has no compatibility benefits as some users for some reason believe it has. Raw images are more universally understood than .e01 evidence files.”
Figure 4 - .e01 Container Conversion Pop-up Dialog
In creating the container converted to the .e01 file extension, options to calculate a SHA-1 hash value for the container, to immediately verify the created container, to create the image with fast, adaptive compression, and to freeze the container were selected. Due to the small size of the container, it was not split into segments. Creation of the converted container was also completed in less than five seconds. When using these options to convert the .e01 container, three files were generated - XWF_Container_Test_e01.ctr, XWF_Container_Test_e01.e01, and XWF_Container_Test_e01.txt.
The XWF_Container_Test_e01.txt file was the container acquisition log. This acquisition log contained several pieces of information about the converted container. It identified the source of the conversion as XWF_Container_Test_e01.ctr which implied that the raw (.ctr) container was created first with the conversion performed from the raw container. The log also contained the user supplied description of the created container. It also identified the use of fast, adaptive compression in creating the image and that the compression ratio was 71%. The log also contained the size of the converted container, and that 279 files were included in the container. Finally, the log contained the computed SHA-1 hash value for the container – 94187061914F80A91705B7844FD10FDDB4355CF4. This hash value can later be used to validate the entire container file.
The raw format XWF_Container_Test_e01.ctr was created first during the conversion of the container to the .e01 file extension. The XWF_Container_Test_e01.ctr had a Windows operating system file creation date and time of 3/11/2021 at 3:54 pm, and it had a file size of 188,014 KB. This file size matched the file size of XWF_Container_Test.ctr created during the initial test. Using the third-party hash calculation tool Hasher, the SHA-1 calculated hash value of XWF_Container_Test_e01.ctr was 0228C4ED8E576F517B08426FE4B3A5CAF1BC64E8. This hash value did not match the value recorded in the XWF_Container_Test_e01.txt acquisition log. It also did not match the hash verification value of the XWF_Container_Test.ctr container created in the initial test, even though the two containers were generated from the same individual files. In comparison to FTK Imager Custom Content Images, the creation of two separate containers from an identical source would generate matching hash verification values. This differing container hash verification value between the two created raw containers will require further testing to identify the cause. A possible explanation for the mis-matching hash verification values between XWF_Container_Test_e01.ctr and XWF-Container_Test_e01.e01 was the use of compression when converting the raw container to the .e01 file extension. Additional testing will be performed to determine whether this explanation is correct. To further test the XWF_Container_Test_e01.ctr container, a new XWF case was initiated with XWF_Container_Test_e01.ctr added as the evidence for the case.
Once added, the properties for XWF_Container_Test_e01.ctr were viewed. The Properties dialog pane (see Figure 5 below) seems to have populated the SHA-1 hash value for the raw (.ctr) image from the acquisition SHA-1 hash value contained in the XWF_Container_Test_e01.txt container acquisition log.
Figure 5 – Initial Properties Panel for XWF_Container_Test_e01.ctr
With the properties pane still opened, the Verify hash button for the evidence container was selected. This produced a SHA-1 verification error (see Figure 6 below).
Figure 6 – XWF_Container_Test_e01.ctr Verification Error
Using the Tools > Compute Hash option from within XWF, a SHA-1 hash value was then calculated for the XWF_Container_Test_e01.ctr container. The resulting hash value (see Figure 7 below) was 0228C4ED8E576F517B08426FE4B3A5CAF1BC64E8 which matched the value calculated by the third-party tool Hasher.
Figure 7 – XWF_Container_Test_e01.ctr SHA-1 Hash Compute
After using the Hash Compute option, the Properties Panel was again accessed from XWF_Container_Test_e01.ctr. Scrolling down the Description window on the right side of the panel identified the displayed the SHA-1 hash value as ‘taken from .txt” supporting the theory that the displayed hash value for XWF_Container_Test_e01.ctr was taken from the container acquisition log. Also notice the re-computed hash values for the container which list the SHA-1 hash value 0228C4ED8E576F517B08426FE4B3A5CAF1BC64E8. These re-computed values match the calculated Hasher SHA-1 hash value, but report an error when compared to the hash verification value associated with the container from the .e01 container acquisition log.
Figure 8 – XWF_Container_Test_e01.ctr Properties Showing SHA-1 Taken from .txt
Using the Refine Volume Snapshot options, SHA-1 hash values were calculated for all files within the XWF_Container_Test_e01.ctr container. These calculated values were then compared to the values in the ‘XWF_Evidence_Container_Test’ hash set, and XWF determined all 279 files contained within the XWF_Container_Test_e01.ctr matched the SHA-1 calculated hash values of the respective original files from the WINDOWS 7.E01 full forensic image.
While this test verified the individual files contained within the XWF_Container_Test_e01.ctr container, it also incorrectly assigned the container hash verification value from the .e01 container acquisition log.
XWF_Container_Test_e01.e01 was the Evidence File Container converted to the .e01 file extension. It had a file size of 53,709 KB, and had a Windows operating system created date and time of 3/11/2021 at 3:58 pm. This created date and time value confirmed the raw XWF_Container_Test_e01.ctr was created approximately 4 minutes before the .e01 file extension converted container. When compared to XWF_Container_Test_e01.ctr, the .e01 converted version was less than a third of the size which confirmed the 71% compression ratio reported in the container acquisition log. Using the third-party tool Hasher, the SHA-1 hash value of the XWF_Container_Test_e01.e01 container was calculated as F53F67EC3BF11ADC59052874CF70E55D0C87ED39. This SHA-1 hash calculation resulted in a mis-matching verification value found in the container acquisition log. A new XWF case was initiated with XWF_Container_Test_e01.e01 added to the case.
Once added, the properties for XWF_Container_Test_e01.e01 were viewed. The Properties dialog pane (see Figure 9 below) populated the SHA-1 hash verification value for the converted .e01 container matched the value contained in the XWF_Container_Test_e01.txt acquisition log.
Figure 9 – XWF_Container_Test_e01.e01 Properties Panel
With the properties pane still opened, the Verify has button for the evidence container was selected. This produced a SHA-1 verification (See Figure 10 below).
Figure 10 – XWF_Container_Test_e01.e01 Verification
Using the Tools > Compute Hash option from within XWF, a SHA-1 hash value was calculated for the XWF_Container_Test_e01.e01 container. The resulting hash value (see Figure 11 below) was 94187061914F80A91705B7844FD10FDDB4355CF4 and matched the value contained in the container acquisition log. This testing demonstrated that XWF clearly recognized the converted .e01 container differently than the third-party tool Hasher.
Figure 11 – XWF_Container_Test_e01.e01 Calculate Hash Option
Using the Refine Volume Snapshot options, SHA-1 hash values were calculated for all files within XWF_Container_Test_e01.e01. These calculated values were then compared to the hash values in the ‘XWF_Evidence_Container_Test’ hash set, and XWF determined all 279 files contained within the XWF_Container_Test_e01.e01 matched the SHA-1 calculated hash values of the respective original files in the WINDOWS 7.E01 full forensic image.
The verification of individual files within Evidence Container Files were determined to be consistent as exact matches to the original source files whether raw containers or containers converted to the .e01 file extension were used.
Results of the comparison of entire container hash verification values were conflicting. XWF displayed and subsequently re-calculated the hash verification value for the .e01 converted container as matching the value contained in the acquisition log. This value could not be verified using third-party hashing tools. Additional testing will now be performed to focus on documenting why these conflicting hash verification values occurred.
.e01 File Extension Container Verification and Validation Without Compression
Testing will now focus on whether the effect of compression used in converting to the .e01 file extension container caused the conflicting hash verification values between XWF and third-party tools. Using XWF and the WINDOWS 7.E01 full forensic image, a third container, XWF_Container_NoCompress, was created using the same individual files and methodology employed to create the previous containers. When this third container was closed, the option to convert the container to the .e01 file extension format was selected; however, for this third container, no compression was selected. This process produced three files – XWF_Container_NoComp.txt, XWF_Container_NoComp.ctr, and XWF_Container_NoComp.e01.
The XWF_Container_NoComp.txt file was the container acquisition log. The log identified the source of the conversion as XWF_Container_NoComp.ctr and that 279 files were included in the container. The log did not include any compression information, and it contained the computed SHA-1 hash value for the container as A446A8D4222F3226997E024E307BAA175744D355.
XWF_Container_NoComp.ctr was created first during the conversion of the container to the .e01 file extension. The XWF_Container_NoComp.ctr had a Windows operating system file creation date and time of 3/12/2021 at 3:14 pm, and it had a file size of 188,014 KB. This file size matched the file size of the two previously created raw containers. Using the third-party tool Hasher, the SHA-1 calculated hash value of XWF_Container_NoComp.ctr was A33B365A82E4FAC989AF885D21568B4952E72C55 which did not match the SHA-1 hash value contained in the container acquisition log. This value also did not match the calculated hash values of the previously created raw containers even though all three containers were created from the same individual files. To complete the test of the XWF_Container_NoComp.ctr container, a new XWF case was initiated with XWF_Container_NoComp.ctr added to the case.
Once added, the properties for XWF_Container_NoComp.ctr were viewed. The Properties dialog pane (see Figure 12 below) populated the SHA-1 hash value for the raw (.ctr) image from the XWF_Container_NoComp.txt acquisition log. Once again, the properties of the raw container incorrectly reported the hash verification value for the container.
Figure 12 - NoComp.ctr Properties
With the properties pane still opened, the Verify button for the evidence container was selected. As in the previous test this action produced a SHA-1 verification error for the raw container.
Using the Tools > Compute Hash option from within XWF, a SHA-1 hash value was calculated for XWF_Container_NoComp.ctr. The resulting hash value (see Figure 13 below) was A33B365A82E4FAC989AF885D21568B4952E72C55 and matched the value from the third-party tool Hasher.
Figure 13 - NoComp.ctr Compute Hash
The Properties pane for XWF_Container_NoComp.ctr was reopened. Scrolling down the Description window on the right side of the panel displayed the re-computed hash values for the container which list the SHA-1 hash value as A33B365A82E4FAC989AF885D21568B4952E72C55, but also identified these values as a re-computed error since they did not match the value contained in the XWF_Container_NoComp.txt acquisition log.
Figure 14 - NoComp.ctr Properties Recompute Hash
Using the Refine Volume Snapshot options, SHA-1 hash values were calculated for all files within XWF_Container_NoComp.ctr. These calculated values were then compared to the values in the ‘XWF_Evidence_Container_Test’ hash set, and XWF determined all 279 files contained within the XWF_Container_NoComp.ctr matched the SHA-1 calculated hash values of the respective original files in the WINDOWS 7.E01 forensic image. This test again verified and validated that individual files contained within the XWF containers were exact duplicates of the files taken from the original source.
XWF_Container_NoComp.e01 was the converted Evidence File Container to the .e01 file extension without the use of compression. The container had a file size of 188,063 making it slightly larger than its raw format counterpart. XWF_Container_NoComp.e01 was created on 3/12/2021 at 3:16 pm (Two minutes after its source, XWF_Container_NoComp.ctr). Using the third-party tool Hasher, the SHA-1 hash value of the XWF_Container_NoComp.e01 container was calculated as 0DF24E9624D8C43ADCD4D892F8C0EE9A60B0E316, and again, Hasher’s SHA-1 calculated value for the converted .e01 container did not match the recorded hash verification value found in the container acquisition log. A new XWF case was initiated with XWF_Container_NoComp.e01 added to the case.
Once added, the properties for XWF_Container_NoComp.e01 were viewed. The Properties dialog pane (see below) populated the SHA-1 hash value for the converted .e01 container, and the Description pane (See Figure 15 below) reported the SHA-1 hash value as taken from the .e01 instead of the .txt (acquisition log).
Figure 15 – XWF_Container_NoComp.e01 Properties Panel
With the properties pane still opened, the Verify hash button for the evidence container was selected. This produced a SHA-1 verification (See Figure 16).
Figure 16 – XWF_Container_NoComp.e01 Verification
Using the Tools > Compute Hash option from within XWF, a SHA-1 hash value was calculated for the XWF_Container_NoComp.e01 container. The resulting hash value (see below) was A446A8D4222F3226997E024E307BAA175744D355 and matched the value contained in the container acquisition log. As documented in previous testing, XWF recognized the converted .e01 container differently than the third-party tool Hasher.
Figure 17 – XWF_Container_NoComp.e01 Calculate Hash Option
Using the Refine Volume Snapshot options, SHA-1 hash values were calculated for all files within the XWF_Container_NoComp.e01 container. These calculated values were then compared to the hash values in the ‘XWF_Evidence_Container_Test’ hash set, and XWF determined all 279 files within container matched the hash set values.
This third test once again verified that the individual files within the created containers were exact matches to the original source files. This third test failed to identify the use of compression as the reason why conflicting container hash verification values were reported when comparing raw format containers with its counterpart converted to the .e01 file extension.
Explanation for Entire Raw Container Unique Hash Values
The purpose of the testing used as a basis for this paper was to determine whether XWF Evidence File Containers were a verifiable option for creating custom data images from a digital storage device. Testing has verified that the individual files added to the containers are exact duplicates of the files obtained from the original source. This verification made the use of XWF Evidence Containers a viable option for creating custom data images. Additional testing also determined that even though these containers had the same files added from the original source, each raw container had a different hash verification value. For each raw container, the acquisition and post-analysis hash values matched. These matching values could be verified using both XWF and a third-party hashing tool. Matching acquisition and post-analysis hash values validate that no data in the container was altered during analysis. These factors further enhanced the validity that raw containers were an option for creating and analyzing custom data images. Even with the determination that raw format containers were a viable option for creating custom data images, testing of the raw containers would not be complete without determining why each container produced its own unique hash value.
To determine why each raw container produced its own unique hash value, a review and comparison of the first two sectors of the created raw containers was performed. While the purpose for all data offsets within the first two sectors could not be determined, data offsets were sufficiently identified to provide an explanation. Figure 18 below is a screenshot of the first sector for XWF_Container_Test.ctr (first test) as displayed within XWF with specific offsets highlighted:
Figure 18: XWF_Container_Test.ctr First Sector
The data offset at 0x000 through 0x00A included the container file header. This value was determined to be consistent throughout each of the tested containers whether the container was created in the raw (.ctr) format or converted to the .e01 file extension. The data identified at offset 0x050 through 0x053 identified the container file system - XWFS. This value is also consistent throughout each container. At data offset 0x080 through 0x087, the container creation date and time are recorded in Unix time format. Using DCode, version 4.02, the data contained at this offset could be converted to a human readable date and time. In this instance, the hexadecimal value at offset 0x080 through 0x087 was converted using DCode (see Figure 19 below). The decoded value was March 11, 2021 at 00:20:24 UTC -6, and the decoded value matched the Windows operating system creation date and time for XWF_Container_Test.ctr. As the reader may recall from earlier, two containers could not be opened at the same time making it impossible for two containers to have the same created date and time value embedded in the file. This would provide at least one explanation why no two Evidence File Containers would ever have matching hash verification values even if all the files in the container were exactly the same.
Figure 19 – DCode Interpretation of Unix Timestamp in XWF_Container_Test.ctr
Beginning at offset 0x090 in the first sector, the name of the container can be found (XWF_Container_Test). Since each container was given its own name, these values would represent a second explanation as to why no two Evidence File Containers would ever have matching hash verification values. Beginning at 0x110, the name of the Examiner provided to XWF during the creation of the Evidence File Container is displayed. For the containers created in this test, the Examiner name values would have remained the same.
Review of the second sector of the XWF_Container_Test.ctr identified two pieces of data recorded for the container. At offset 0x200, the version of the XWF software used to create the container was recorded. This value would have remained the same in all the containers created during the tests documented in this paper. At offset 0x250, the user provided description of the container begins. In the containers created during these tests, the container descriptions would have varied. When comparing separate raw containers, this description would provide a third explanation as to why unique hash verification values were produced.
Figure 20: XWF_Container_Test.ctr Second Sector
Reconciliation of Raw Containers with Converted .e01 Containers
With several explanations identified for unique hash verification values within the raw (.ctr) containers, a comparison was also made between the first sector sectors of the raw (.ctr) container used to convert the container to the .e01 file extension with the first sector of the .e01 converted container. As the reader may recall, when a container was converted to the .e01 file extension, XWF first created the container in the raw format. This raw format container was then used to convert the container a separate the container with the .e01 file extension. Twice during testing, a raw container was converted to the .e01 file extension – once using compression and once with no compression. On both occasions, the hash verification value for the raw container did not match the value for the container in the converted .e01 file extension. These unique hash verification values indicated changes to the actual containers may have occurred during the conversion process.
Figures 21 and Figure 22 below represent a comparative look at the first sectors for XWF_Container_Test_e01.ctr and XWF_Container_Test_e01.e01 (converted to .e01 file extension from XWF_Container_Test_e01.ctr).
Figure 21: XWF_Container_Test_e01.ctr First Sector
Figure 22: XWF_Container_Test_e01.e01 First Sector
By comparing Figure 11 with Figure 12, the first sectors of both containers are similar. Both have matching headers (0x000 – 0x00A) and a matching file system (0x050 – 0x053). Also noted is that both containers have a matching Unix time stamp at 0x080 – 0x087. The decoded value of this Unix time stamp is March 11, 2021 at 15:53:45 UTC -6. The decoded time stamp matched the creation date and time reported by the Windows operating system for the XWF_Container_Test_e01.ctr (raw container). Since both the Unix time stamp, Examiner name, and container name for both the raw and .e01 file extension containers had matching values, the review focused on any dissimilar data. As highlighted in Figure 21, container XWF_Container_Test_e01.ctr contained the value ‘64’ at offset 0x05C. This ‘64’ value was consistent with each of the raw format containers created during testing. Comparing the same offset data in Figure 22, the recorded value ‘74’ is present at hex offset 0x05C. This value was consistent with each container created during testing which was converted to the .e01 file extension. The two containers in Figure 21 and Figure 22 also record differing data at offsets 0x078 – 0x07B. The raw format container recorded data values at this offset, while the container converted to the .e01 file extension recorded no data (00 00 00 00). This difference in recorded data at offset 0x078 – 0x07B was also consistent when the raw format container was compared to the container converted to the .e01 file extension. To further confirm this difference in recorded data between a raw container and a container converted to the .e01 file extension, the first sector of XWF_Container_NoComp.ctr and XWF_Container_NoComp.e01 are displayed in Figures 23 and 24 below.
Figure 23: XWF_Container_NoComp.ctr First Sector
Figure 24: XWF_Container_NoComp.e01 First Sector
XWF_Container_NoComp.ctr (raw format) has the value ‘64’ at offset 0x05C, while XWF_Container_NoComp.e01 records the value ‘74’. Offsets 0x078 – 0X07B for the XWF_Container_NoComp.ctr container has stored data while the same offsets for XWF_Container_NoComp.e01 contain all zeros (no data). The conclusion drawn from these comparisons are that the data contained in these two mentioned hex offsets record whether the container is in a raw format or whether the container has been converted to the .e01 file extension.
A final point should be emphasized when comparing hash verification values for containers converted to the .e01 file extension. All raw containers produce matching hash verification values whether XWF or a third-party hashing tool is used the calculate the hash value. XWF and third-party tools are therefore calculating values by using the same data. When XWF calculates hash verification values for converted containers with the .e01 file extension, those calculated hash values do not match hash verification values calculated by third-party tools. More testing would be required to determine what triggers XWF to view .e01 converted containers differently than third-party tools. Testing has shown that the hash value calculated internally by XWF for the converted .e01 containers matches the value stored in the container acquisition log. Based on these testing results, third-party hashing tools should not be relied upon to validate .e01 converted containers.
Evidence File Container Compatibility with Other Tools
The XWF Evidence File Container is not in a sector image format such as E01 or DD which is recognized by most forensic tool applications. While the Evidence File Container is relatively easy to create within XWF, which forensic applications will successfully ingest the container for analysis?
As expected, XWF recognized the Evidence File Container just as any other evidence item. Belkasoft Evidence Center (BEC) was another commercial tool which successfully recognized the XWF Evidence File Container as an evidence item. Testing in 2019 verified the BEC successfully recognized and parsed data from the container during analysis. Due to the author’s lack of a current BEC license, no updated testing could be performed regarding BEC’s current recognition of Evidence File Containers. Using a trial version of Get Data’s Forensic Explorer (FEX), the XWF Evidence File Container was successfully loaded and data within the container was successfully analyzed. FEX is also a commercial application which required the purchase of a license for full functionality. Due to a limited budget, the Author was unable to test the full functionality of FEX regarding Evidence File Containers.
Autopsy, FTK Imager, and Magnet AXIOM were forensic applications which did not support the XWF Evidence File Container format.
Other forensic applications such as EnCase and Detego were not tested to determine whether it supported the XWF Container since the Author did not own licenses for these products.
Conclusions and Recommendations
XWF is a commercial computer forensic application which requires a licensing cost. XWF allows the analyst to create Evidence File Containers in two separate formats. The default raw container format (.ctr extension) is the more universally recognized format. The raw format can be converted to an .e01 file extension Evidence File Container. The .e01 conversion offers additional benefits to the analyst such as creation of an acquisition log, compression of the container, and splitting the container into file segments. However, XWF’s use of the converted .e01 file extension container can create confusion and has limitations. The Expert Witness sector image format also uses the .E01 file extension, and use of the converted container to an .e01 file extension may confuse Analysts into believing the XWF Evidence Container File is in fact the universally recognized Expert Witness forensic image format.
For the following reasons, XWF Evidence File Containers are a verifiable option for the purpose of creating custom data images from a digital device:
Individual files included in XWF Evidence File Containers were verified and validated as exact matches to the same files obtained from the original source. Individual file matches were validated whether the container was created in the raw (.ctr) format or whether the container was converted to the .e01 file extension. As such, individual files included in containers can be relied upon as exact duplicates to the original source files.
When the created container was in the raw (.ctr) format, no container acquisition log file was created and no acquisition hash value for the container was calculated. Subsequent to creation, validating hash value calculations could be performed for containers in the raw format using both XWF and third-party tools. Whether using XWF or a third-party tool, acquisition and post-analysis hash value verification of the raw containers could be performed.
Choosing to convert a raw container to the .e01 file extension was also a verifiable option for the purpose of creating custom data images from a digital device with the following limitations:
Examiners and Analysts receiving a container converted to the .e01 file extension should recognize it as an XWF Evidence File Container and not the more universally accepted Expert Witness format forensic image.
When a raw container is converted to the .e01 file extension, the created container acquisition log refers to the .e01 file extension container and not to the raw container format. If the original raw format container used in the conversion process is added as an evidence item to an XWF case, XWF will report inaccurate hash verification information about the container. The Analyst adding the raw container used in the conversion process must calculate a hash value for the container independently from the container acquisition log. This independent hash calculation can be performed within XWF or can be performed by a third-party hashing tool.
In order to correctly calculate the hash value of the raw container from within XWF, use the Tools > Compute Hash option.
When the converted .e01 file extension container is added to XWF as an evidence item, the verification hash value for the container can only be correctly re-computed and verified within XWF. Re-computation and verification of the converted .e01 file extension container should match the verification hash value contained in the container acquisition log. Third party hashing tools will not successfully verify the acquisition hash value of a converted .e01 file extension container.
AccesData Group. (2016, March 31). Imager User's Guide. 42. Lindon, Utah.Evidence Container Files. (n.d.). Retrieved July 2, 2018, from X-Ways Forensics: http://www.x-ways.netGetData Forensics. (2017). www.forensicexplorer.com. Retrieved 2019, from Forensic Explorer.Lee, R. (2018). Windows Forensic Analysis - FOR500. Bethesda, Maryland, Maryland: SANS Institute.Magnet Forensics. (2019). Magnet Axiom. Retrieved January 30, 2019, from Magnet Forensics: https://www.magnetforensics.comShavers, B., & Zimmerman, E. (2014). X-Ways Forensics Practitioner's Guide. Elsevier.
Reviewers found that the documentation of testing procedures is clear, concise, organized, and complete. References are appropriately cited. Reviewers were able to validate the author’s method. A few minor grammatical issues were identified by the reviewers.
Reviewers did not suggest any future work related to this paper.
Brett Shavers (Methodology Review, Validated Review using Reviewer Generated Datasets)
Ryan Wesley (Methodology Review, Validated Review using Reviewer Generated Datasets)