Begin with the authority and the question
Before collecting a device, cloud export, removable medium or log stream, define the authorized scope, the question being examined, and the relevant retention window. An examination that preserves every available byte can still miss the question if an expected cloud account, volatile log or external storage component was never in scope. Record what was inaccessible and whether the collection itself changed the source state.
The first observable in an acquisition record should be what was collected and how. It is not yet an interpretation of what a person did. Preserve acquisition time, relevant device and application versions, operating conditions, file or image sizes, source identifiers, clock context, and failures. If an image is partial or a service export omits earlier revisions, record this as a limitation rather than silently describing it as complete.
Separate three evidence claims
- Byte equality: a matching digest indicates that two sets of bytes produced the same digest under a specified algorithm. For practical SHA-256 file integrity checks, this is strong evidence of equality, but only for the bytes actually hashed.
- Handling history: a chain-of-custody record describes who handled an object, when, under what authority and with what transfer or storage controls. Hashes do not create missing custody entries.
- Historical truth and attribution: neither a matching digest nor a custody log proves who originally created a file, whether its embedded timestamp is accurate, or whether a depicted event occurred.
For example, a screenshot can be hashed immediately on receipt and transferred with immaculate documentation. The procedure may preserve the screenshot faithfully without proving the screenshot accurately depicts an authentic event. A forensic report must not promote preservation into authentication.
An acquisition verification sequence
- Identify the source and its collection scope; preserve relevant authority and case identifier without disclosing protected information publicly.
- Record collection tool name, build, settings, operator, date, time reference and collection side effects.
- Calculate an appropriate cryptographic digest at acquisition and again after transfer where feasible.
- Separate source material from working derivatives and keep transformation records with derived objects.
- Test a parser or export method against known input before relying on a feature that may be version-sensitive.
- Correlate key observations with distinct artifacts, recognizing that multiple outputs may share one upstream source.
- Report exclusions, inaccessible sources, failures, overwritten records and uncertainty alongside the supported findings.
The local SHA-256 demonstration lets a visitor reproduce a small byte-integrity check without uploading a file. It is an educational demonstration, not an acquisition tool.
Competing hypotheses and failure points
If source and working-copy hashes differ, an unrecorded transformation is one possibility. So are an incomplete read, comparison of different objects, transfer corruption, or legitimate format conversion. Preserve the mismatch and determine which bytes or stages differ before attributing intent. If hashes match, an upstream false narrative remains possible. If a custody signature is absent, that is a documentation deficiency, not automatic evidence tampering.
A final report should be able to distinguish observed acquisition state, verified handling, interpretation, and unresolved alternatives in separate sentences.
Editorial and validation status
This article is a method guide, not a legal opinion, forensic certification standard or report of a completed case validation. Consult current tool documentation and applicable organizational procedures. For further reading, see the defensive Anti-Forensics field guides and NIST's Computer Forensics Tool Testing program.
Source and revision record
Original editorial analysis and definitions. For background reference, consult the source catalog.