Chapter 14 — Exercises

A mix of concept checks, hands-on labs (write the command, read the tool output, build the chain, calculate and verify the hash), and judgment calls. Groups A–G move from what an image is through how you make and verify one to how you account for it and the cases that don't fit the textbook — roughly the arc of the chapter itself. Work the hands-on items with a forensic Linux distro and a small disposable USB drive you own — never on real evidence or data you do not own (see Appendix J for practice images and a lab build). (answer in Appendix) marks problems with a worked solution in Answers to Selected Exercises. ⭐ marks a stretch problem. Aim to be able to justify every answer the way you would on the stand: concretely, in plain language, with the specifics written down — remembering the chapter's warning that, in court, your notes are you.

Group A — The cardinal rule and what an image captures

14.1 In your own words, state the cardinal rule of this chapter and explain why it is arrived at from opposite directions in data recovery versus digital forensics. Keep it to four sentences, and name the one recurring theme from the book that this rule embodies. Then add a sentence on what concretely changes in your method depending on which discipline you are in — even though the rule is the same. (answer in Appendix)

14.2 A junior technician says, "I copied every file off the suspect's drive with robocopy, so I have everything." (a) List four distinct categories of data that a file-level copy throws away but a physical, sector-by-sector image preserves, and for each give one concrete example of evidence it might contain. (b) Using the chapter's "A FILE COPY sees this / A FORENSIC IMAGE captures this" diagram as your model, explain in one sentence why the phrase "I have everything" is precisely backwards. (c) The robocopy run also updated last-access timestamps on every file it touched on the source. Explain how that single side effect could destroy the very evidence an investigation depends on, referencing the IP-theft anchor case where altered access times were the issue.

14.3 A 512-byte-per-sector drive reports 500,118,192 sectors. (a) Show the arithmetic for its capacity in bytes, then convert to both GB (decimal, ÷10⁹) and GiB (binary, ÷2³⁰). (b) Explain why a drive marketed as "256 GB" shows up in your imaging tool as roughly 238.5 GiB. (c) Your destination volume has 240 GiB free. Can it hold a raw image of this drive? Can it hold a compressed E01? Justify each answer. (answer in Appendix)

14.4 ⭐ Explain the difference between slack space and unallocated space, citing the addressable-sector/offset model from Chapter 2. Then (a) explain why a forensic raw image of a drive that is "90% empty" still occupies 100% of the source capacity on your destination, while the same drive as a compressed E01 may occupy a small fraction of that — and what physical property of "empty" space makes the E01 collapse. (b) A colleague says, "If the E01 is so much smaller, it must be throwing data away — that can't be forensically sound." Explain why compression is lossless here and why the verification hash proves the E01 contains every original byte despite being smaller on disk.

14.5 Modern "Advanced Format" media uses 4,096-byte physical sectors instead of 512. (a) Give the byte offset of the start of sector 2,048 on a 4Kn drive, and on a 512-byte drive. (b) Why does the imaging tool report "Bytes per Sector" in its summary, and why must you record it? (c) Why does sector size change speed and reporting but not the fundamental result of a bit-for-bit image?

Group B — Write-blocking

14.6 A colleague plans to "take a quick look" at a suspect drive by connecting it to a running Windows workstation and browsing it in Explorer "without changing anything." (a) List at least five specific writes the operating system may perform on that source before your colleague clicks a single file. (b) For each, explain why it is fatal to the evidence's integrity in terms of the disk's hash. (c) Tie this to the chapter's War Story: what did the corporate investigator destroy, and what survived? (d) Your colleague protests, "but I opened the files read-only." Explain why "I opened the files read-only" and "the disk was read-only" are completely different claims, and why only the second one is defensible.

14.7 Compare hardware and software write-blocking across these four dimensions, one or two sentences each: (a) independence from the host OS, (b) independent validation/testability (name the relevant NIST program), (c) simplicity of the claim you must defend on the stand, (d) reliance on correct configuration under time pressure. (e) The chapter notes that "most forensic mistakes are configuration mistakes made under time pressure." Explain how hardware blocking removes that entire class of failure, and why that matters more at 3 a.m. on a search-warrant execution than in a calm lab. Conclude with which you would use for an evidentiary acquisition and a one-sentence justification a juror could follow. (answer in Appendix)

14.8 Design a write-blocker validation procedure you could run and log before trusting a blocker on a real case. (a) Specify the exact steps in order, the command you would deliberately use to attempt a write through the blocker, and the precise observation that proves the blocker works. (b) State what you record in your notes about the blocker itself (four specific attributes). (c) Explain the chapter's claim that "a write-blocker you have never tested is a write-blocker you cannot vouch for." (d) Your blocker passed validation last quarter but its firmware was updated last week. Do you need to re-validate, and why? State the principle in one sentence. ⭐

