Imaging with interACT

interACT has an imaging command with several options/switches to allow users to read a disk or volume and write its contents out as a .dd file. As seen on the previous page, this can also be done from the AIR UI but remains here in interACT for those who prefer to image from the command line.

interACT Imaging Options

   --list, -l                           list available disk/volume devices (default: false)
   --input value, -i value              read disk device from given input
   --output value, -o value             write output file(s) to a repository or directory. Use 'repository' to upload to evidence repository set at session start
   --max-chunk-size value, -c value     maximum chunk size in bytes or use suffix K,M,G. Use 0 to use dynamically calculated chunk size (default: "512M")
   --chunk-retry-count value, -r value  number of retries for chunk creation attempts when output is repository. If output is a directory, this flag is ignored (default: 1024)
   --start-offset value, -s value       start offset in bytes or use suffix K,M,G (default: "0")
   --max-chunk-count value, -n value    maximum number of chunks to create. 0 value dynamically calculates the number of chunks (default: 0)
   --block-size value, -b value         input block size in bytes or use suffix K,M,G. This must be multiple of logical sector size. Bigger values will result in faster reads but will skip the same amount of data on each read if read error occurs. 1M is a good value for most cases. (default: "1M")
   --file-prefix value, -p value        prefix for output file name(s)
   --no-proxy                           bypass proxy if enabled while transferring file to a repository (default: false)
   --bandwidth-limit value              maximum bandwidth limit in bytes or use suffix K,M,G (default: "0")
   --help, -h                           show help

Here is an example of an imaging command in its simplest form:

 image -i E: -o OutputFolder2

In this command, the -i flag is used to specify the input source for the image command.

Here's a breakdown of the command:

• image: This is the name of a command or script that is used to create an image (a copy) of a disk or volume.

• -i E:: This flag specifies the input source for the image creation process. In this case, E: represents a disk or volume identifier on the system. It indicates that the image creation process should target the contents of the disk or volume associated with the drive letter E:.

• -o OutputFolder2: This flag specifies the output destination for the image file. The image file generated by the command will be stored in the OutputFolder2 directory.

Imaging output and the metadata.yml file

To inspect the results of the command shown above, image -i E: -o OutputFolder2, we can navigate to the folder using interACT and list the contents as shown below:

Imaging output and associated metadata file

In this case, we see that there are two image chunks; image.001.zip and image.002.zip, along with a file named metadata.yml. This file exists in your output folder even when you use the AIR UI to image a disk or volume.

This metadata file can be read in the shell with the 'cat' command. It provides information about your image including the source, imaging start and end times, size, and hash values:

Contents of metadata.yml read with 'cat' command

Understanding errors documented in the metadata.yml file

From time to time all imaging tools will have issues with areas of the the disk that can not be read. In such cases, AIR will report errors in the metadata.yml file and they will be recorded as shown below:

metadata:
    Hostname: Win10-002
    Source: '\\.\E:'
    Target: C:\Users\OutputFolder2
    StartTime: 2024-03-19T19:58:21.2390559-07:00
    BlockSize: 1048576
    StartOffset: 0
    Duration: 7.734205s
    ChunkSizeInBytes: 536870912
    BytesRead: 1073737728
    ReadDuration: 466.9625ms
    SeekDuration: 0s
    BytesWritten: 1073737728
    NumberOfChunks: 2
    WriteDuration: 7.249291s
    Compression: true
    Encryption: false
    Hash:
        MD5: fca9b2842db5decdf894327adf4a1ed9
        SHA1: ad6a937e97fa73e64d6d0fdabb0a357ca01c9df4
        SHA256: eeb5961f8f83ae3d70495831da307d429c6ffe881364c5396da76408a8ad8224
ReadErrorTable:
    Errors:
        0: error-1
        1: error-2
    Regions:
        - Offset: 0
          Size: 1048576
          RefError: 0
        - Offset: 2097152
          Size: 1048576
          RefError: 1

This imaging metadata report outlines the process and outcome of an imaging operation carried out in AIR. The report provides details about the operation, including the source, target, data transfer metrics, and errors encountered. Let's break down the key parts and interpret the errors mentioned in the report:

Basic Operation Details

• Hostname: Win10-002 indicates the machine name where the operation was performed.

• Source: '\.\E:' shows that imaging was done from a device mounted at E: (likely a disk drive).

• Target: C:\Users\OutputFolder2 is where the imaged data was written.

• StartTime: The operation started on March 19, 2024, at 19:58:21 local time.

• Duration: It took approximately 7.73 seconds to complete.

• Compression: Enabled, indicating the data was compressed during the imaging process.

• Encryption: Not used during this imaging operation.

Data Transfer Metrics

• BytesRead and BytesWritten: Both are 1,073,737,728 bytes, indicating that a bit over 1 GB of data was read from the source and written to the target.

• NumberOfChunks: 2 chunks of data were processed, aligning with the bytes read/written and chunk size.

• ChunkSizeInBytes: Each chunk was 536,870,912 bytes, about 512 MB, which fits the total data size indicating two chunks were necessary.

• ReadDuration and WriteDuration: Reading took under half a second, whereas writing took the majority of the operation time (about 7.25 seconds).

Errors and Their Implications

The ReadErrorTable section is particularly noteworthy as it outlines issues encountered during the read operation:

• Errors Listed: Two errors, error-1 and error-2, were encountered during the imaging process.

• Regions Affected:

  • The first error occurred at the very beginning of the read operation (Offset: 0), affecting 1,048,576 bytes (1 MB).

  • The second error occurred after skipping the next 1 MB chunk (notably absent from the errors), affecting the third 1 MB segment of data (Offset: 2,097,152).

Interpreting the Errors

• The presence of read errors in specific regions suggests issues with the source device at those locations. This could be due to bad sectors, physical damage, or corruption within the disk's storage.

• The operation continued despite these errors, which is common in forensic imaging processes where the goal is to recover as much data as possible, even in the presence of damaged or inaccessible areas.

• The absence of errors for the second 1 MB segment (from 1,048,576 to 2,097,152 bytes) indicates that not all regions of the source had issues, highlighting the localized nature of the problems.