Verify EWF Evidence Images Safely with ewfverify

ewfverify checks that an Expert Witness Compression Format (EWF) image's media data still matches its stored checksum. It can also calculate an optional SHA-1 or SHA-256 digest on top. The workflow uses the installed ewfverify 20140814 binary from ewf-tools version 20140814-1build3.

Allow about ten minutes, excluding the time needed to read the image. You need a Linux shell, an EWF image such as evidence.E01, and enough free time for the complete read. Verification is read-only by default. One option, -w, deliberately writes zeroes to sectors with checksum errors, so this guide treats it as a hazard rather than a normal troubleshooting step.

1. Check the installed command

Confirm the binary and its package version before relying on its output. These are ordinary, read-only commands and do not need elevated privileges:

$ command -v ewfverify
/usr/bin/ewfverify
$ dpkg-query -W -f='${Package} ${Version}\n' ewf-tools
ewf-tools 20140814-1build3
$ ewfverify -V
ewfverify 20140814

The version matters when you are comparing a result with another workstation. This guide describes the options shown by that installed build, not an assumed version from a newer distribution.

Checkpoint: if command -v finds nothing, stop and install the package through your normal system administration process. Do not copy an unrelated binary into place.

2. Identify the first EWF segment

ewfverify accepts the first file in an EWF segment set or the entire set. Replace the placeholder with the actual path supplied by your evidence-handling process:

$ IMAGE='/path/to/evidence.E01'
$ test -r "$IMAGE" && printf 'readable: %s\n' "$IMAGE"
readable: /path/to/evidence.E01

Use the exact first segment name. If the image is split, keep all segment files together and do not rename or reorder them. The first file is enough for ewfverify to discover the set when the files follow the format's normal naming.

The test command only checks that your shell can read the path. It does not prove that the file is a valid EWF image. If it fails with a permissions error, ask the evidence owner to provide access or use an approved account. Adding sudo changes who reads the evidence and may affect your audit trail.

3. Run the default raw-media verification

For a normal EWF acquisition, run ewfverify with the image path. This reads the stored data and compares it with the checksums recorded in the image:

$ ewfverify "$IMAGE"
ewfverify 20140814

Verify started at: [time varies]
This could take a while.

Status: at [progress varies].
        verified [amount varies] of total [amount varies].

Verify completed at: [time varies]

MD5 hash stored in file:    [digest varies]
MD5 hash calculated over data:    [digest varies]

ewfverify: SUCCESS

The exact progress, timing and throughput depend on the image and storage. The useful completion signal is ewfverify: SUCCESS. Keep the terminal output with your case notes, including the command, image path and installed version.

Checkpoint: a successful run verifies the image data against its stored checksum. It does not prove that the original acquisition was accurate, that the source media was unaltered before acquisition, or that your copy of the image came from the correct case.

4. Add a second digest when you need one

The EWF metadata normally contains an MD5 value. Add -d sha256 when your procedure requires a SHA-256 digest as well:

$ ewfverify -d sha256 "$IMAGE"
MD5 hash stored in file:    [digest varies]
MD5 hash calculated over data:    [digest varies]
SHA-256 hash calculated over data:    [digest varies]
ewfverify: SUCCESS

The option calculates an additional digest; it does not replace the stored MD5 comparison. The other accepted value is sha1:

$ ewfverify -d sha1 "$IMAGE"
ewfverify: SUCCESS

Use the digest required by your evidence policy and record which option you selected. Do not call an additional digest a new chain-of-custody record unless your procedure defines how that record is created and retained.

5. Verify logical file data when the image format requires it

Use -f files for logical file data stored in an EWF file. The manpage describes this format as restricted to logical volume files:

$ ewfverify -f files "$IMAGE"
ewfverify 20140814

Single file: [name varies]
MD5 hash stored in file:    [digest varies]
MD5 hash calculated over data:    [digest varies]

Verify completed at: [time varies]
ewfverify: SUCCESS

Do not add -f files merely because a normal raw-media verification failed. First establish whether the image was acquired as raw storage media or as logical files, then use the matching format. Passing the wrong format can produce an error or an answer that does not test what you intended.

6. Save diagnostics without changing the evidence

Use -l when your process requires verification errors and digest output in a separate log:

$ LOG='/tmp/ewfverify-case-001.log'
$ ewfverify -d sha256 -l "$LOG" "$IMAGE"
$ test -s "$LOG" && printf 'log written: %s\n' "$LOG"
log written: /tmp/ewfverify-case-001.log

The log is a new file on the host, not a modification to the EWF image. Treat it as case material: set an approved location and permissions before using it for real evidence. The example uses /tmp only for a disposable test. If you created that test log and no longer need it, remove only that exact file:

$ rm -- /tmp/ewfverify-case-001.log

Do not use rm on the image or its segment files. The verification command itself does not provide an undo for an image changed by another operation.

7. Diagnose a failed open or verification

A missing or unreadable path fails before verification. This safe test demonstrates the shape of the failure without touching an image:

$ ewfverify /tmp/definitely-no-ewf.E01
Unable to open EWF image file(s).
libewf_handle_open: invalid filenames.
verification_handle_open_input: unable to open files.

A non-zero exit status is expected for that command. Check the path, segment set, permissions and file transfer before trying different verification options. If the command reaches the verification stage and reports a checksum error, preserve the original image, capture stderr and follow your incident or evidence procedure.

-q requests minimal status information. It is useful for a quiet automated check, but it makes an interactive investigation less visible. -v sends errors and available diagnostic output to stderr. The package notes that verbose and debug output may be unavailable when the program was built without it:

$ ewfverify -q "$IMAGE"
$ status=$?
$ printf 'ewfverify exit status: %s\n' "$status"
ewfverify exit status: [0 for success, non-zero for failure]

For a script, test the exit status rather than parsing a progress line. Keep the image path quoted, and do not pass untrusted option text through a shell expansion.

8. Do not use the checksum-repair option casually

-w means zero sectors on checksum error, mimicking EnCase-like behaviour. That is a destructive, irreversible change to the data being verified. It can destroy evidence and undermine later examination.

Do not include -w in a routine verification command. If an approved forensic procedure specifically requires it, work on a verified copy, obtain the required authorisation, record the exact command and preserve the untouched original. There is no ewfverify undo command that reconstructs sectors zeroed by this option.

The -x option selects chunk data instead of buffered read and write functions. It changes the I/O path, not the evidence's meaning. Use it only when a documented compatibility or troubleshooting procedure calls for it.

Done means