8. Acquisition
Storage acquisition
Once volatile evidence is preserved and the machine is powered down, acquire the storage. Acquisition is the act of copying evidence in a way that can be shown to be complete and faithful. Whatever the method, the rule is the same: acquire once, verify, then work only from the copy.
A physical image of the whole device
Take a bit-for-bit image of the complete physical device: every sector from the first to the last, including partition tables, unpartitioned space, every partition whether or not it mounts, unallocated space within filesystems and slack space at the ends of files. Copying visible files, or imaging only the partition the operating system shows, discards exactly the material (deleted entries, earlier partition layouts, hidden volumes, corrupted metadata) that a difficult examination depends on. Where a device has host-protected or device-configuration-overlay areas, record whether the imaging tool reports and includes them.
A logical acquisition (files and folders as the filesystem presents them) is sometimes all that is possible, for instance on a large network share or a cloud mailbox. Record what was included and what was not, so nobody later assumes a full image exists. It is not a substitute for a physical image of a workstation drive.
Write blocking
Connect the evidence drive through a hardware write blocker, which permits reads and refuses writes regardless of what the workstation's operating system attempts. Hardware blockers are preferred because they cannot be misconfigured by a distracted operator. Where hardware blocking is impossible (an NVMe drive without a suitable bridge, an embedded device), use a software write-blocking configuration whose behaviour you have validated on a test drive and recorded. Test the blocker on a scratch drive before the first real use of the day, and record the test.
Imaging tools
- FTK Imager (Windows) produces raw or E01 images with built-in hashing and verification and a readable acquisition log.
- Guymager (Linux) produces raw, E01 or AFF images, hashes as it goes, verifies on completion and writes a detailed information file.
- dc3dd (command line) is a forensic extension of dd with hashing, progress and logging suitable for scripted or headless acquisition.
- Comparable established tools (ewfacquire, Tableau imagers, the acquisition modules of the commercial suites) are equally acceptable. What matters is that the tool is recognised, its version recorded, its behaviour validated and its output hashed and verified.
Failing media and bad sectors
A drive that reports read errors, clicks, spins down or stalls is failing, and every read may be its last. Imaging comes before any thought of repair, and repair is never done to the original. Do not keep retrying with a standard imager, and do not run diagnostic utilities that read the drive again to "check" it: each pass consumes what life the media has left. Use a fault-tolerant tool designed for the job, run it once with a strategy that captures the good areas first, and let it manage the retries:
- GNU ddrescue reads the good areas first, skips and returns to bad areas in later passes with progressively smaller blocks, and maintains a map file recording which sector ranges were read successfully, which failed and which were not attempted. Keep that map file with the image: it is the only record of which parts of the image are real data and which are zero-filled gaps, and it is required evidence in its own right.
- The error-tolerant modes of the forensic imagers above serve the same purpose for lightly damaged drives and record unreadable ranges in their logs.
Record the unreadable sector ranges in your notes as well as in the tool's output. Any finding that depends on data near an unreadable range must say so.
Never run repair tools against the original
Do not run chkdsk, fsck, scandisk, the automatic repair offered by an operating system on mounting a "dirty" volume, a drive manufacturer's repair utility or any tool whose purpose is to make a filesystem consistent, against evidential media. These tools write to the disk: they rebuild directory structures, discard entries they consider invalid, move data they consider orphaned and update journals and bitmaps. Every one of those actions destroys the evidence of what the filesystem looked like before, and in a case involving corruption, deletion or anti-forensic activity, that "before" state is the evidence. The same applies to mounting a volume read-write "just to look", which on many systems replays the journal and marks the volume clean.
Corrupted metadata is itself evidentially significant. A partially overwritten directory record, a journal entry for a deletion that never completed, a partition table that describes a layout the drive no longer has, or a filesystem that was deliberately damaged to hide files all tell a story about what happened and when. Repairing them erases the story. Reconstruct from a verified copy (section 18) and leave the original as found.
Example. A workstation's data drive images cleanly for the first 80 per cent and then produces a cluster of read errors. The examiner stops the standard imager, records the point of failure, and re-images with ddrescue over three passes, producing a map showing 1,412 sectors unreadable in two ranges. Both the image and the map are hashed and stored. When a later finding turns on a file whose data run crosses one of those ranges, the report says so, and the confidence assigned reflects it.