Chapter 5: The Forensic Process — Acquisition, Preservation, Analysis, and Reporting

Where you are: Part I, Chapter 5 of 40. Chapters 2–4 taught you how data physically lives on media — bits, bytes, sectors, and clusters (Chapter 2); the drives and flash that hold them (Chapter 3); and the file systems that organize them (Chapter 4). This chapter is the hinge of the entire book: the disciplined method — acquisition, preservation, analysis, reporting — that turns "I looked at a drive" into "I can prove what was on it, and that I changed nothing." It is the methodology this book owns and deepens in Chapter 14, and it introduces the courtroom anchor case that recurs through Parts III and IV.

Learning paths: Everyone reads this chapter — it is the spine. 🔍 Forensic Examiner and 📜 Legal/eDiscovery should internalize every line: chain of custody, legal authorization, and admissibility live here. 🛡️ Incident Response, note the order-of-volatility and triage forward-links to Chapter 15. 💾 Data Recovery, watch the Recovery vs. Forensics callouts: you will borrow imaging and hashing wholesale and skip most of the legal overhead — right up until the day an ordinary recovery turns into a case.

From "poking around" to a repeatable method

Two people sit down at the same broken laptop. The first plugs the drive into their Windows desktop, double-clicks through folders, finds a deleted-looking file in the Recycle Bin, copies it to a thumb drive, and says, "Here's your evidence." The second photographs the laptop, records its make and serial, removes the drive through a write-blocker, makes a bit-for-bit image, computes a cryptographic hash of both the original and the copy to prove they are identical, logs every handoff on a custody form, and only then — working on a copy of the copy — begins to examine what is there.

Both people may "find" the same file. Only the second can stand in a courtroom, or in front of a skeptical insurance adjuster, or across the table from opposing counsel, and answer the one question that decides whether the work was worth anything: How do you know you didn't change it, and how do you know it was there before you arrived? The first person cannot answer. By opening the drive on a live Windows system, they altered it — Windows writes to a disk simply by mounting it — and they have no record of the drive's state before they touched it. Their "evidence" is now indistinguishable from something they could have planted, corrupted, or fabricated. It is, in the language of the law, unreliable, and a good attorney will say so until the judge agrees.

