Chapter 7 — Exercises

Thirty problems across seven groups: concept checks you can answer in a sentence, hex-reading you do by eye, byte-offset math you work by hand, hands-on labs you run against a practice image, and judgment calls with no single right answer. (answer in Appendix) = worked solution in Answers to Selected Exercises. ⭐ = stretch. Every lab runs against an image, never an original — and several problems hand you the exact bytes or tool output you need, so work from what is printed rather than guessing. Keep Appendix A — File Signatures Reference open; you will check headers and footers against it constantly.

Group A — The core idea: shapes and signatures (concept checks)

These warm up the chapter's foundation: when the file-system map is gone, files are still recognizable by the shape of their own bytes. If you can answer this group in plain sentences, you understand what carving is for; the later groups are about doing it well.

7.1 A client quick-reformatted a 500 GB external drive that held ten years of photos, then realized the mistake within a day. Chapter 6's metadata recovery returned only part of the collection. In plain language a non-technical person will believe — no jargon — explain (a) why nearly all the photos are still physically on the drive, (b) why carving can recover them when undelete cannot, and (c) what carving gives you back that the file system did not — and the one piece of bad news you must deliver in the same breath about what carving cannot promise. (answer in Appendix)

7.2 Define signature (magic number), header, and footer in one sentence each. Then state the real reason file formats carry signatures — a reason that has nothing to do with recovery — and name both the Unix command and the library that identify files by these patterns.

7.3 ⭐ A file named report.dll begins with the bytes FF D8 FF E1. What is it really, and how do you know? Explain why an examiner runs a content-based type scan instead of trusting the extension, name the single Unix command you would run to confirm the true type in one step, and give the relative paths of the two later chapters that lean on the "extensions lie, magic numbers don't" fact. Then state, in one sentence, how this same principle cuts the other way for an anti-forensic actor who renames secrets.zip to report.dll.

7.4 Name the three classic carving strategies and, in one sentence each, say what each does and one file type best served by it. Then state the single assumption all three silently share — the assumption that, when it fails, ruins the carve. (answer in Appendix)

Group B — Reading signatures in hex (identify by eye)

The signature table becomes intuition only once you have read the bytes. Identify these without a tool.

7.5 Identify the file type from each opening byte sequence, and for each say whether the footer situation is reliable or none: (a) 25 50 44 46; (b) 50 4B 03 04; (c) 89 50 4E 47 0D 0A 1A 0A; (d) 47 49 46 38 39 61; (e) D0 CF 11 E0 A1 B1 1A E1; (f) 4D 5A; (g) 52 61 72 21 1A 07 01 00; (h) 53 51 4C 69 74 65 20 66. For (e) and (h), name what kind of file the format typically holds (the legacy-Office case and the database case), and explain why a SQLite signature in unallocated space is a prize for an examiner. (answer in Appendix)

7.6 Your carver reports thousands of "ZIP" files (50 4B 03 04). Explain why "found a ZIP" is not the same as "found a DOCX," name the specific internal member whose presence confirms an Office Open XML document, and list three other everyday file types that are ZIP containers underneath the hood. Then explain why this matters for the counts you put in a report: if PhotoRec says it recovered 4,000 "ZIP" files, what should you actually write, and what one further step turns that vague number into an accurate inventory of documents versus archives?

7.7 ⭐ The literal bytes 66 74 79 70 ("ftyp") identify the MP4/MOV family — but they do not sit at offset 0. At what byte offset do they appear, and what occupies the four bytes before them? Then explain why a naive scan for the TIFF signature 4D 4D 00 2A trips over almost every ordinary smartphone photo.

7.8 Here are the first 16 bytes of a carved file as xxd would render them. State the type, the specific variant, and what the file almost certainly came from — and name the one thing carved into this file that survived even though the file system did not. (answer in Appendix)

00000000: ffd8 ffe1 1a2c 4578 6966 0000 4d4d 002a  .....,Exif..MM.*

