Case Study 2 — The Carved File That Almost Sank the Case

A departing engineer was suspected of taking proprietary CAD drawings to a competitor. Carving recovered the deleted files from unallocated space — but the company's first report described them as though they still had names, dates, and owners. Opposing counsel turned that single overreach into a credibility problem. The mirror image of Case Study 1: the same carve, read through the forensic lens, where what you claim matters as much as what you recover.

Background

A precision-parts manufacturer suspected that a senior mechanical engineer, leaving in two weeks to join a direct competitor, had copied the company's crown jewels: a folder of proprietary CAD drawings and a clients_pricing.csv export. In his final week the engineer had created a staging folder, copied files to a personal USB device, then deleted the folder, emptied the Recycle Bin, and run CCleaner — the same anti-forensic pattern that threads through this book's IP-theft anchor (developed in Chapter 16 — Windows Forensics, Chapter 21 — Timeline Analysis, and Chapter 30 — Anti-Forensics). CCleaner scrubbed the file-system pointers, so Chapter 6's metadata recovery returned the drawings' names from residual $FILE_NAME` attributes but not their *contents* — the `$MFT records that mapped to the data had been reused. The contents, if they survived at all, were in unallocated space. That meant carving.

The investigation

There were, in effect, two investigations: a hasty in-house one and a proper outside one, and the gap between them is the lesson.

When suspicion first arose, the company's IT lead ran a free carving tool against the live machine, recovered some files, and wrote a short report. A month later, once litigation was real, the laptop went to an outside examiner who did it correctly: imaged the drive to an .E01, recorded MD5 and SHA-256, worked only on the copy, isolated the unallocated space, and corroborated across tools.

sha256sum eng_laptop.E01          # matches the acquisition log -> integrity intact
blkls eng_laptop.dd > unalloc.dd  # carve deleted content, not the live OS
photorec /log /d ./pr_out /cmd unalloc.dd partition_none,fileopt,everything,enable,search
foremost -t pdf,doc,zip,jpg -i unalloc.dd -o ./fm_out   # independent corroboration
bulk_extractor -o ./be_out unalloc.dd                   # features for context

The carve recovered fragments of two CAD-export PDFs and a partial .csv, plus several intact drawing thumbnails. bulk_extractor did what no carver could: in the same unallocated region it surfaced the competitor's email domain, the engineer's personal Gmail address, and a cloud-upload URL — context tying the carved bytes to a person and an act, even where no whole file reassembled.

# be_out/email.txt   (offset  TAB  feature  TAB  context)
1739264   j.engineer.personal@gmail.com   ...attach clients_pricing to j.engineer.pers
1740096   careers@rival-precision.com     To: careers@rival-precision.com  Subject: st
# be_out/url.txt
1822304   https://drive.example.com/u/1/upload   ...uploading clients_pricing.csv to ht

The proper examination, in short, had the goods. What nearly lost them was the first report.

Chain of Custody. A carve can yield thousands of files; you cannot bag-and-tag each one. The chain of custody attaches to the source image and its hash, and the carved files are documented as derivative products of a recorded, reproducible process — source image hash, tool name and version, exact configuration, and a per-file manifest of byte offset and SHA-256. The outside examiner produced exactly that. The IT lead had produced none of it.

Where the first report went wrong

The in-house report listed the carved evidence like this:

Exhibit 4 (as originally written -- WRONG):
  File: clients_pricing.csv
  Created: 2026-05-12 14:08   Modified: 2026-05-12 14:09
  Owner:  ENGINEER\\m.santos
  Path:   C:\Users\m.santos\Desktop\staging\
  Recovered with: [free tool], default settings

Every line of context in that entry was invented. A carved file has no original name, no creation or modification timestamp, no owner SID, and no folder path — those all lived in the $MFT record that CCleaner's deletion and later disk activity had destroyed, which is why the file had to be carved in the first place. The tool had simply labeled the carve clients_pricing.csv because its bytes resembled a CSV, and the report dressed that guess in metadata that did not exist.

