Integrity and Hashing
What Is a Forensic Hash Manifest?
A straightforward guide to forensic hash manifests, the fields they should contain, how they differ from a single hash value, and why paths and metadata matter.
The simple definition
A hash manifest is a saved list of files and their calculated hash values.
Instead of recording only a long SHA-256 string, a manifest preserves enough context to know which value belongs to which file.
Think of it as an inventory
| Relative path | Size | Algorithm | Hash |
|---|---|---|---|
reports/final-report.pdf | 842,191 | SHA-256 | 93f1... |
images/device.E01 | 54,882,991,104 | SHA-256 | 7a20... |
The table is a human-readable view. The underlying manifest might use JSON, CSV, SQLite, or another structured format.
Recommended fields
At minimum:
- Manifest identifier
- Creation time
- Algorithm
- File path
- File size
- Hash value
- Calculation status
Useful additional context:
- Case number
- Tool and version
- Source root
- Relative path
- Examiner
- Modification time
- Error details
- Manifest format version
Relative and absolute paths
An absolute path records the full original location. A relative path records the location beneath the selected root.
Relative paths are often more portable when a case is moved to another drive or restored from an archive. Absolute paths may still help document the original environment. A strong design can preserve both.
Why one checksum file may not be enough
A simple checksum list works well for many release packages. For a forensic case, examiners may also need case context, errors, file sizes, tool version, source root, and re-verification history.
Human-readable and machine-readable outputs
A useful workflow may create both:
Structured record
- Reopened by the application
- Supports automated comparison
- Preserves metadata
Readable report
- Easy to review
- Suitable for case attachments
- Summarizes results and exceptions
Common mistakes
- Saving values without paths
- Omitting failed or inaccessible files
- Using only filenames when duplicate names exist
- Recreating the manifest instead of preserving the original
- Failing to record the source root
- Treating a manifest as proof of authenticity
Where ByteCase Verify fits
ByteCase Verify is intended to create a persistent structured manifest and a readable report, then use the original saved record during later verification.