Group C — Offsets, sizes, and the math (calculate and verify)

The tools compute all of this; you decode it by hand once so you can check them — and so that when an offset in your report is challenged, you can defend the arithmetic from first principles rather than "the tool said so." Keep the rule sector × 512 = byte offset and its inverse in front of you.

7.9 A JPEG's SOI marker (FF D8 FF) sits at byte offset 0x00202000 of a disk image, and the matching EOI marker (FF D9) begins at 0x00202C50. (a) Compute the exact size in bytes of the carved file, show the hex-to-decimal arithmetic, and explain why you add 2 to the span. (b) The image uses 512-byte sectors; compute the starting sector number of this carved file and confirm it falls on a sector boundary. (c) In one sentence, explain why real file headers almost always sit on a cluster boundary, and how a carver can use that fact to cut its false-positive rate. (answer in Appendix)

7.10 A Foremost audit.txt line reads 1: 00004128.jpg 518 KB 2113536. Foremost numbers carved files by their starting 512-byte block. Verify that block 4128 corresponds to byte offset 2,113,536, then compute the starting block number for the file the same audit lists at byte offset 8192.

7.11 ⭐ Your scalpel.conf caps jpg at 20000000 bytes. A header is found, but no FF D9 appears anywhere in the next 20 MB. (a) Describe exactly what Scalpel writes to disk and why, and whether that output is likely to open in an image viewer. (b) Explain what the cap protects you from — what would a carver with no cap do when it meets a corrupt header followed by a huge unstructured run? (c) Predict the symptom if the cap had instead been set to 5000000 for a legitimate 9 MB photo, and which kind of error (truncation or runaway) each misconfigured cap produces.

7.12 A bulk_extractor run prints Disk Size: 32212254720 and elsewhere a tool labels the same image "30.0 GB." Express the size in GiB and in GB, explain which one the tool actually means despite its label, and compute how many 512-byte sectors the image contains. (answer in Appendix)

7.13 The PNG footer is 49 45 4E 44 AE 42 60 82. (a) Identify which four bytes are the chunk type and which four are the CRC, and explain why this eight-byte footer essentially never occurs by accident. (b) Decode the ASCII of the four type bytes. (c) Contrast that reliability with the BMP header 42 4D, and state what kind of carving error short signatures like BMP's produce — and roughly how often two arbitrary bytes match by chance in random data, to justify your answer numerically.

Group D — Strategies, fragmentation, and smart carving (concept + judgment)

The difference between a carver that produces usable files and one that produces a junk pile. These are the questions that separate someone who can run a carver from someone who can predict and explain its output — which is what a client paying by the hour, and a court weighing your testimony, actually need from you.

7.14 Explain the "nested footer" bug: why does a naive header-to-first-footer JPEG carver truncate almost every phone photo, and what does a structure-aware carver do instead to find the real end of the image? (answer in Appendix)

7.15 Garfinkel's 2007 study of secondhand drives found roughly 6% of files fragmented overall, but far higher rates for certain types. Name three file types he found heavily fragmented and the rough rates, explain why those particular types fragment (consider file size, repeated rewriting, and incremental appending), and state why this pattern means carving fails "most painfully on the most valuable evidence." Then name the one Garfinkel technique that rescues some fragmented files, and the exact case it handles versus the case it cannot.

7.16 ⭐ In ASCII, diagram a file A fragmented into two pieces with an intruding block of file B wedged between them, and show what a linear header-to-footer carve produces. Then explain in two sentences what bifragment gap carving attempts, and why three-or-more fragments in arbitrary order is, in general, not solvable by content alone.

7.17 For each format, name the internal structure a smart carver follows to compute the file's exact length without searching for a footer: (a) PNG; (b) ZIP/DOCX; (c) MP4/MOV. For (c), explain why the location of the moov atom decides whether a structurally perfect carve actually plays, and why cameras that write moov at the end of a recording make video the hardest common format to carve. (d) For JPEG, explain what a marker-parsing carver does that a footer-searching one cannot — and which specific bug it fixes. (answer in Appendix)

