Create Disk Image/Make Backup Copy
This command in the File menu allows to create a backup or image of the currently open logical drive, physical disk, or individual file. There are three possible output file formats, each with unique advantages.
File format: WinHex Backup Evidence File Raw Image
Filename extension: .whx .e01 e.g. .dd
Interpretable as disk: no yes yes
Splittable: yes yes yes
Compressible: yes yes (NTFS)
Encryptable: no yes no
Optional hash: integrated integrated separate text file
Optional description: integrated integrated separate text file
Range of sectors only: yes (yes) (yes)
Applicable to files: yes no no
Automated maintenance: Backup Manager no no
Compatibility: no (yes) yes
Required license: none forensic personal
The major advantage of evidence files and raw images is that they can be interpreted by WinHex like the original disks (with the command in the Specialist menu). This also makes them suitable for usage as evidence objects in your cases. This holds true for evidence files in particular because they can store an optional description and an integrated hash for later automated verification. Raw images have the benefit that they can be easily exchanged between even more forensic tools. All output file formats support splitting into segments of a user-defined size. A segment size of 650 oder 700 MB e.g. is suitable for archiving on CD-R. Evidence files must be split at 2047 MB at most to make them compatible with X-Ways Forensics versions before v14.9 and EnCase versions before v6 and certain other tools. With a forensic license, raw image files and evidence files can automatically be verified immediately after creation, by recomputing the hash value that was originally computed from the medium, with the image instead.
Evidence file and WinHex backup compression is based on the "Deflate" compression algorithm that is part of the popular general-purpose library zlib. This algorithm consists of LZ77 compression and Huffman coding. With the "normal" compression level you can reach a compression ratio of 40-50% on average data. However, this comes at the cost of a considerably reduced imaging speed. "Fast/adaptive" compression is a very good and intelligent compromise between speed and good compression, not like the ordinary fast compression option in other programs. With "high" compression you gain only a few percentage points more compression, but at disproportional high cost. For WinHex backups, "adaptive" is the same as "normal".
Raw image files can be compressed at the NTFS file system level, if they are created on NTFS volumes. Either normal NTFS compression is used, or the image file can be made "sparse", such that large amounts of zero-value bytes won't need drive space.
Cleansed images: With a forensic license, there is an acquisition option for those users who need to or want to exclude certain files from forensic images, called "Omit excluded files". The data stored in clusters that are associated with files that you exclude before starting the imaging process will automatically be zeroed out in the image. Won't have any effect on files whose contents are not stored in their own clusters. Before you start the imaging process for a partitioned disk, open the partitions in which the files are located that you would like to exclude. Wait till the volume snapshot has been taken if it was not taken before. Then exclude the files. You do not need to open and take volume snapshots of partitions whose data you would like to include completely. All other data is copied to the image normally. There is an option to "watermark" wiped sectors in the image with an ASCII or Unicode text string, so that when working with the image you are reminded of the omission when you look at the affected areas. Cleansed images are useful for anyone who needs to redact certain files in the file system, but otherwise wants to create an ordinary forensically sound sector-wise image, compatible with other tools. A must in countries whose legislation specially protects the most private personal data of individuals and certain data acquired from custodians of professional secrets (e.g. lawyers and physicians, whose profession swears them to secrecy/confidentiality). Limitation: Not available for disks partitioned as Windows dynamic disks or with Linux LVM*. Only files in supported file systems can be omitted. Note that you can also retroactively cleanse (redact) already created conventional raw images, in WinHex, by securely wiping files selected files via the directory browser context menu. The granularity of this operation is not limited to entire clusters. For example, that means it can also wipe files in NTFS file systems with so-called resident/inline storage and it does not erase file slack along. For a comparison of evidence file containers, skeleton images and cleansed images please see our web site. All of those are images that only transport a subset of the original data.
Another kind of cleansed image is an image in which all the clusters marked by the file system as free are zeroed out (specialist or forensic license only). That is very useful if you create the image for backup purposes and not for forensic purposes, or if for forensic purposes you do not require data in free space or are not supposed to acquire it (to only examine existing files). In conjunction with compression, this option has the potential to save a lot of drive space, depending on how much free space there is, and imaging speed can be greatly accelerated if there are large contiguous free drive space areas in volumes/partitions. Note that in case of file system inconsistencies clusters could be erroneously regarded as free. If you wish to omit both certain (excluded) files and free clusters, also exclude the virtual file "Free space" and turn of "net free space computation" in the volume snapshot options.
You have to specifically confirm the creation of cleansed images as in the traditional sense they are not forensically sound (though in a more modern sense of the word they can be, depending on the jurisdiction that you work in in countries with stricter personal privacy rights and depending on the overall situation).
X-Ways Forensics checks for and warns of overlapping partitions when creating a cleansed image of a partitioned physical disk. Clusters in affected disk areas are not omitted. In such a situation, it is recommended to image the relevant partitions separately.
Forensic license: When creating an image, the technical details report is created and written to a text file that accompanies the image file. For an .e01 evidence file it is also incorporated directly into the .e01 file as a description. The SMART information is queried and written to the text file again upon completion of the image, so that you can see whether the status of a hard disk in bad shape has further deteriorated during imaging. Secondly, you can see how the "power on time" has changed, which is useful to deduce its unit of measurement (usually hours, but can be different on certain hard disk models). The text file also indicates the amount of time spent creating the image, the compression ratio achieved, the result of an immediate verification of the image based on the hash value (if selected), and any sector read errors.
Forensic license: Ability to create a second copy of an image immediately when imaging a disk, which is much quicker than copying the image file later and makes sense if the 2nd copy is created on a different drive. File spanning (i.e. when to start another image file segment) is kept in sync between both copies even when running out of space on one of the two target drives only.
Forensic license: You may specify an overflow location in advance where further image file segments will be stored should space on the primary output drive be exhausted. If you leave that field blank or if even the overflow location has no more space left, you will be prompted for a new path as before when needed. If an overflow location is specified in advance and at the same time you chose to create two copies of the image, then please note that the overflow location is used only for the first image copy that runs out of space, if any. For the other image copy you would be prompted if space is scarce.
Forensic license: Ability to compute two hash values simultaneously. If you make use of this option, then both hash values will be stored in the descriptive text file. The first hash value is the one that can be automatically verified when imaging completes. You could intentionally choose the faster algorithm for that as the main purpose at that point is to detect I/O errors and file errors. The second hash value is imported into the evidence object properties when adding the image to a case.
An option allows to exhaust system memory prior to the hash verification to invalidate and thwart any file buffers employed by Windows so that the data of the image is read directly from the disk for the verification and not taken from the memory buffer. This option exists for small images and for somewhat paranoid or uber-diligent users. It is not required for images that are much larger than the physical amount of RAM that is installed in your machine because by the time when the final parts of the image have been written, the initial parts are no longer in the buffer, and once the final parts are about to be verified they are no longer in the buffer because at that time the initial parts are in the buffer as they have been verified just before. Your system may behave a little bit sluggish for a while when using this option, and verification may be slightly slower than normally.
Forensic license: Ability to schedule in advance subsequent disk imaging operations in additional instances that will wait until already ongoing imaging operations in previous instances have completed, to avoid inefficient simultaneous creation of multiple images on the same output disk (which is unnecessarily slow and produces highly fragmented image files). Additional instances only wait for previous instances in which the checkbox for waiting was checked as well, but not for others.
Forensic license: If you cancel disk imaging in the middle of the process, X-Ways Forensics quickly finalizes the .e01 evidence file format (more precisely, the current segment) to guarantee a consistent image even though it is not a complete image. Useful for example in an emergency situation when imaging media on site, because a incomplete image that can be used without errors is better than an unusable corrupt image. If hashing was enabled, incomplete .e01 images even have a hash value that can later be verified later.
Forensic license: For the .e01 evidence file format, you may choose the internal chunk size. Might be regarded as useful by some to achieve a marginally better compression ratio for ordinary data, at the expense of more time needed when creating the image and when later randomly accessing data in the image, but improves compression noticeably for extremely compressible data (e.g. a wiped or unused areas of a hard disk). A 512 KB chunk size reduces the image size with ideal data (e.g. only 0x00 bytes) ceteris paribus by an additional 40% compared to a 32 KB chunk size.
Forensic license: The descriptive text file that is generated for images points out the exact sizes in bytes of all segments of raw images files and the exact chunk counts in all segments of .e01 evidence files. If for whatever reason one or more segments get lost or corrupted, this allows to create artificial placeholder segments of the right capacity to fill in any gaps, such that all the data in subsequent segments will have the correct logical distance from the data in preceding segments, to preserve validity of pointers within the data (partition start sectors in the partition table, cluster numbers in file system data structures) as long as the original image file segments that contain source and destination are available.
Forensic license: You may adjust the compression option while .e01 evidence files are being created. Useful if your priorities (higher compression rate or higher speed) change, for example when you see that drive space suddenly seems scarce or you have to finish the process quicker than previously thought. Also useful to experiment, when not sure which compression option might be best for a particular system configuration (e.g. when imaging a live system on site and having to write the image to an external hard disk via USB, where I/O is slow and the overall process may be faster with compression than without).
Forensic license: When imaging with active compression in .e01 format, X-Ways Forensics provides immediate visual feedback about the actual amount of data found on the disk. That is possible because disk areas that were never written as well as disk areas that were wiped achieve extremely high compression ratios. The rolling compression ratio is represented during imaging by vertical bars in a separate window. The higher the bar, the lower the "data density" in that area. The compression statistics are also stored in the .e01 evidence file, so that the same chart is also available at any later time from the evidence object properties dialog when you click the "Compression" button.
Forensic license: Ability to specify how many extra threads to use for compression when creating .e01 evidence files. By default X-Ways Forensics will use no more than 4 or 8, and it depends on how many processor cores your system has, but you could try to increase the number on very powerful systems with even more cores usually without problems, for a chance to further increase the speed, or you can reduce it you run into stability problems.
Forensic license: You have the option to change the nature of an image (disk or volume) and its sector size when creating the image. This is possible not only for .e01 evidence files, where both is explicitly defined in the internal metadata (compatible with other tools), but also for raw images (via external metadata, compatible only with X-Ways Forensics/Image v18.4 and later, lost if the image leaves the realm of NTFS file systems). Useful whenever the source of the data is not an ideal interpretation. For example if a reconstructed RAID actually represents a volume, not a physical disk, then you can already adjust the nature of the image accordingly when you create it. Or if the sector size of the reconstructed RAID or a disk in an enclosure does not match the sector size of the file system in a partition, you can adjust the sector size of the image accordingly. All of this will allow for smoother and more successful usage of the image later, in particular by users who do not pay much attention to details such as image type and sector size. With the additional metadata present for a raw image, X-Ways Forensics does not need to prompt users for the nature of the image and its sector size even if under normal circumstances it would (for example because the image does not start with an easily identifiable partitioning method or volume boot sector).
At the end of the imaging process, the computer can be optionally either shut down or (if supported by your system) hibernated, to save power. If you select hibernation and Windows signals that hibernation fails, X-Ways Forensics will instead try to shut down the system.
There is an option to add newly created images to the case and start refining their volume snapshot(s) automatically without further user interaction if the source disk had not been added to the case yet and if a case is open at that time when you start imaging.
Using this command is the recommended way to create a disk image. In order to image an arbitrary range of sectors, you could select a sector range as a block and copy it to a file via Edit | Copy Block | Into New File, or use Tools | Disk Tools | Clone Disk. The latter is particularly useful to partially image hard disks with severe physical defects (not just ordinary bad sectors) and can even copy sectors in reverse order.
For imaging automation please see command line parameters.
More hints on disk cloning and disk imaging
The encryption algorithm optionally used in .e01 evidence files is either 128-bit or 256-bit AES/Rijndael, in counter (CTR) mode. This allows for random read access within evidence files. The 128-bit implementation is newer and faster and supported only by X-Ways Forensics v16.4 and later. Encryption will render an .e01 evidence file incompatible with other tools. The encryption algorithm uses a 256-bit key that is digested with SHA-256 from the 512-bit concatenation of the SHA-256 of the password you specify and 256 bits of cryptographically sound random input (salt), which is stored in the header of the evidence file. For 128-bit AES the 256-bit key is reduced to 128 bit by xor-ing the first and second half. The 128-bit counter is randomized and incremented per encryption block, as a little-endian integer in 256-bit AES, as a big-endian integer in 128-bit AES. The encryption block size of AES is 128 bits. An additional SHA-256 is stored in the header as well (optionally for 256-bit AES, see Security Options) and used later to determine whether a password, specified by the user for decryption, is correct or not. The SHA-256 algorithm is applied to a concatenation of the salt, hash x, and hash y to compute this password verification hash, where hash x is the SHA-256 of the user-supplied password and hash y is the SHA-256 of the concatenation of the user-supplied password and hash x. For 128-bit AES, y becomes x and is concatenated and hashed over and over again, 100,000 times, to practically render rainbow table attack computationally infeasible. Please note that when you use compression and encryption at the same time, each chunk in an .e01 evidence file is first compressed, then encrypted. So an educated guess about the nature of the data in a given chunk might be possible, merely judging from the compressed size of the chunk (i.e. its compression ratio), even if the compressed data is encrypted.
If you have WinHex assign a filename for a WinHex backup automatically, the file will be created in the folder for backups (cf. General Options), named with the next free "slot" according to the Backup Manager's naming conventions ("xxx.whx"), and will be available in the Backup Manager. If you explicitly specify a path and a filename, you can restore the backup or image later using the Restore Backup command, and in case of split backups WinHex will automatically append the segment number to the filenames.