The difference between those two people is not talent, tools, or intelligence. It is method. The forensic process is the method. It is what separates forensics from poking around a hard drive, and — this is the part newcomers underestimate — it is also what separates professional data recovery from amateur tinkering. The recovery engineer who images a failing drive before touching it does so for a different reason than the examiner (the original is the client's only copy and it is dying, not "the original must be admissible"), but the discipline is the same. Across both disciplines, the method is the product.

The scientific method, applied to a hard drive

Strip away the courtroom vocabulary and the forensic process is just the scientific method pointed at a storage device. Science makes claims that can be tested, repeated, and disproven; it documents its procedures so that a stranger can follow them and get the same answer; it distinguishes what was observed from what is concluded. Digital forensics demands exactly these things, and for the same reason: a finding that cannot be reproduced is not a finding, it is an assertion.

Walk the parallel concretely. You observe — a manager reports that a departing employee may have copied proprietary files. You form a question — did files leave the company on removable media before the resignation? You state a hypothesis that can be wrong — "On the night before resigning, the user attached a USB device and copied the customer database to it." You test the hypothesis against artifacts: USB device history in the registry, file-access timestamps, link files, the volume serial numbers recorded when devices were mounted. Crucially, you test for disconfirmation too — you look for evidence that the hypothesis is false (the database was last opened a month earlier; no removable device was attached that night), because an examiner who only seeks confirming evidence is not doing science, they are building a case for a predetermined conclusion. You analyze the results, reach a conclusion that is proportionate to the evidence, and you write it up so that another examiner with the same image and the same tools reaches the same conclusion. That last property — independent reproducibility — is the whole game.

This is not an analogy invented to sound rigorous. It is the legal standard. In United States federal courts, the admissibility of expert and scientific testimony is governed by the Daubert standard (covered in depth in Chapter 25), which asks whether a technique can be and has been tested, whether it has been subjected to peer review, whether it has a known error rate, whether standards govern its use, and whether it is generally accepted in the field. Every element of the forensic process — write-blocking, imaging, hashing, documentation — exists to make your work testable, repeatable, and standardized so that it survives this scrutiny. The method is not bureaucracy bolted on after the fact. It is the reason your findings count.

Why This Matters. Media changes, file systems change, encryption changes — but the method does not (theme: technology changes, principles don't). The drive in front of you in ten years may use a storage technology that does not exist today, yet you will still understand the technology, image the evidence, analyze the copy, document every step, and report accurately. Learn the method now and you will never be obsolete; learn only today's tools and you will be obsolete the moment they update.

Four phases, with many names

This book frames the process in four phases: identification, preservation, analysis, and reporting. You will see other names for the same arc, and you should recognize them, because exam questions, certifications, and opposing experts use them interchangeably. The U.S. National Institute of Standards and Technology, in NIST Special Publication 800-86, names four phases collection → examination → analysis → reporting. The UK's Association of Chief Police Officers (ACPO) Good Practice Guide for Digital Evidence frames the discipline as four principles rather than phases (reproduced below). The Digital Forensic Research Workshop (DFRWS) model is more granular — identification, preservation, collection, examination, analysis, presentation. The labels differ; the substance does not. Find the evidence, protect it from alteration, examine the protected copy, and explain what you found.

   ┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
   │ 1. IDENTIFY  │ ──> │ 2. PRESERVE  │ ──> │ 3. ANALYZE   │ ──> │ 4. REPORT    │
   │ what data    │     │ image, hash, │     │ work on the  │     │ findings,    │
   │ sources      │     │ write-block, │     │ COPY; form & │     │ methods,     │
   │ exist? scope │     │ chain of     │     │ test hypoth- │     │ tools, limits│
   │ & authority  │     │ custody      │     │ eses; build  │     │ — for a non- │
   │              │     │ (acquisition)│     │ the timeline │     │ tech reader  │
   └──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
          │                    │                    │                    │
          └────────────────────┴────────────────────┴────────────────────┘
              DOCUMENT EVERY STEP — the audit trail runs the full length

Notice the band running underneath all four boxes. Documentation is not a fifth phase that happens at the end; it is a continuous activity that spans the entire process. ACPO's third principle states it plainly: an audit trail of all processes applied to digital evidence should be created and preserved, and an independent third party should be able to examine those processes and achieve the same result. The other three ACPO principles are worth committing to memory because they compress this entire chapter into four sentences:

1. No action taken should change data held on a device that may later be relied upon in court.
2. If you must access original data, you must be competent to do so and able to explain the relevance and the implications of your actions.
3. An audit trail should be created and preserved so that an independent party can repeat your process and reach the same result.
4. The person in charge has overall responsibility for ensuring the law and these principles are followed.

Principle 1 is the default. Principle 2 is the rare, documented exception (you will meet it when a phone can only be examined while powered on, in Chapter 15, and when encryption forces a live capture, in Chapter 29). Principle 3 is documentation. Principle 4 is accountability. Everything else in this chapter is detail hung on this frame.

A first look at the case that ends up in court

Throughout the book, four anchor cases recur and deepen. You have already met the first — the deleted wedding photos from Chapter 1, a recovery job that is equal parts technical skill and human service. This chapter introduces the fourth and most consequential: a forensic image analyzed in court.

A laptop arrives at your lab as evidence in a criminal matter. The allegation is possession of child sexual abuse material (CSAM). We will follow this case — clinically — across the book: hash verification here and in Chapter 14; deleted-file recovery in Chapter 6; photo and EXIF metadata analysis in Chapter 20; timeline analysis proving dates of access in Chapter 21; the report in Chapter 26; and a cross-examination drill in Chapter 27. The ethics of this work — what you owe the victim, the accused, the court, and yourself — is owned by Chapter 28.

A word on how this book treats that case, set down once so it never has to be repeated graphically. We address it strictly at the level of procedure, law, and ethics. We never describe content. The examiner's job is not to decide guilt or to dwell on imagery; it is to establish, forensically, what is on the device, when it arrived, and who had access — and to do so in a way that survives cross-examination. The technical skills serve a human need: protecting the vulnerable while protecting the rights of the accused. Both obligations are real, and the method serves both, because the same disciplined chain that convicts the guilty is what exonerates the wrongly accused.

Ethics Note. If, during any examination, you encounter what appears to be CSAM, U.S. federal law (18 U.S.C. §2258A) imposes reporting duties on certain providers, and standing policy at every legitimate lab requires you to stop, preserve, limit your exposure, and escalate to the proper authority — you do not "keep looking to be sure." This is introduced here and treated fully in Chapter 28, alongside the reality of secondary trauma and examiner well-being. The human cost of this work is real, and pretending otherwise is itself a failure of professionalism.

Phase 1 — Identification: find every source of data

Identification answers a deceptively simple question: what is there to examine? Get this wrong and the most flawless imaging in the world is irrelevant, because you imaged the wrong thing — or you missed the device that mattered.

Start by inventorying the obvious: desktops, laptops, servers, and their internal drives. Then widen the lens, because data has scattered. External hard drives and the USB stick in a drawer. SD and microSD cards in cameras, drones, and dashcams. Phones and tablets (their recovery is Chapter 11; their forensics is Chapter 24). Optical media. Network-attached storage and the RAID arrays inside it (Chapter 10). And the sources that have no physical presence at the scene at all: cloud accounts (email, file sync, backups — Chapter 31), and the volatile state of any machine that is currently running.

For each source, record its identity precisely: make, model, serial number, capacity, and condition. "A black laptop" is useless six months later in a deposition. "Dell Latitude 7430, service tag 7XK2QL3, with a 512 GB Western Digital SN740 NVMe SSD, serial 22451B804296, lid scratched, powered off on receipt" is a sentence you can defend. Photograph everything before you touch it: the device, its connections, the screen if it is on, cable arrangement, the room. Photographs are free and unimpeachable; memory is neither.

Don't forget the volatile and the hidden

Two categories of evidence get lost during identification, and both losses are permanent.

The first is volatile data. A running computer holds, in its RAM, things that exist nowhere on disk: running processes, open network connections, decrypted file contents, clipboard data, and — critically — encryption keys. The instant you pull the power, that evidence is gone forever. There is an order of volatility, from most to least ephemeral: CPU registers and cache, then RAM, then network and process state, then the disk, then archival media and printouts. The disk you can image tomorrow; the RAM you cannot. This creates genuine tension with ACPO Principle 1 ("change nothing"), because capturing RAM is a change — and that is precisely the documented exception Principle 2 permits. Live response and the order of volatility are owned by Chapter 15; memory analysis by Chapter 22. For now, learn the rule of thumb: if a machine is on, decide about the volatile data before you decide about the power cord. Pulling the plug on a running, encrypted machine can lock you out of the disk forever (Chapter 29).

The second is hidden capacity. A drive can hold more sectors than the operating system reports. The Host Protected Area (HPA) and the Device Configuration Overlay (DCO) are ATA features that hide a region of the disk from the OS — originally for recovery partitions and capacity-clamping, but equally useful for concealment. A naive copy stops at the reported size and misses everything beyond it. Proper forensic imagers detect and temporarily disable HPA/DCO so that every sector is captured. We cover the mechanics in Chapter 14; flag it here so the word "identification" includes all the sectors, not just the ones the OS admits to.

Try This. On a practice machine (never on evidence), connect a USB drive through a write-blocker and run a tool that reports drive geometry — hdparm -I /dev/sdb on Linux will report whether an HPA is present. Compare the user-addressable sectors to the native max. The gap, if any, is space the operating system never showed you. Lab-image sources and setup are in Appendix J.

Phase 2 — Preservation: the original is sacred

Preservation is the heart of this chapter and the discipline. Its governing principle is one of the book's six recurring themes, stated bluntly: the original is sacred. You never analyze the original. You make a perfect copy, prove it is perfect, and work on the copy. Forensics does this for admissibility — the court must trust that the evidence is unaltered. Recovery does this for irreplaceability — the client's data may exist nowhere else, and a single wrong write can destroy it. Different motives, identical discipline.

Why even looking is dangerous

Newcomers assume that reading a drive is harmless — surely you can't change something just by looking at it? On modern systems, that assumption is wrong, and the wrongness is the entire justification for write-blocking.

Attach an NTFS drive to a running Windows machine and Windows immediately begins to write to it, without asking and without any action from you. It updates the $LogFile` journal. It may create a `System Volume Information` folder and a `$RECYCLE.BIN. It writes a RECYCLER/recycle structure, builds thumbnail caches if you browse images, and — most damaging of all for an investigation — it updates last-access timestamps on files and directories you merely glance at. The drive's MFT, its journal, and its timestamps are all altered before you have consciously done anything. Even mounting a Linux file system read-write replays the journal on mount, changing the disk. This is theme three made concrete: every action leaves a trace. The OS's helpful housekeeping leaves traces all over your evidence, and worse, it overwrites the very timestamps and unallocated space that hold the answers. The defense against this is not carefulness. It is hardware that makes writing physically impossible.

Write-blocking

A write-blocker sits in the data path between the suspect drive and your workstation. It passes read commands through to the drive and silently refuses — or returns success for without executing — every write command. The original cannot be modified because the modifications never reach it.

  ┌───────────────┐      ┌────────────────────┐      ┌─────────────────────┐
  │ SUSPECT DRIVE │      │   HARDWARE          │      │   EXAMINER          │
  │ (the original,│ ===> │   WRITE-BLOCKER     │ ===> │   WORKSTATION       │
  │  "best        │ READ │   reads pass;       │      │   imaging software  │
  │  evidence")   │ ONLY │   ALL writes blocked│      │   writes the IMAGE  │
  │               │      │   (e.g. Tableau,    │      │   to a SEPARATE     │
  │               │ <=X= │    WiebeTech/CRU)   │ <=X= │   destination disk  │
  └───────────────┘      └────────────────────┘      └──────────┬──────────┘
     no write ever reaches the original   writes are refused     │
                                                                 v
                                                      ┌─────────────────────┐
                                                      │   EVIDENCE IMAGE     │
                                                      │   disk1.dd / .E01    │
                                                      │   + sha256 + md5     │
                                                      └─────────────────────┘

Write-blockers come in two forms. Hardware write-blockers — Tableau (now OpenText), WiebeTech/CRU, and others — are dedicated bridges for SATA, SAS, IDE, USB, NVMe, and more. They are the gold standard precisely because the blocking is enforced in hardware, independent of any operating-system setting you might forget. The U.S. NIST Computer Forensics Tool Testing (CFTT) program publishes test results for hardware write-block (HWB) and software write-block (SWB) tools against a documented specification; using a CFTT-tested blocker is part of how you satisfy Daubert's "standards and testing" prong.

Software write-blockers alter the operating system's behavior to prevent writes. On Linux you can set a device read-only at the block layer; on Windows there is a registry-based USB write-protection backstop. These are useful, but they are backstops, not substitutes — a misconfiguration, a forgotten reboot, or a driver that ignores the flag can let a write through. Use hardware when stakes are high.

# Linux: inspect read-only, then enforce it at the block layer (software backstop)
sudo blockdev --getro /dev/sdb      # 0 = writable, 1 = read-only
sudo blockdev --setro /dev/sdb      # force read-only
sudo blockdev --getro /dev/sdb      # confirm: must now print 1

# Never `mount` evidence read-write. If you mount at all, force read-only
# and disable journal replay so the mount itself changes nothing:
sudo mount -o ro,noload,noatime /dev/sdb1 /mnt/evidence    # ext: noload
sudo mount -o ro,norecovery     /dev/sdb1 /mnt/evidence    # NTFS: norecovery

Windows USB write-protect backstop (REQUIRES reboot/reconnect; NOT sufficient alone):

  HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies
      WriteProtect   (REG_DWORD) = 0x00000001

  This affects USB mass-storage only and is bypassable. For evidence, use a
  CFTT-tested HARDWARE write-blocker. The registry key is a seatbelt, not a vault.

Tool Tip. Before you trust any write-blocker — hardware or software — verify it on a scratch drive. Note the drive's hash, attempt a write through the blocker (e.g., try to create a file or run a tool that touches the disk), then re-hash. If the hash is unchanged, the blocker works. Record the make, model, and firmware of the blocker in your notes; "write-blocked with a Tableau T356789 SATA bridge, firmware 1.2.3" is the kind of specificity that ends a cross-examination before it starts.

The forensic image: a bit-for-bit copy

With writes blocked, you make a forensic image: a sector-by-sector, bit-for-bit copy of the entire storage device. Every sector — allocated, unallocated, slack, boot, partition gaps, and the HPA/DCO once disabled — is copied exactly. This is the single most important distinction a newcomer must absorb, so it is worth stating sharply.

A forensic image is not a backup. A backup, or any ordinary file copy, captures files — the data the file system currently admits to having. A forensic image captures the entire device, including the space the file system says is empty. And "empty" space is where the evidence lives. Recall theme one from Chapter 1 and the file-system mechanics of Chapter 4: deleting a file removes the pointer, not the data. The clusters that held a "deleted" file are marked available, but their contents persist until something overwrites them. A file copy skips those clusters entirely because no file points to them. A forensic image grabs every sector regardless of what points to it — which is exactly why the deleted files, the slack-space fragments, and the carved artifacts of Chapter 6 and Chapter 7 are recoverable from an image and invisible to a backup.

Picture the difference at the byte level. Sectors are 512 bytes (or 4096 on Advanced Format / 4Kn drives); from Chapter 2, a sector's byte offset is simply sector_number × sector_size. A logical copy reads only the runs of sectors the MFT or inode table claims. A physical image reads sector 0 through the last sector, in order, no matter what the metadata claims:

  LOGICAL COPY (a backup) — follows file-system pointers only:
    [allocated file A][allocated file B]..............[allocated file C]
     ^copied          ^copied          ^SKIPPED        ^copied
                                       (unallocated — but here lie the
                                        deleted files, slack, and carve-able
                                        fragments an investigation needs)

  PHYSICAL IMAGE (forensic) — every sector, in order, ignores pointers:
    sector 0 ─────────────────────────────────────────────► last sector
    [MBR/GPT][partition 1 ............................][gap][partition 2 ...]
     every byte captured, including all the "empty" space above

Image formats: raw, E01, and AFF4

You will encounter three families of image format. Know what each one is and when to reach for it.

Raw / dd images (.dd, .raw, .img, sometimes split into .001, .002, …) are exactly the bytes of the device, with no wrapper and no embedded metadata. They are universal — every forensic tool reads raw — and simple, but large (no compression) and "dumb" (the hash and case details live in a separate log you must not lose).

EnCase Expert Witness Format (E01) is the de facto forensic standard. An E01 is a container: it compresses the bitstream (zlib), embeds case metadata (case number, evidence number, examiner, notes, acquisition date), stores the acquisition hash inside the file, and protects integrity with a CRC on each block of data (by default a CRC every 64 sectors / 32 KiB), so localized corruption is detected and isolated rather than silently poisoning the whole image. Large acquisitions segment into .E01, .E02, .E03, and so on. The newer Ex01 format (EnCase Evidence File Format v2) adds stronger compression and optional encryption. The practical payoff: an E01 carries its own provenance and self-checks its own integrity.

AFF4 is a modern, open format supporting features raw and E01 lack — such as storing logical evidence and sparse images efficiently — and is gaining adoption in research and large-scale acquisition. For most casework today, E01 is the safe default; raw is the universal fallback; AFF4 is the forward-looking option.

A subtlety that trips up beginners and matters for the progressive project below: the hash stored inside an E01 is the hash of the acquired bitstream (the device's bytes), not the hash of the .E01 file on disk. The .E01 file is compressed and wrapped, so sha256sum image.E01 gives the hash of the container — useful for proving the file you received equals the file someone sent (transfer integrity), but not the same number as the bitstream hash your tool re-verifies when it loads the image. Two different hashes, two different jobs. We return to this distinction when you receive your case image.

Recovery vs. Forensics. Imaging is the clearest example of one artifact serving both disciplines. The technique is identical — write-block, copy every sector, verify. The trigger differs. In forensics you image always, because the chain of custody and admissibility demand it. In recovery you image when the media is valuable, failing, or irreplaceable — a dying drive may give you only one good read of each sector (every read stresses failing heads or fading NAND), so you image first to a healthy target and then do all your experimentation on the copy, never risking the patient again. The wedding-photos client (Chapter 1, worked in Chapters 6–7) gets imaged not for a courtroom but because those ten years of photos exist nowhere else and the drive is the only copy. Same act; different "why."

Hashing: proving the copy equals the original

You have a bit-for-bit copy. How do you prove it is bit-for-bit identical — not approximately, but exactly? You use a cryptographic hash function. Hashing is the mathematical backbone of the entire process: it is how you prove the image equals the source, how you prove the image has not changed since acquisition, how you confirm a working copy matches the master, how you identify known files, and how you let a court accept your evidence without re-examining every byte.

What a hash function actually does

A cryptographic hash function takes input of any size and produces a fixed-length output — a digest or hash value — with several properties that make it ideal for integrity verification. It is deterministic: the same input always yields the same digest. It exhibits the avalanche effect: changing a single bit of input changes roughly half the output bits, unpredictably, so the digest of a tampered copy looks nothing like the original's. It is one-way: you cannot reconstruct the input from the digest. And it is fixed-length regardless of input size — a 500 GB drive and a one-byte file both hash to the same-size digest.

The avalanche effect is the magic for forensics. If even one bit of your 500 GB image differs from the source — a single flipped bit in a single sector — the hashes will not match, and you will know the copy is unfaithful before you waste a moment analyzing it. Watch the avalanche on a one-character change:

SHA-256("abc")
  = ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad

SHA-256("abd")          (changed only the last letter: c -> d)
  = a52d159f 262b2c6d df06f9b8 ... (completely different — ~half the bits flip)

MD5("abc")    = 90015098 3cd24fb0 d6963f7d 28e17f72        (128-bit / 32 hex)
SHA-1("abc")  = a9993e36 4706816a ba3e2571 7850c26c 9cd0d89d (160-bit / 40 hex)
SHA-256("")   = e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855
                (the SHA-256 of an empty input — a useful sanity value to memorize)

Those are real test vectors; you can reproduce them yourself, which is the point — a hash is a claim anyone can independently check.

MD5, SHA-1, SHA-256, and the collision question

Three algorithms dominate forensic practice, and their differences create a question you will be asked under oath, so understand it now.

A collision is two different inputs that produce the same digest. For MD5 and SHA-1, researchers have constructed collisions deliberately. This matters because a cross-examining attorney can ask: "Examiner, isn't it true that MD5 is broken — that two different files can share a hash? So your matching hash doesn't actually prove the image is the original, does it?" The honest, complete answer is twofold. First, a crafted collision requires an attacker to control both inputs in advance; it is not something that happens by accident, and it cannot retroactively make your faithfully-imaged drive collide with a different drive. Second — and this is why you do it — you compute two hashes (MD5 and SHA-256), or you simply use SHA-256, which has no practical collision. No one has produced a single input that simultaneously collides under two different algorithms. Dual-hashing turns a potential cross-examination wedge into a non-issue, and it costs you nothing but a few extra minutes of compute. The modern best practice: acquire with SHA-256 (and MD5 alongside it for tool compatibility), and re-verify before every analysis session.

Here is the verification logic you will run countless times, written as a streaming hash so you never try to load a 500 GB image into memory:

import hashlib

def sha256_of_file(path, chunk=1024 * 1024):
    """Stream a file through SHA-256 in 1 MiB chunks (works on multi-GB images)."""
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for block in iter(lambda: f.read(chunk), b""):
            h.update(block)
    return h.hexdigest()

# The acquisition log recorded this digest when the image was created.
expected = "a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4b7e0c3f6a9d2b5e8"
actual   = sha256_of_file("/cases/2024-0417/evidence/disk1.dd")

if actual == expected:
    print("[OK]   integrity verified — working copy equals the source image")
else:
    print("[FAIL] HASH MISMATCH — do NOT analyze; this copy is not faithful")
    print(f"       expected: {expected}")
    print(f"       actual:   {actual}")

On Windows you do not need a script at all; PowerShell ships with a hashing cmdlet:

Get-FileHash -Algorithm SHA256 -Path 'D:\cases\2024-0417\evidence\disk1.dd' |
    Select-Object Algorithm, Hash

Limitation. A matching hash proves integrity, not authenticity or origin. It proves the bytes did not change between two points in time — it does not prove who created the data, when content was first written, or that the device belonged to a particular person. Those are separate questions answered by metadata, timelines, registry artifacts, and corroboration, not by the hash. Confusing "the hash matches" with "the suspect did it" is a category error that good opposing counsel will expose, and that an honest examiner never makes (theme: know your limitations).

Chain of custody: the documented life of evidence

The hash proves the evidence did not change. The chain of custody proves the handling was sound. It is the chronological, documented history of a piece of evidence — who collected it, when, and where; who has had it since; what each person did with it; and every transfer from one hand to the next. It answers the question that decides admissibility: can you account for this evidence from the moment of seizure to the moment it is shown in court, with no unexplained gaps?

A break in the chain — an interval where you cannot say who had the drive or what they did — does not automatically exclude evidence, but it gives opposing counsel an opening to argue the evidence was altered, swapped, or contaminated, and it shifts the fight from what the evidence shows to whether the evidence can be trusted at all. That is a fight you avoid by documentation, not by argument.

What goes on the form

A chain-of-custody form (templates in Appendix F) records two things: the identity of the evidence and its movement. Identity: a case number; a unique exhibit/item number; a full description (make, model, serial, capacity, condition); where and when it was collected; who collected it; and the acquisition hashes. Movement: a transfer log where each handoff records the date and time, who released it, who received it, the purpose, and two signatures — released-by and received-by. Every transfer is a two-signature event. Evidence does not move silently.

 SEIZURE ─> INTAKE/LABEL ─> IMAGING ─> EVIDENCE LOCKER ─> ANALYSIS ─> COURT ─> DISPOSITION
    │            │             │             │            (on copy)     │           │
 who / when   exhibit #,   source AND     sealed in    working copy  testimony   return or
 / where      make /       image hash     tamper-       re-verified  & exhibits  destroy
 photos       serial /     = MATCH        evident bag,  before each              per court
              capacity                    access log    use                      order
    └────────────┴─────────────┴─────────────┴────────────┴────────────┴───────────┘
       EVERY transfer = date-time + released-by sig + received-by sig + purpose

Two details in that diagram carry disproportionate weight. First, the original goes into the locker and stays there. After imaging, the best-evidence original is sealed in a tamper-evident bag, logged, and stored; all subsequent work happens on the image. The original is touched again only if a court orders it or a defense expert requests independent examination — and that, too, is a logged transfer. Second, analysis happens on a copy, re-verified before each use. You keep a read-only master image and work on a copy of it; before each session you re-hash the working copy against the master so that you can attest the data you analyzed today is bit-identical to what was acquired months ago.

Chain of Custody. Treat the chain as a story with no missing pages. From seizure to courtroom, you must be able to narrate the whole life of the evidence and produce a signature for every transition. The most common failure is not dramatic tampering; it is mundane sloppiness — a drive left on a desk overnight, a colleague who "just took a quick look," an undocumented hour. Those gaps cost cases. Document contemporaneously: write it down as it happens, not from memory at the end of the day.

Sealing, labeling, and the evidence locker

Physical handling matters as much as paperwork. Evidence is sealed in tamper-evident bags or containers — packaging that visibly shows if it has been opened — and the seal is signed and dated across the closure. Each item carries a label tying it to its exhibit number and case. Mobile devices that could connect to a network are isolated in a Faraday bag to prevent remote wiping or new data arriving (covered in Chapter 11 / Chapter 24). Stored evidence lives in a controlled, access-logged location — an evidence locker, safe, or room with restricted entry — so that "who could have touched this?" has a short, documented answer. The principle scales down to the smallest job: even a one-drive recovery benefits from a labeled shelf and an intake note. Habits formed on small cases hold up on the big ones.

Legal authorization: the method can't manufacture authority

Here is a hard truth that technical people resist: the cleanest image, the perfect hashes, the flawless chain of custody — all of it is worthless, and may be illegal, if you lacked the authority to examine the device in the first place. The method preserves and proves; it cannot grant permission. Before you image anything, you must answer: what is my lawful basis for examining this?

Warrant, consent, and corporate authority

Three bases cover most situations; the law is owned by Chapter 25 and summarized in Appendix E, so here we cover only the operational essentials.

A search warrant authorizes law enforcement to search and seize, subject to the Fourth Amendment's requirement of particularity — the warrant describes what may be searched and what may be seized. The warrant defines your scope. You may examine for the things the warrant names; ranging beyond them risks suppression.

Consent is permission given voluntarily by someone with authority over the device or data. Consent can be limited ("you may look at the email folder, nothing else") and withdrawn at any moment, so you document its scope and you stop when it ends. The person must actually have authority — a roommate generally cannot consent to a search of your locked, password-protected laptop.

Corporate authority lets an employer examine company-owned devices, grounded in an acceptable-use policy and, ideally, a login banner that puts users on notice that the device may be monitored and is not private. Bring-your-own-device (BYOD) arrangements complicate this badly, because the employee's personal data mingles with the company's on hardware the employee owns; the answer lies in policy written before the incident, not improvised after. Civil matters add subpoenas and court orders (the engine of eDiscovery under the Federal Rules of Civil Procedure), and emergencies add narrow exigent-circumstances exceptions.

Legal Note. Hashing and a clean chain do more than satisfy Daubert — they tie directly to the rules of evidence. Federal Rule of Evidence 1001–1003 (the "best evidence" rules) treats an accurate duplicate as admissible as the original, which is exactly what a verified forensic image is. And FRE 902(14), added in 2017, allows electronic data copied from a device to be self-authenticating when accompanied by a qualified person's certification that identifies the data by its hash. In other words, the hash you compute in Phase 2 is the mechanism the rules of evidence use to let your image into the courtroom without you having to authenticate every byte by hand. Method and law are not separate worlds; the method is how you meet the law.

Scope discipline and plain view

Authorization is not a one-time gate; it constrains you throughout. Scope discipline means you search for what you are authorized to find and you do not wander. If a warrant authorizes a search for evidence of financial fraud, you examine spreadsheets, accounting files, and email — you do not open the personal photo library "just to see," because that exceeds your authority and can taint the whole examination under the fruit-of-the-poisonous-tree doctrine.

The hardest version of this problem is the courtroom anchor case in reverse: what do you do when you are looking for one thing and stumble onto evidence of another crime? The plain-view doctrine has a contested, evolving application to digital searches, because a disk is not a room you can glance across — finding "obvious" contraband may require opening files, which is itself a search. The disciplined answer, and the one that protects both the case and the rights of the accused: stop, do not expand your search, document precisely what you saw and how you came to see it, and obtain expanded authorization (a second warrant) before continuing into the new area. Charging ahead can suppress the very evidence you found.

Ethics Note. There is one situation where "stop and escalate" is not merely good practice but a legal and moral imperative: if you encounter apparent CSAM during any examination — including a routine corporate or recovery job where you never expected it — you stop, you preserve, you minimize your own exposure to the material, and you escalate to law enforcement. You do not "keep looking to confirm," you do not copy it for your files, and you do not handle it casually. Reporting duties (18 U.S.C. §2258A for covered providers) and the realities of mandatory reporting, scope, and examiner well-being are the subject of Chapter 28. This is where the abstract phrase "the human cost is real" stops being abstract.

Phase 3 — Analysis: work the copy, seek the truth

With the evidence preserved, proven, documented, and lawfully obtained, analysis can begin — on a copy of the verified image, never the master, and never, ever the original. You re-verify the working copy's hash against the master at the start of each session, so that the chain of integrity is unbroken from acquisition to finding.

Analysis is where the rest of this book lives: recovering deleted files from MFT and inode remnants (Chapter 6), carving by signature where the metadata is gone (Chapter 7), reading the Windows registry and prefetch (Chapter 16), reconstructing the MACB timeline (Chapter 21), and the rest of Part III. The forensic process does not change with the technique; only the artifact does. You form a hypothesis, you test it against the evidence on the copy, you document each action and the tool (and tool version) that performed it, and you note what you find and — equally — what you don't.

Two principles elevate analysis from "looking for incriminating things" to "establishing the truth." First, reproducibility: every action is recorded in enough detail that an independent examiner, given the same image and tools, repeats your steps and reaches your result. Contemporaneous notes, exact tool versions, exact commands, exact file paths and byte offsets — these are not pedantry, they are the difference between an opinion and a finding. Second, you seek both inculpatory and exculpatory evidence. Your loyalty is to the facts, not to the side that retained you. The same disciplined examination that proves a USB device was attached at 02:14 also proves, in the next case, that it wasn't — and an examiner who reports only the half that helps the client is not an examiner, they are an advocate, and the court will eventually treat them as one. The method that convicts the guilty is the method that clears the innocent. That symmetry is the moral center of the discipline.

Phase 4 — Reporting: if it isn't written down, it didn't happen

The final phase converts technical work into something a non-technical decision-maker can act on. A forensic report (owned by Chapter 26, with testimony in Chapter 27) translates sectors, hashes, and timestamps into plain findings a judge, jury, attorney, manager, or client can understand — without sacrificing the precision that lets another expert check your work.

A sound report separates facts from opinions, states the methodology and tools (with versions), references each finding to its evidence (file paths, byte offsets, hashes, timestamps), and is candid about limitations and assumptions. That last part is not weakness; it is credibility. An examiner who writes "the evidence is insufficient to determine who was at the keyboard" is more trustworthy than one who overreaches, and far harder to impeach. The operating maxim: if it isn't in the report, it didn't happen. Undocumented work cannot be defended, cannot be reproduced, and cannot be relied upon. The report is the deliverable; everything before it was preparation.

Two workflows, one foundation: recovery vs. forensics

You now have the full arc, and you can see why this book teaches two disciplines as one. Recovery and forensics share a foundation — the original is sacred, image first, hash to verify, work on the copy — but they diverge in how much legal machinery rides on top. The divergence is about consequences, not about care.

Recovery vs. Forensics. The single most useful instinct you can develop is to ask, on every job, "could this become a case?" A routine "my drive won't mount" recovery has no courtroom on the horizon — until the client mentions it's a business partner's drive in a dispute, or you find something that triggers a reporting duty. The moment that possibility appears, you upgrade to the forensic workflow: write-block, image, hash, and start a chain of custody retroactively from now, documenting the transition honestly. You cannot manufacture a chain you didn't keep, but you can start one the instant you realize you need it — and an examiner who recognizes that moment early has saved more cases than one who never makes a mistake.

War Story. A recovery shop took in a "dead" external drive as a normal data-recovery job — no chain of custody, no imaging, just a tech browsing the file system on a Windows box to assess it. Mid-browse, they found material that turned the job into a criminal matter overnight. By then the evidence had been mounted read-write (timestamps altered, journal replayed), copied around, and handled by three people with no log. The underlying conduct may well have been real, but the handling gave the defense a field day, and the technical findings were fought over for the data's reliability rather than its meaning. The lesson the shop took away — and adopted as policy — was brutal and simple: image first and write-block every intake, even the routine ones. It costs an hour. It can save a case. It is theme two and theme three, learned the hard way: the original is sacred, and every careless action leaves a trace that someone will use against your findings.

Tool demonstration: acquire and verify an image

Let us make the abstract concrete with the tools you will actually use. (Per this book's rule, these commands and outputs are illustrative and were not executed in the sandbox; the byte arithmetic and hash lengths are internally consistent. The full command reference is Appendix H; the tool reference is Appendix C.)

First, identify the device read-only, then enforce a software backstop on top of your hardware write-blocker:

# Read-only inventory of the source (passes through the write-blocker)
sudo fdisk -l /dev/sdb
#  Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
#  Disk model: Forensic via Tableau

sudo blockdev --setro /dev/sdb      # software backstop
sudo blockdev --getro /dev/sdb      # -> 1 (read-only confirmed)

Note the arithmetic from Chapter 2: 976,773,168 sectors × 512 bytes = 500,107,862,016 bytes — a 500 GB drive, exactly. Now acquire with dc3dd (a forensic descendant of dd that computes hashes inline and writes a log — dcfldd is an equivalent alternative):

sudo dc3dd if=/dev/sdb \
           of=/cases/2024-0417/evidence/disk1.dd \
           hash=sha256 hash=md5 \
           log=/cases/2024-0417/evidence/disk1.log \
           hlog=/cases/2024-0417/evidence/disk1.hashes

dc3dd 7.3.1 started at 2026-06-28 09:14:02 -0400
command line: dc3dd if=/dev/sdb of=/cases/2024-0417/evidence/disk1.dd
              hash=sha256 hash=md5 log=...disk1.log hlog=...disk1.hashes
device size: 976773168 sectors (probed),   500,107,862,016 bytes
sector size: 512 bytes (probed)

  500107862016 bytes ( 466 G ) copied ( 100% ), 3942 s, 121 M/s

input results for device `/dev/sdb':
   976773168 sectors in
   0 bad sectors replaced by zeros
   md5:    7a1f9c3e5b2d8f4a6c0e1b3d5f7a9c2e
   sha256: a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4b7e0c3f6a9d2b5e8

output results for file `/cases/2024-0417/evidence/disk1.dd':
   976773168 sectors out  [ok]

dc3dd completed at 2026-06-28 10:19:44 -0400

The acquisition recorded a SHA-256 of the source device. Now prove the image matches it — verify the file against the device through the write-blocker:

sudo dc3dd if=/dev/sdb vf=/cases/2024-0417/evidence/disk1.dd hash=sha256
# ...
#   [ok] /cases/2024-0417/evidence/disk1.dd matches /dev/sdb
#   sha256: a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4b7e0c3f6a9d2b5e8

Identical digests; the image is faithful. Many examiners prefer a GUI for the same job — FTK Imager produces an E01 with the case metadata baked in and verifies automatically:

Created By AccessData(R) FTK(R) Imager 4.7.1.2
Case Number:     2024-0417
Evidence Number: 2024-0417-001
Examiner:        [your name]
Acquired using:  Tableau T356789 SATA write-blocker (fw 1.2.3)

[Computed Hashes — source device]
  MD5 checksum:   7a1f9c3e5b2d8f4a6c0e1b3d5f7a9c2e
  SHA1 checksum:  3f786850e387550fdab836ed7e6dc881de23001b

[Image Verification Results]
  MD5 checksum:   7a1f9c3e5b2d8f4a6c0e1b3d5f7a9c2e : verified
  SHA1 checksum:  3f786850e387550fdab836ed7e6dc881de23001b : verified
  Image contains 976773168 sectors. Verify: PASS

Finally, when you later extract files for examination, you can fingerprint a whole tree and audit it against that baseline so any later change is caught:

# Baseline: hash every extracted file
hashdeep -c sha256 -r /cases/2024-0417/extracted/ > manifest.txt

# Later: audit the tree against the baseline (-a audit, -k known-hashes)
hashdeep -c sha256 -r -a -k manifest.txt /cases/2024-0417/extracted/
#   hashdeep: Audit passed
#       Files matched:           14,902
#       Files moved / new / removed:  0

Worked example: intake of the courtroom evidence

Return to the anchor case — the laptop submitted in the criminal matter — and walk Phase by Phase through intake only. The analysis itself unfolds across later chapters; here you see how the method protects the evidence from the very first minute. We stay strictly procedural; we never describe content.

Phase 1 — Identification. Law enforcement delivers one laptop and its charger under a warrant authorizing a search for evidence of a specific offense. On receipt you photograph the device as-is, record it ("Lenovo ThinkPad T14, serial PF3K9LM2, 256 GB Samsung PM9A1 NVMe SSD"), and note its state: powered off on receipt. (Had it arrived powered on, the order-of-volatility decision of Chapter 15 would come first — capture RAM before considering power.) You assign exhibit number 2024-0417-001 and label it.

Phase 2 — Preservation. You remove the SSD (or image in place through a supported bridge), attach it via a hardware write-blocker, and confirm the blocker is read-only on a scratch test. You acquire to E01 with FTK Imager, embedding the case metadata. The tool computes the source hash and the image hash and reports verified — they match. The original drive returns to the laptop or to an anti-static, tamper-evident bag; the bag is sealed, signed, dated, and placed in the evidence locker; and the chain-of-custody form records intake, the acquisition, and the hashes. The original will not be touched again absent a court order or a defense expert's logged request.

Phase 3 — Analysis (preview). All work proceeds on a copy of the verified E01, re-hashed before each session. Across later chapters you will recover deleted files (Chapter 6), examine photo metadata including EXIF camera and GPS fields (Chapter 20), review browser history (Chapter 18), and build a timeline that establishes when files were created and accessed and by which user account (Chapter 21). You will pursue exculpatory possibilities as rigorously as inculpatory ones — for example, whether files arrived via automatic download or malware rather than deliberate action.

Phase 4 — Reporting (preview). The report (Chapter 26) will state the methodology, the tools and versions, the acquisition and verification hashes, the findings with their byte-level references, and the limitations. At trial (Chapter 27), cross-examination will probe exactly the things this chapter built: Did you write-block? How do you know the image equals the original? Can you account for the evidence at every moment? What did you not find? Because you imaged, hashed twice, write-blocked with a tested device, and documented every transfer, those questions have clean answers — and the evidence stands or falls on what it shows, not on whether it can be trusted. That is the entire purpose of the forensic process.

Common mistakes

• Booting the suspect machine, or plugging its drive into a live OS without a write-blocker. This is the cardinal sin. Windows writes to a disk simply by mounting it; you alter timestamps, the journal, and unallocated space before you have done anything intentional. Always write-block. Always image. Never browse the original.
• Working on the original instead of an image. The original is sacred — for admissibility and because it may be the only copy. One bad write on a failing drive can destroy the data forever. Image first; analyze the copy.
• Skipping the pre-acquisition source hash. If you hash only the image and never the source, you can prove the image hasn't changed since you made it — but you cannot prove the image equals the original device. Hash the source, hash the image, show they match.
• Forgetting volatile data. Pulling the plug on a running machine can lose RAM-resident evidence and, on an encrypted system, the keys you needed to ever read the disk. Decide about volatile data before the power cord (Chapter 15, Chapter 29).
• Gaps in the chain of custody. An undocumented hour, a "quick look" by a colleague, a drive left on a desk overnight — mundane sloppiness, not dramatic tampering, is what breaks chains. Document contemporaneously; sign every transfer.
• Exceeding the scope of authorization. Searching beyond what a warrant or consent permits can suppress evidence and taint the examination. When you find evidence of a different crime, stop and get expanded authority — do not charge ahead.
• Relying on a single, weak hash with no re-verification. Use SHA-256 (and MD5 alongside it), and re-verify the working copy before each session. A lone MD5 invites the collision cross-examination; dual-hashing and re-verification close it.
• Not recording tool names and versions. "I used a forensic tool" is not reproducible. "Autopsy 4.21.0 / The Sleuth Kit 4.12.1" is. Reproducibility is admissibility; version numbers are part of it.
• Confusing a logical backup with a forensic image. A backup copies files and misses the unallocated space, slack, and deleted-file remnants where investigations and recoveries find their answers. Image the device, not the files.
• "Just a quick look" before imaging. Every pre-image glance alters the evidence and undermines your later claim that the image reflects the original's true state. The discipline is image, then look — never the reverse.

Limitations: knowing when to stop

The forensic process is powerful, but it is not omnipotent, and a professional is honest about its edges (theme: know your limitations).

You cannot image what you cannot access. A drive locked by full-disk encryption with no available key yields only ciphertext; a powered-off, encrypted device may be unrecoverable by design (Chapter 29). A locked, modern smartphone may resist acquisition entirely (Chapter 24). Cloud-resident data is not at the scene at all and requires legal process directed at a provider (Chapter 31).

Live systems cannot be perfectly preserved. Acquiring RAM changes RAM — the act of measuring perturbs the thing measured — so a memory image is a slightly smeared snapshot, not a frozen instant. You manage this by documenting what you ran and when, not by pretending the smear doesn't exist (Chapter 22).

Even imaging, done perfectly, cannot rescue media that is physically failing during the read. A drive with degrading heads or fading NAND may give you exactly one good read of a given sector before that sector is gone; this is why recovery imaging triages the most valuable data first and uses tools that handle errors gracefully (Chapter 8, Chapter 9).

The scale of modern storage defeats byte-by-byte human review; you depend on tools, hash sets (such as known-file libraries), and automation — and tools have error rates, which is precisely why Daubert asks about them and why you validate your tools. A hash proves integrity, not authorship or origin. And no amount of technical rigor can supply authority you never had — without a lawful basis, the most pristine image is inadmissible.

Finally, the most professional limitation of all: "the evidence is insufficient to reach a conclusion" is a valid, complete finding. The pressure to deliver a definitive answer is real, and the temptation to overreach is the most dangerous failure in the field, because it is the one that convicts the innocent and discredits the expert. Knowing when to stop — and saying so plainly — is not a gap in your skill. It is the skill.

Progressive project: receive the assignment and write your investigation plan

This chapter begins your progressive project, The Forensic Case File — a complete investigation you build across the book, adding one skill and one evidence type per chapter until, at the capstone in Chapter 38, you assemble a court-admissible case file. Everything you do from here lands in that file. Right now, you do what every real examiner does on day one of a matter: you receive the assignment, verify what you were given, and write the plan that scopes the work.

Your assignment. You have been retained by counsel for Meridian Health Analytics (MHA). A senior data engineer, "J. Okafor," resigned two weeks ago and joined a direct competitor. Before leaving, Okafor allegedly copied a proprietary patient-analytics dataset and supporting source code to removable media and/or a personal cloud account. MHA's counsel has lawful authority to examine the company-owned laptop Okafor used (corporate-owned device, signed acceptable-use policy on file, login banner consenting to monitoring). Law enforcement is not involved; this is a civil matter. You are provided a forensic image, already acquired by MHA's IT team, delivered as mha-laptop.E01 with a sidecar mha-laptop.E01.sha256. (Practice-image sources and how to build your own are in Appendix J; you may substitute any disk image you control.)

Step 1 — Verify the delivery and open the chain. Before anything else, prove the file you received equals the file MHA sent. Confirm the container hash, then record the start of your custody of the image:

# Transfer integrity: does the .E01 file you received match the sidecar value?
sha256sum -c mha-laptop.E01.sha256
#   mha-laptop.E01: OK     <- the CONTAINER file is intact in transit

# Note the value for your records (container hash, e.g.):
#   b7e0c3f6a9d2b5e8a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4

Record this as a chain-of-custody entry (Appendix F has the template): date/time received, from whom, exhibit number you assign (e.g., MHA-2026-001), description, and the verified hash. Remember the distinction from earlier: sha256sum here verifies the container file's transit integrity; when you load the E01 into your tool (Autopsy, FTK), the tool independently re-verifies the acquisition (bitstream) hash stored inside the image — note both in your file.

Step 2 — Write the one-page Investigation Plan. Before you analyze a single artifact, write the plan that will govern the work. At minimum, include these sections:

• Objective. One or two sentences: Determine whether MHA proprietary data was exfiltrated from the subject laptop prior to the user's departure, and if so, by what means, what data, and when.
• Questions to answer (your testable hypotheses). For example: Was removable media attached in the two weeks before resignation, and when? Were the dataset/source-code files accessed or copied in that window? Is there evidence of upload to personal cloud or webmail? Were file timestamps altered or anti-forensic tools run? List the disconfirming checks too — what would show exfiltration did not occur.
• Authority and scope. State the legal basis (corporate-owned device; AUP and monitoring banner; civil matter). State what is in scope (artifacts of file access, removable-media use, cloud/webmail upload, and timeline reconstruction on the provided image) and out of scope (Okafor's personal devices and personal cloud accounts not on this image; any examination beyond MHA's authority). Scope discipline starts on paper.
• Evidence inventory. Exhibit MHA-2026-001 = mha-laptop.E01; container hash recorded; acquisition hash to be confirmed on load.
• Methodology. The four phases as applied here: the image is already acquired (you verify rather than acquire); you will analyze a copy, re-hashed each session; you will document every step for reproducibility.
• Tools (with versions). List what you intend to use and pin the versions (e.g., Autopsy 4.21.0 / The Sleuth Kit 4.12.1; a Python 3.12 environment for the Appendix B scripts). You will refine this as the case proceeds.
• Reporting plan. A factual report distinguishing facts from opinions, with findings tied to artifacts and an explicit limitations section — the deliverable that Chapter 26 teaches you to write.

Deliverables for this chapter's milestone: (1) the completed chain-of-custody entry with the verified container hash; (2) the one-page Investigation Plan with the in/out scope statement and your list of testable questions. Save both to your case folder. You will acquire and verify in earnest in Chapter 14 and recover deleted files from this image starting in Chapter 6 — but the discipline you are practicing now, scoping and documenting before touching the data, is the habit that separates examiners from tinkerers.

Summary

The forensic process is the scientific method applied to digital evidence, and it is the reason your findings are worth anything. Across four phases — identification (find every source of data, including the volatile and the hidden), preservation (protect the original from any alteration), analysis (examine the protected copy and seek the truth), and reporting (explain what you found to a non-technical reader) — runs a single unbroken thread: document everything. Preservation is the heart of the discipline. Because even reading a drive on a live system alters it, you write-block the original; because a backup misses the deleted files and slack where answers hide, you make a bit-for-bit forensic image of every sector; because you must prove the copy is faithful, you hash the source and the image and show they match, preferring SHA-256 and re-verifying before every session; and because admissibility depends on accounting for the evidence's whole life, you maintain an unbroken, signed chain of custody. None of it counts without lawful authorization — a warrant, consent, or corporate authority — and the disciplined scope that authority imposes. The method also draws the line between the two disciplines this book teaches: recovery borrows imaging and hashing for speed and irreplaceability and skips the legal overhead, while forensics adds the full chain-of-custody and authorization machinery for admissibility — same foundation, different consequences, and the wise practitioner asks on every job whether a recovery could become a case. You met the courtroom anchor here, clinically: a forensic image analyzed in a criminal matter, where the chain you build at intake is exactly what survives cross-examination months later. And you began your own case file by doing what real examiners do first — receiving the assignment, verifying the evidence, and writing the plan that scopes the work.

You can now: - Explain the four phases of the forensic process — identification, preservation, analysis, reporting — and map them to the NIST and ACPO frameworks an examiner is expected to know. - Justify why the original is never touched, and use write-blocking and bit-for-bit imaging to protect it — distinguishing a forensic image from an ordinary backup. - Compute and verify cryptographic hashes (MD5, SHA-1, SHA-256), explain the collision question well enough to answer it under cross-examination, and prove a copy equals its source. - Maintain a chain of custody and recognize the legal bases — warrant, consent, corporate authority — and the scope discipline that authorization requires. - Contrast the recovery and forensic workflows and recognize the moment a routine recovery must be upgraded to a forensic process. - Receive a case assignment, verify the delivered evidence, and write a scoped investigation plan — the first milestone of your Forensic Case File.

What's next. Chapter 6 — Logical Recovery — takes the verified image you now know how to make and goes hunting inside it: recovering deleted files from the MFT and inode remnants that still point at "deleted" data, rebuilding formatted and corrupted partitions, and proving — at the byte level — that deleted does not mean destroyed.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.