7.18 Explain Garfinkel's principle of object validation in two sentences, then list three concrete things it buys a carver (choose from: false-positive suppression, exact length, the nested-footer fix, fragment-reassembly testing). Name the free carver built on this principle and state, in one sentence, why its output is cleaner than a pure signature scanner's.

Group E — Hands-on carving labs (work from an image)

Build the practice subject yourself so the answers are known — carving files whose true contents you already hold is the single fastest way to build intuition, because you can grade every result instead of guessing. Use a spare USB stick or a disk image (Appendix J); submit the commands and the relevant output, and never run a lab against an original.

7.19 Make a ground-truth image. Format a small USB stick FAT32, copy on a dozen photos of varied sizes plus a multipage PDF and one short video, and record each file's name, size, and SHA-256. Then delete them all and reformat the stick. Image it with dcfldd, hash the image, and record the hash. Submit the exact dcfldd command and the resulting SHA-256, and state which region of the stick you expect still holds your "deleted" files and why. Keep this image — the next four labs use it.

7.20 Extract only the unallocated space from your image with blkls image.dd > unalloc.dd, then run PhotoRec against unalloc.dd with the /log option and only photo/video formats enabled. Submit the command, the per-type counts from photorec.log, and explain in two sentences why you carved unalloc.dd rather than the whole image.dd. Then compare the carve count to the dozen files you actually planted: why is it almost certainly higher, and what kinds of "files" make up the difference (think thumbnails, embedded previews, and cache)?

7.21 ⭐ Hash-match the carved JPEGs against the originals whose SHA-256 you recorded in 7.19. How many carves are byte-perfect? For every carve that does not match an original, classify the cause — truncated at an embedded thumbnail, spliced by fragmentation, or a false positive — and state the single observable clue that lets you tell which is which.

7.22 Run Foremost against the same unalloc.dd with -t jpg,png,pdf,mov and save its audit.txt. Compare its per-type counts to PhotoRec's. Name one file type one tool recovered that the other missed, explain a plausible reason for the difference (consider validation, signature lists, and the thumbnail-truncation bug), and state why running more than one carver is good practice in casework. Which of the two tools would you expect to report more JPEGs, which would you expect to report more usable JPEGs, and why is that not a contradiction? (answer in Appendix)

7.23 Carve the video you planted in 7.19. Did it play? Explain the result in terms of contiguity and the moov atom: if it was a short, contiguous clip it likely played; if it was long or fragmented it likely did not. State honestly whether a non-playing carved video means the bytes are gone or merely unreassemblable, and why that distinction matters to a client. Finally, draft the two-sentence expectation you would give before the job to a client whose only copy of a long 4K wedding video sits on a reformatted card — the honest version, not the hopeful one.

Group F — Tools, configs, and corroboration (read and write tool output)

The craft is in the configuration and in reading what the tools tell you. A carver is only as trustworthy as the configuration you fed it and the audit trail it left behind, and corroboration across independent tools is how a single result becomes a defensible finding.

7.24 Write three correct scalpel.conf lines — one for GIF89a, one for PNG, and one for PDF using the REVERSE option — using the exact header and footer bytes from the chapter and sensible maximum sizes. In one sentence, explain why PDF (and ZIP) want REVERSE. (answer in Appendix)

7.25 ⭐ Read this Foremost audit excerpt and answer: the tool version, the exact invocation, the image size, and how many files were extracted. Then explain why the mov:= 0 line appears even though MOV was requested, and compute the starting 512-byte block of the file at offset 5,142,528.

Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Invocation: foremost -t jpg,png,pdf,doc,zip,mov -i unalloc.dd -o foremost_out
Length: 30 GB (32212254720 bytes)
Num      Name (bs=512)        Size       File Offset      Comment
2:       00010044.jpg          1 MB          5142528
...
mov:= 0