14.9 On a Linux forensic distro you must image a SATA drive but have no hardware blocker on hand. (a) Write the sequence of commands that establishes a software read-only configuration: set the block device read-only, and — if you must mount — mount read-only with the journal suppressed and access-time updates disabled (give the exact mount options and say what each one prevents). (b) Better still, state the approach that avoids mounting the source at all, and why it is safest. (c) Give two reasons this whole approach is a supplement to, not a replacement for, hardware blocking in court.

Group C — Imaging tools and commands (hands-on)

14.10 (a) Write a complete, correct dcfldd command line to acquire physical device /dev/sdc for case 2026-0317, evidence item 02, that: computes MD5 and SHA-256 on the fly; writes a piecewise hash every 1 GiB; logs the per-window hashes to one file and the overall hashes to another; logs unreadable sectors to an error log; pads bad reads to preserve byte offsets; uses a 4 MiB block size; and writes a raw image plus separate .md5 and .sha256 logs into /mnt/evidence/. Annotate each operand with one phrase explaining its forensic purpose. (b) After the acquisition finishes, write the single hashdeep command that verifies the finished image against both algorithms, and explain why you would still re-run it before each later analysis session even though the acquisition already verified. (answer in Appendix)

14.11 ⭐ Explain precisely what goes wrong if you image a drive with dd ... conv=noerror but omit sync. Walk through, sector by sector, what happens to byte offsets after the first unreadable sector; explain why the resulting image is silently corrupted in a way that may not surface until file-system parsing fails deep into analysis; and state the one-line fix.

14.12 Read this FTK Imager summary excerpt and answer the questions below.

[Drive Geometry]
 Bytes per Sector: 512
 Sector Count: 1,953,525,168
[Physical Drive Information]
 Drive Model: WDC WD10EZEX-08WN4A0
 Drive Serial Number: WD-WCC6Y7AANP12
[Computed Hashes]
 MD5 checksum:  3b5d41...e2a9
 SHA1 checksum: a17f...90c4
Image Verification Results:
 MD5 checksum:  3b5d41...e2a9 : verified
 SHA1 checksum: a17f...90c4 : verified

(a) What is the source capacity in bytes and in GiB? (b) Which two hash algorithms did FTK Imager use here, and which one does it not compute by default? (c) Your lab policy mandates SHA-256 for every acquisition — does this report satisfy it, and if not, name two tools or methods that would let you produce a SHA-256 of the same evidence. (d) Why is it useful that the report records the drive model and serial number? (answer in Appendix)

14.13 Plain dd and dcfldd both produce a complete copy. (a) Give the three forensic gaps in plain dd that dcfldd (or dc3dd) closes. (b) Explain specifically why imaging a failing evidence drive with plain dd and then hashing the image separately is a dangerous choice for the drive's survival — i.e., the "two reads" problem. (c) Which tool would you script for acquiring a rack of twenty drives over SSH, and why? (d) The chapter calls dd "the honest baseline — understand it, because everything else is dd with the forensic gaps filled in." Explain what is gained pedagogically by learning plain dd first even though you will rarely use it on real evidence.

14.14 Read this Guymager .info excerpt and state (a) the image format and sub-format, (b) whether compression was used, (c) whether the acquisition verified and what "verified" means here, and (d) one thing this format carries that a raw .dd image would not.

Format           : Expert Witness Format, sub-format Guymager, compressed
MD5              : 7c0a9e...51bd
SHA-256          : f29b34...8ace
MD5 verified     : yes  (source image matches acquired image)
SHA-256 verified : yes  (source image matches acquired image)
State            : Finished successfully

Group D — Image formats

14.15 You are handed an unknown file and its first sixteen bytes are:

0x00000000  45 56 46 09 0D 0A FF 00  01 01 00 00 ...

(a) Identify the format and decode what the ASCII portion spells. (b) Explain what the bytes immediately following the signature describe. (c) Name the open-source library and the three command-line tools you would use to verify, inspect metadata of, and mount read-only this file. (d) How would the first bytes differ if instead you were handed a raw image of an MBR-partitioned disk? (answer in Appendix)

14.16 ⭐ A 4 TB evidence drive is roughly 95% empty (long runs of 00). (a) Estimate, with reasoning, how much destination space a raw image will consume versus a compressed E01. (b) Explain the mechanism — at the chunk level — that makes the E01 collapse on runs of identical bytes. (c) Give one situation in which you would still choose raw despite its size cost, and one situation in which a freshly wiped (all-FF or all-00) drive also compresses to almost nothing.

