Evidence Identification, Acquisition and Preservation
Evidence Identification
Find it before you collect it
Evidence identification is the mapping phase: deciding what exists, where it lives, and whether it is probative. Sources include allocated files, deleted files, file slack and unallocated space, registry hives, event and application logs, memory, network captures, mobile app databases, cloud accounts, and physical media. The same event is often reflected in several places - a file copy may leave an entry in the file system, a link file, a jump list, a prefetch file, and a backup snapshot.
Triage is the discipline of prioritising sources under time pressure without destroying them. Scope questions ask whether the identified evidence addresses the allegation; relevance and probative value are not the same as volume.
Distinguish source from artifact. The registry is a source; a USBSTOR key is an artifact. Know that file extensions are unreliable - identify types by signature (magic bytes), structure, and context. Record every search term, tool, and index you use, because your identification method is itself subject to challenge.
Traps
Concluding from a single source. Assuming "deleted" means "gone" (shadow copies, backups, cloud sync, and recycle bins often retain it). Overlooking alternate locations: Volume Shadow Copies, temp folders, thumbnail caches, mail archives, and sync clients. Failing to document search scope invites the question "what did you not look for?".
Worked example: a file named invoice.pdf begins with the bytes 50 4B 03 04 - a ZIP container, consistent with an Office document, not a PDF. Query the signature, not the extension, and note the mismatch in your report as potentially significant.
Rule of thumb: for any key finding, look for a second independent source that corroborates it before you commit to it.
Acquisition and Preservation
Capture without changing
Acquisition produces a defensible copy; preservation keeps the original and the copy trustworthy. Know the acquisition types: physical (bit-for-bit, including unallocated space), logical or file-system (allocated files), sparse (allocated plus selected free space), and targeted (specific artifacts). Know the formats: raw/dd, EWF/E01 (with compression and embedded metadata), and AFF4.
Write blockers prevent writes to the source - hardware blockers are generally preferred; software blockers depend on the host and can fail if misconfigured. Hashing (SHA-256 preferred; MD5 acceptable but collision-prone) is applied to the source before and after acquisition and to the resulting image; verify that the image hash matches the source hash, not merely that the image matches itself. Document tool versions, serial numbers, adapters, and the examiner's identity.
Memory acquisition, network capture, and mobile acquisition have their own tooling. Mobile acquisition levels run from manual review, through logical and file-system methods, to physical and chip-off - each with different completeness and risk. Handle media in anti-static packaging, shield wireless devices with Faraday bags, and log every transfer.
Traps
Relying on MD5 alone when collision resistance matters. Believing a bit-stream image always contains deleted data - TRIM on SSDs and logical acquisitions may exclude it. Forgetting that a hardware write blocker protects the source, not your analysis machine. Hashing the image and comparing it to itself proves nothing about fidelity to the source.
Worked example: hash the source disk, image it through a hardware write blocker, hash the source again, and hash the image file. All three values must agree; if the source hash changed, document the discrepancy and investigate before proceeding.