7.26 Run bulk_extractor -o be_out unalloc.dd against your practice image. (a) Name four feature files it produces. (b) Explain what a *_histogram.txt file shows you that the raw feature file does not, and why an investigator usually reads the histogram first. (c) Decode the forensic path 1048576-ZIP-3413. (d) Explain why bulk_extractor can surface an email address that no file carver could ever recover as a file. (e) bulk_extractor's ccn.txt scanner validates candidate credit-card numbers with the Luhn checksum before reporting them — explain why that validation step matters, in terms of the false-positive problem that haunts every byte-pattern scan.

7.27 The chapter's minimal Python JPEG carver contains four deliberate flaws. Name all four, and for each give the single change that fixes it. One flaw — data = f.read() — is not a correctness bug at all on a small file but is fatal on a real one; explain precisely why, and what "streaming" the input means in practice. Then name the production tool that is, in effect, "this toy with all four flaws fixed," and the appendix that holds a better-behaved version you may reuse.

Group G — Forensics, limits, ethics, and the case file

Say what a carve proves, name what it cannot, and protect the people behind the bytes. This is the layer that separates a technician who recovers files from a professional whose work survives a courtroom and treats the data — and the people it belongs to — responsibly.

7.28 A junior colleague's report lists a carved file as: "wedding.jpg, created 2016-07-23 19:42, owner jdoe, recovered from \Users\jdoe\Pictures." (a) Identify every claim in that entry that carving cannot support, and for each, name the file-system structure that would have held it and why that structure was unavailable. (b) Rewrite the entry to state only what a carve actually establishes — content, offset, method, source hash, output hash — noting any internal metadata as internal. (c) The file genuinely does contain an EXIF DateTimeOriginal of 2016:07:23; explain how you may and may not use that date in the report. (answer in Appendix)

7.29 ⭐ You are authorized to carve a drive image only to recover stolen engineering drawings. Partway through, PhotoRec surfaces material that appears to be child sexual abuse material. State, clinically and in order, exactly what you do and do not do next, the U.S. statute that governs your reporting duty, and the chapter that owns the full ethics-and-well-being treatment (give its relative path). In one sentence, explain why carving is the single technique most likely to raise this situation.

7.30 Progressive project — carve and document the case image's unallocated space. Advancing your Forensic Case File: (a) re-verify your working image's SHA-256 against the Chapter 5 acquisition record and log the result; (b) run blkls case001.dd > case001_unalloc.dd and record the extracted size; (c) carve with PhotoRec (/log) and corroborate with Foremost, saving both logs and comparing the per-type counts; (d) run bulk_extractor and review email.txt, url.txt, and exif.txt (and their histograms) for context the carve itself cannot provide; (e) build the carved-evidence manifest recording each relied-upon file's byte offset, size, and SHA-256; (f) write the limitation note stating that carved files lack file-system metadata (no original name, path, owner, or MACB timestamps), that any shown dates derive from alterable internal metadata, and that the carve is reproducible from the named source, tool, version, and configuration. Close by committing one sentence to scope discipline — that you review only what your authority permits, and surface anything outside it through the proper channel rather than exploring it yourself.

Self-check. You have mastered this chapter when you can glance at FF D8 FF E1 and say "Exif JPEG, off a camera or phone" without looking it up; when you reach for blkls and a structure-aware carver by reflex and know before you run them which files will come back clean and which will arrive truncated or spliced; and when you can write a carved-evidence entry that an opposing expert cannot tear apart because it claims nothing the carve did not establish. If labs 7.19–7.23 ran on your own ground-truth image and your hash-matches in 7.21 explained every mismatch, you are ready for Chapter 8 — Hard Drive Recovery, where the problem stops being a lost map and becomes failing hardware — the drive itself.