14.17 For each scenario, choose raw, E01, or AFF4 and justify in one sentence: (a) you must hand a verifiable image to opposing counsel's expert who may use any toolset; (b) you need embedded case metadata, per-chunk integrity, and compression for a routine 1 TB laptop drive bound for court; (c) you must capture only the relevant 300 GB of data-bearing extents from a 60 TB storage array without bit-copying the whole thing; (d) you are cloning a customer's failing drive onto a healthy replacement to hand back today, no court involved; (e) you are imaging to a destination formatted FAT32, which cannot hold a single file larger than 4 GiB, and the source is 500 GB. (For (e), name the feature — fragment/segment size — and the value you would set.) (answer in Appendix)

Group E — Hash verification (calculate and verify)

14.18 During triage you notice that 47 files in a directory listing all share the MD5 digest d41d8cd98f00b204e9800998ecf8427e. (a) Without computing anything, state what these files have in common and how you know. (b) What is the equivalent SHA-256 value you would expect for the same files? (c) Why is recognizing these "constant" hashes a useful triage skill? (answer in Appendix)

14.19 A re-verification of an image before an analysis session returns a SHA-256 that does not equal the value recorded at acquisition. (a) Construct the diagnostic decision tree you would follow, in order of likelihood, listing at least five possible causes and the observation or action that would confirm or rule out each. (b) State clearly what you must do before any further analysis. (c) Name the single artifact (produced at acquisition) that would most help you localize where the difference is. (d) Of your five causes, identify the one that, if all others are ruled out, becomes a finding in its own right — and explain why an examiner must never quietly "fix" it by re-imaging without documenting the mismatch first. ⭐ (answer in Appendix)

14.20 You acquire a drive and your notes record source MD5 = 9a1c0e6b4f7d2a83c5e10f9b6d4a72e8. After imaging, the tool reports image MD5 = 9a1c0e6b4f7d2a83c5e10f9b6d4a72e8, but the image SHA-256 you wrote in your notes differs from the source SHA-256 by a single hex character. (a) Given the same bytes, is it plausible that MD5 matches while SHA-256 genuinely differs? (b) What is the most likely real explanation? (c) How do you resolve and document it defensibly, and what habit would have prevented the ambiguity?

14.21 You acquired with dcfldd hashwindow=512M. On a pre-analysis re-verification the overall hash mismatches, but the per-window log shows windows 1–11 and 13–40 unchanged and only window 12 differing. (a) What does this localization tell you that a single whole-disk hash never could? (b) Compute which byte range window 12 covers (windows are zero- or one-indexed — state your assumption and show the math for a 512 MiB window). (c) Given the source was already flagged as a failing drive, write the one-sentence integrity statement you would put in the report. Reference the technique in Chapter 8.

14.22 Demonstrate the avalanche effect for yourself: using any hashing tool, hash the exact string The quick brown fox jumps over the lazy dog, then hash it again with the final dog changed to cog. (a) Confirm your MD5 of the first string equals 9e107d9d372bb6826bd81d3542a419d6. (b) Quantify, roughly, how many hex digits of the output changed for a one-letter input change. (c) Explain in one sentence why this property is the entire reason a hash can prove a multi-terabyte image is unaltered.

Group F — Chain of custody and physical handling

14.23 Build the chain-of-custody log for the following events and then identify the gap that a defense attorney would attack:

24 June, 09:14 — Det. A. seizes a laptop at the scene. 24 June, 11:40 — Det. A. logs it into the evidence room with Tech B. 25 June, 08:05 — Examiner C. signs the item out for imaging. 25 June, 14:20 — the imaging is complete. 26 June, 16:00 — Tech B. records the item back on the storage shelf.

Lay out the log in the column format from the chapter (Date/Time, Released by, Received by, Purpose, Signature), then (a) state in one sentence what the cross-examiner will ask about, (b) name the maxim the gap violates, and (c) describe the corrective entry that should have existed between 14:20 and 16:00 on 25 June to close the hole. (d) The defense does not have to prove the laptop was tampered with during the gap — explain, in one sentence, why merely raising a credible doubt about the chain can be enough to suppress the evidence. (answer in Appendix)

14.24 (a) Write the acquisition verification report section (the boxed text block style from the chapter) for this acquisition: case 2026-0488, item 03, a 1 TB Seagate SATA HDD, S/N ZAB9X2Q1, 1,000,204,886,016 bytes, acquired to compressed E01 with Guymager through a Tableau T356789iu (SATA) blocker validated that morning, MD5 and SHA-256 both verified, working copy verified against the acquisition value. Invent plausible (clearly fictional) hash values and label them as fictional. Include the write-blocker model and validation time, because those belong in the record. (b) Then write the first two chain-of-custody transfer rows (intake to storage, and storage to examiner for imaging) that would accompany this report, in the chapter's column format. (c) In one sentence, explain why the report and the chain are stored together but prove different things.

