Evidence File Containers
Only available with a forensic license. The Specialist menu allows to create a new file container, open an existing one, and close the active file container. The directory browser context menu allows to fill it with selected files.
When you need to pass on a collection of selected files (even from different evidence objects) that are of particular relevance to a case, to other persons involved in that case, e.g. specialized investigators, who do not need to or must not see irrelevant files, evidence file containers may come in handy. Most file-system level metadata (name, path, size, attributes/file mode, timestamps, deletion status, classification as alternate data stream or virtual file or e-mail message or attachment, ...) and especially the contents of the file are fully retained in an evidence file container. Also when a conventional (physical, sector-wise) image is overkill because you need to acquire only selected files and not entire media, containers are recommended. Evidence file containers use a special file system (XWFS) that can accomodate most metadata from conventional file systems of the Windows, Linux, and Apple world.
Evidence file containers can be interpreted, added to a case and conveniently examined like other image files, and in particular also in X-Ways Investigator [CTR], the simplified version of X-Ways Forensics for investigators that are not computer forensic examiners, but specialized in other areas such as corruption, accounting, child pornography, building laws, ... The recipient of the container can add the container to his or her own case, view the files that it contains just like in a disk partition or a conventional image, can run keyword searches, comment on files, add files to report tables, create a report, etc. Report table associations can even be exported and imported back into the original case, via case tree context menu commands. This allows to split up the workload in large cases across multiple investigators who work simultaneously and to reconcile their results.
Evidence file containers of the current format can be understood by certain computer forensic tools other than from X-Ways. Older versions of WinHex (with a specialist license or higher), X-Ways Forensics and X-Ways Investigator can also understand them. They can all read the contents of all files and show the most essential metadata (e.g. filename, path, many attributes, most timestamps, existing or deleted). To see the maximum amount of metadata, however, please use WinHex/XWF/XWI 16.3 and later. More information. Subject to change: If an evidence file container contains no more than 1,000 objects, it can opened in WinHex with any license type and even in the evaluation version (free of charge, not only for evaluation purposes), and it can be interpreted and mounted as a drive letter.
Containers can theoretically hold around 1 billion files. X-Ways Forensics automatically prevents that the same file is copied to the container twice. If you wish to check the contents of an evidence file container while you are filling it, that is no problem. You can tentatively add it to the same case as an evidence object while it is open for filling. You do not need to remove it from the case or close the evidence object in order to fill the container further. After every filling step, you can take a new volume snapshot of the container to see the complete up-to-date contents. And when done filling the container, you can remove it from that case as it is probably no longer needed in there.
In order to identify/preserve the source of files that originate from different evidence objects, the names of these evidence obejcts can be included in the container as the top directory level. If the option to insert an artificial top directory level is only half selected, that means that only the the names of partition evidence objects are included that have a physical evidence object as a parent. Useful if the parent evidence object name is very long and redundant to include because you will fill your entire container only with files from that physical evidence object and will reference that object's name in the container name already.
Artificial directories can be optionally created in containers to accommodate child objects of files, for compatibility with tools that do not accept files as child objects of other files (non X-Ways tools and WinHex/XWF/XWI 15.9 and earlier). WinHex/XWF/XWI 16.0 and later (latest release, respectively) do not need such artificial directories.
When creating a container, you chose between a direct method and an indirect method to fill it. Indirect means via your own hard disk, i.e the contents of files are not copied directly into the container, but to your folder for temporary files first (cf. General Options), and only then from there into the container. This can be beneficial because it allows a resident antivirus software to intercept these files (check them for viruses, disinfect/disarm them, rename them, move/delete/lock them, etc.), so that it prevents viruses from making it into a container. The resulting container is free of known viruses (depending on the antivirus software in use) and can reasonably be passed on to and used in an environment with higher sensitivity, higher security requirements, and/or less sophisticated virus protection. Please check whether your antivirus software works in this situation before you rely on it.
An optional internal designation can be specified (up to 31 characters), which will become the volume label of the XWFS file system. An optional description can also be specified (up to 60,000 characters), which will be imported as the evidence object comments once the container is added to a case in X-Ways Forensics. The description stored in the container can still be added or edited later.
Files selected in the directory browser can be added to the container that is open in the background with the directory browser's context menu. Either you copy the logical contents of a file, the logical contents and the file slack separately, just the slack, only the block selected in File mode, or merely the file system level metadata of the file. You may also specify whether child objects of selected files should be copied to the container as well, even if they are not selected themselves, either child objects of any kind of child objects (if fully checked) or only e-mail attachments (if half checked).
Optionally containers can include the data/contents of directories themselves, i.e. depending on the file system, directory entries, INDX buffers, etc. Useful if the recipient of the container is technically versed and might be interested in timestamps or other metadata in these data structures. If you choose to include directory data in a container when creating it, this has a direct effect only on directories that are selected themselves. It has an effect on the respective parent directory of selected items only if you enable an additional option ("Include data structures/contents of direct parent items"). This additional decision is needed because otherwise the directory data might unintentionally reveal the names and other metadata of files that were intentionally omitted from the container, e.g. for reasons of confidentiality.
If in the container you have X-Ways Forensics recreate the original path of files that are child objects of other files, then those parent files will be included in the container at least as nominally, without data, so that the child object appears with the correct path and it is clear where it comes from, just by looking at the container. Examples for such parent files are the e-mail message that a selected attachment belongs to, the zip archive that contains a selected file, and the document that a selected picture is embedded in. With the option Include data structures/contents of direct parent items, the data of such files is also included in the container, even if these files were not selected for copying themselves.
Any file that is part of a volume snapshot (e.g. even individual e-mail messages if extracted) can be added to a container. Once added, a file cannot be physically removed any more, however, its exclusion can be made permanent in the container. You have the option to automatically create report table associations for files that have been added to an evidence file container.
Optionally, hash values can be stored for the files that are copied into a container. This allows to verify the integrity of the files later, after having added the container to a case, by refining the volume snapshot. The hash values are computed directly for the data as read from the original source medium (unless you copy metadata to the container only) or taken from the volume snapshot, if available.
Optionally, the preparer of an evidence file container can pass on report table associations (either all or not those created by X-Ways Forensics internally) or comments about included files with the container. Useful to not only forward a collection of files to other investigators, but also case-specific information and preliminary findings. For example, the comment could explain the reason why a file was selected for inclusion in the container in the first place. Please note that transferring extracted metadata to the container is not recommended if the recipient would like to work with an event list because events are not transferred to the container and events derived from within file contents will not be added to the event list if a file is marked as already metadata-processed.
Abort operation upon read error: This option allows to abort copying files into an evidence file container upon a read error and to not include affected files partially. Useful when acquiring files from a network location and the connection might be interrupted, if you assume that if that happens you will get the connection back and will be more successful when you try again, to avoid having incomplete files in the container, which cannot be replaced with a complete copy retroactively. Available only when not filling containers indirectly.
When closing a container that is open in the background, the user is offered to compress, encrypt, and/or split it. This is useful if the container is complete and relatively huge, and e.g. should be sent to someone else on CDs or DVDs. You may also find it useful to have a verifiable overall hash value for all the data in the container, which can be computed at that occasion and embedded in the target container. You can also freeze the file system in the target container that you create in .e01 evidence file format, so that it cannot be filled further even if it is converted back later to its plain state again (to a raw image).