Legal Note. Opposing counsel pounced. Under the rules of authentication (and the reliability standard of Daubert, detailed in Chapter 25 — The Legal Framework), they demonstrated that the report's timestamps and owner could not come from a carved file, then argued that if those facts were fabricated, the whole exhibit — and the examiner's competence — was suspect. The judge excluded the in-house report's carved-evidence section. Carving is a well-established, peer-reviewed technique, but admissibility attaches to your application of it; a single unsupportable claim can taint an otherwise sound recovery.

The outside examiner rebuilt the carved evidence to the standard the method actually requires, claiming only what a carve establishes:

Exhibit 4 (corrected):
  Carved object: 1,048,576-byte candidate text/CSV
  Source: eng_laptop.E01, SHA-256 8f2a3c9e... (matches acquisition log)
  Location in image: unallocated space, byte offset 1,739,776
  Method: PhotoRec 7.1, free-space carve; corroborated by Foremost 1.5.7
  Carved-output SHA-256: 2b1c... (this exact byte sequence)
  Internal metadata: none (plain text); content matches the format of the
     company's pricing export by column structure
  Corroboration: bulk_extractor recovered, in adjacent unallocated space,
     a personal email and an upload URL referencing "clients_pricing.csv"
     (be_out/email.txt offset 1,739,264; url.txt offset 1,822,304)
  Establishes: this content existed in unallocated space at this offset.
     It does NOT, by itself, establish the file's original name, timestamps,
     owner, or path; those are addressed by the artifacts in Exhibits 6-8.

The corrected exhibit was weaker-sounding but unassailable: it proved content was present where the examiner said, recovered reproducibly, and tied it to the engineer through corroborating artifacts (USB device history, $LogFile`/`$UsnJrnl traces, and registry keys from Chapters 16 and 21) rather than through metadata the carve never had. It held.

Ethics Note. The broad carve also surfaced material outside the engagement's scope — personal photos and another employee's tax document sitting in unallocated space. The examiner did not review or report them beyond noting that out-of-scope material was encountered and handled per the engagement's scope rules. Carving is indiscriminate by nature; scope discipline — reviewing only what your authority permits and escalating anything that does not belong through the proper channel — is part of doing it correctly. The fuller treatment lives in Chapter 28 — Ethics.

The analysis

  1. A carved file has no file-system metadata — never invent it. No name, no path, no owner, no MACB timestamps; they died with the $MFT record. Reporting them as if they survived is the error opposing counsel most wants you to make. State only what the carve establishes: content present at an offset, recovered by a documented method.

  2. Document to a reproducible standard or the evidence is air. Source-image hash, tool name and version, exact configuration, per-file byte offset and hash. The method survives a reliability challenge only if your run of it can be reproduced by another examiner from your source.

  3. Corroborate the carve with features and surviving artifacts. bulk_extractor tied bytes to a person where no whole file reassembled; USB history and journal traces supplied the when and who the carve could not. A carved file is a strong starting point, not a self-contained conclusion.

  4. The contrast with Case Study 1 is the whole point. The same act — carving unallocated space — restored a photographer's archive and nearly sank a lawsuit. In recovery, the EXIF date is a convenient sort key; in forensics, every claim is a promise you may defend on the stand. Same carve, two standards of proof.

  5. Working forensically by default costs little and saves cases. Image, hash, isolate unallocated space, corroborate, document — the outside examiner's discipline was not exotic, just complete. The in-house shortcut recovered the same bytes and then gave them away with one fabricated exhibit.

Discussion questions

  1. List every claim in the original "Exhibit 4" that carving cannot support, and for each name the file-system structure that would have held it — and why that structure was unavailable here.
  2. bulk_extractor found an email and an upload URL that no carver could recover as files. Explain how a feature scanner surfaces content from fragments too small to carve, and why that makes it a complement to carving rather than a competitor.
  3. ⭐ The corrected exhibit sounds weaker than the original yet is far stronger evidence. Explain that paradox to a non-technical attorney, and draft the one sentence you would add to the report so a jury understands what a carved file does and does not prove.
  4. At the first moment of suspicion, what should the company have instructed instead of having IT carve the live machine? Draft a three-step instruction a non-forensic manager could follow without destroying or tainting evidence.
  5. This case and Case Study 1 are governed by the identical opening move — image first, work on the copy — yet diverge completely afterward. Explain why that convergence is the chapter's central discipline, and what specifically the forensic job demands on top of the recovery job.