14.25 Match each physical-handling control to the specific threat it neutralizes, and explain in one sentence why substituting the wrong one fails: (a) anti-static bag, (b) Faraday bag, (c) numbered tamper-evident seal signed across the closure, (d) photographs taken before opening, (e) locked, access-controlled storage with its own access log. Then (f) state which single control most directly supports the claim "this is the same item that was seized, unchanged," and (g) explain why signing across the seal — rather than next to it — is what makes a later opening visible and attributable.

14.26 ⭐ A powered-on Android phone with a cracked screen arrives at intake, still connected to cellular. (a) List, in order, the immediate handling and acquisition-staging steps you take. (b) Justify the Faraday-bag decision in terms of a specific threat the bag defeats. (c) Explain why letting the battery die before acquisition can be its own problem (think about encryption-at-rest state). (d) Why is an anti-static bag not a substitute for a Faraday bag here? Reference Chapter 24 for the deeper treatment.

14.27 Before acquiring, you must prepare the destination media. (a) Why should a destination drive be wiped and verified before you image onto it, rather than just reformatted? (b) What contamination risk does old data on the destination create for your evidence's credibility? (c) Write the one-line command you would use to wipe a destination with zeros, and the command to verify the wipe. (d) Why must the destination not auto-mount or auto-index your source?

Group G — Judgment, edge cases, and the progressive project

14.28 ⭐ At a scene you find a desktop powered on, logged in, with a full-disk-encrypted volume currently unlocked. (a) State the dilemma in one sentence. (b) Argue both options — pull the plug for a clean image of unreadable ciphertext, versus keep it running to preserve the decrypted state — naming what each choice preserves and what each destroys. (c) Which order of operations does this push you toward, and which two later chapters own that workflow? (answer in Appendix)

14.29 Your hdparm -N /dev/sdb query reports a user-addressable size smaller than the drive's native capacity stamped on its label. (a) What does this indicate? (b) Name the two mechanisms that can make a drive report itself as smaller than it is, and give the second hdparm query you would run to check the other one. (c) What must your acquisition do as a result, and why is trusting the reported size a classic acquisition mistake? (d) Connect this to Case Study 1: how many gigabytes were hidden there, and what did the hidden region turn out to contain? (e) Why is "the drive told me its size and I believed it" a weak answer under cross-examination, while "I queried for and captured the full native capacity" is a strong one?

14.30 Progressive project — acquire the case evidence. Using a disposable USB drive you have populated yourself: (1) document the source (make/model/serial, capacity, photograph); (2) acquire it through a validated read-only configuration to a compressed E01 (or a raw .dd with dcfldd), entering a case number, evidence number, examiner, and notes, computing MD5 and SHA-256; (3) verify source and image hashes match for both algorithms; (4) make a working copy and verify its hash equals the acquisition value; (5) start a chain-of-custody log using the Appendix F template. Save the verification report, the dual-hash record, and the chain log into your Forensic Case File. Everything you do in Chapters 15–24 will be performed on this working copy, and every finding will trace back to these hashes. Then reflect in writing: which step took longest, where were you tempted to cut a corner, and what is the one sentence you could now say on the stand about how you know your image is unaltered? Keep that reflection — it is the difference between performing the steps and understanding them.

14.31 ⭐ Extend 14.30: write a short Python helper (model it on the chapter's chunked-hashing script) that hashes your image in 1 MiB blocks, prints MD5 and SHA-256, and appends a single chain-of-custody line to a log file — opening the image strictly read-only so it can never alter the evidence. (a) Run it against your working copy and confirm the printed SHA-256 equals your acquisition value. (b) Explain why reading the file in chunks matters for a multi-terabyte image (think about RAM). (c) Explain the single line/argument in the script that guarantees the evidence is never modified — and what would change if you opened the file "rb+" instead of "rb". (d) Why is a script like this illustrative for learning but still something you would validate against a known-good reference tool (e.g., sha256sum) before relying on it in a real case? Add the script to your personal toolkit (see Appendix B).

Self-check. You have mastered this chapter when you can, without notes: explain what a physical image captures and why; choose and validate a write-blocker and defend the choice in plain language a juror would follow; write a dcfldd acquisition command from memory and read an FTK Imager or Guymager verification report at a glance; pick raw vs. E01 vs. AFF4 for a given job; describe the three-link hash chain, react correctly to a mismatch, and explain why two algorithms beat one; and build a gap-free chain of custody around a verified image. If a defense attorney asked "how do you know nothing changed?" and your answer is one calm, concrete sentence about a tested write-blocker and two matching hashes, you are ready for Chapter 15 — Live Response and Triage Forensics, where the comfortable assumption that you can power the machine off no longer holds.