Chapter 7: File Carving — Recovering Files Without File System Metadata

Where you are: Part II, Chapter 7 of 40. Chapter 6 recovered deleted files the easy way — by reading the residual metadata the file system left behind (deleted-but-intact $MFT records, orphaned ext4 inodes, FAT directory entries with a lopped-off first character). This chapter is what you do when that metadata is gone: reformatted, overwritten, corrupted beyond use. Here you stop trusting the file system entirely and start reading the raw bytes for the shape of files themselves. This is where the wedding-photos anchor (introduced in Chapter 1, worked in Chapter 6) reaches its hardest stage — the regions of the drive where the MFT no longer points to anything.

Learning paths: 💾 Data Recovery — this is one of your core, daily skills; carving is how you pull photos and documents out of formatted, repartitioned, and "the file system is dead" drives. 🔍 Forensic Examiner — carving recovers deleted evidence from unallocated space, slack, and damaged volumes, but you must understand exactly what a carved file can and cannot prove. 🛡️ Incident Response — carving pulls malware binaries, configuration fragments, and exfiltrated documents out of memory dumps and wiped volumes. 📜 Legal/eDiscovery — you need to understand why a carved file has no filename, no path, and no timestamps, because that fact directly affects authentication and evidentiary weight.

When the map is gone but the territory remains

A file system is a map. The $MFT on NTFS, the inode table on ext4, the catalog file on APFS — these structures tell the operating system where every file's bytes live, what the file is called, when it was created, who owns it, and which clusters belong to it. In Chapter 6 you learned that deleting a file does not erase the file's data; it only flags the map entry as reusable. As long as the map still describes the deleted file — even faintly — recovery is a matter of reading the map and following it to the data.

But maps get destroyed. A quick format writes a fresh, empty $MFT` over the start of the volume. A repartition rewrites the partition table and the file-system superblocks. A failing controller scrambles the directory structures. A second installation of the operating system lays down gigabytes of new files, and the new `$MFT grows over the top of the old one. When the map is gone, the techniques of Chapter 6 hit a wall: there is no deleted-but-intact record to read, no cluster run to follow, no orphaned inode to resurrect. The pointer is not merely removed — the entire pointer structure is gone.

And yet the territory remains. This is the first recurring theme of this book stated in its purest form: deleted is not destroyed. Formatting a 500 GB drive writes only a few megabytes of new file-system metadata at the front; the other 499-plus gigabytes of photos, documents, and video are still sitting in the same physical sectors they always occupied. The operating system can no longer find them, because the map that named them is gone. But the bytes are there. The job of this chapter is to find files by their content alone, with no map to guide you.

That technique is called file carving. You scan the raw bytes of a disk image — sector by sector, ignoring the file system entirely — looking for the recognizable beginnings and endings of known file types. When you find a JPEG's distinctive opening bytes (FF D8 FF) you have found the start of a picture. When you find the JPEG's closing bytes (FF D9) you have, probably, found its end. Everything between is, probably, a photograph. You copy those bytes into a new file, give it an arbitrary name, and you have carved a file out of an undifferentiated sea of data — recovered without a single byte of file-system metadata.

Why This Matters. Carving is the recovery technique of last resort and, simultaneously, one of the most powerful tools in the forensic arsenal. It is last-resort for recovery because it produces files stripped of every piece of context the file system provided — no name, no folder, no timestamps. It is powerful for forensics because it sees what the file system has been told to forget: it reads unallocated space, file slack, the gaps between partitions, the contents of a "wiped" volume that was only quick-formatted. When a suspect empties the Recycle Bin, runs a registry cleaner, and reformats a thumb drive, the file-system map is scrubbed — but carving still pulls the underlying files out of the raw sectors. Deleted is not destroyed; carving is how you prove it.

Two views of the same drive

It helps to hold both techniques in your head at once. Chapter 6 works with the file system; this chapter works against its absence.

  FILE-SYSTEM VIEW (Chapter 6: logical recovery)     CARVING VIEW (Chapter 7)
  --------------------------------------------       --------------------------------
  $MFT record  ->  filename, MACB timestamps,        (no metadata available at all)
                   parent directory, owner SID,
                   $DATA attribute -> cluster runs    scan raw sectors / bytes for
        |                                             header ... footer patterns
        v                                                   |
  follow the cluster runs to the file's data              v
                                                     reconstruct the file from its
  REQUIRES the metadata to still exist.              CONTENT alone.
  Fails the moment the $MFT is overwritten.          Works even when there is NO $MFT,
                                                      no partition table, no superblock.

The trade is stark. Logical recovery, when it works, gives you everything: the file and its name, dates, and location. Carving gives you only the file — the bytes — and asks you to figure out the rest. For a data-recovery client who just wants the photos back, that trade is often acceptable. For a forensic examiner who needs to prove when a file was created and who put it there, a carved file is a starting point, not a conclusion. We will return to that distinction throughout the chapter, because it is the difference between the two disciplines this book is about.

The core idea: files have shapes

Carving works because file formats are not arbitrary. A program that writes a JPEG and a program that reads it have to agree on a structure, and that agreement is encoded in the bytes. Most formats begin with a signature — a short, fixed sequence of bytes near the start of the file that announces "I am a file of type X." These signatures are also called magic numbers, a term that goes back to early Unix, where the file command identified file types by consulting a database of these patterns (today that database is libmagic, the engine behind the file utility).

The signature exists for a practical reason that has nothing to do with recovery: software needs to identify a file's true type regardless of its name. A .jpg file renamed to .txt is still a JPEG, and an image viewer that checks the first three bytes (FF D8 FF) will know it. Extensions are a convenience for humans and the operating system's file associations; magic numbers are the truth. Anti-forensic actors exploit this — renaming a secrets.zip to report.dll hides it from a casual extension filter — but the magic number gives them away, and a forensic examiner runs file (or a content-based type scan) precisely because extensions lie. (You will use this fact again in Chapter 16 — Windows Forensics and Chapter 30 — Anti-Forensics.)

For carving, the magic number is the header — the thing you scan for. Many formats also define a footer (also called a trailer): a fixed byte sequence that marks the end of the file. JPEG ends with FF D9; GIF ends with a single 3B byte; PNG ends with the eight bytes of its IEND chunk. A format with both a reliable header and a reliable footer is the carver's dream: find the header, find the next footer, copy everything in between, and you have an exact, complete file. Formats with a header but no dependable footer are harder — you have to guess where the file ends — and formats with no distinctive header at all (plain text, CSV, many proprietary blobs) are nearly impossible to carve, because there is no shape to recognize.

A gallery of signatures

Below is a working subset of the signatures you will meet constantly. The full reference — hundreds of formats, with header and footer bytes, typical offsets, and notes — lives in Appendix A — File Signatures Reference. Memorize the top handful; you will read them in hex dumps for the rest of your career.

TYPE        HEADER (hex)                         FOOTER (hex)            NOTES
--------    ---------------------------------    --------------------    ----------------------------
JPEG/JFIF   FF D8 FF E0                          FF D9                   APP0 = JFIF
JPEG/Exif   FF D8 FF E1                          FF D9                   APP1 = Exif (camera/phone)
JPEG (any)  FF D8 FF                             FF D9                   safest generic header
PNG         89 50 4E 47 0D 0A 1A 0A              49 45 4E 44 AE 42 60 82 footer = IEND chunk + CRC
GIF87a      47 49 46 38 37 61                    00 3B                   "GIF87a"
GIF89a      47 49 46 38 39 61                    00 3B                   "GIF89a", 3B = ';'
PDF         25 50 44 46                          25 25 45 4F 46          "%PDF" ... "%%EOF"
ZIP / DOCX  50 4B 03 04                          50 4B 05 06             "PK.." ; DOCX/XLSX/PPTX/JAR
   /XLSX                                                                 /ODF/APK are all ZIP
MP4 / MOV   .. .. .. .. 66 74 79 70              (none reliable)         "ftyp" at byte offset 4
TIFF (LE)   49 49 2A 00                          (none reliable)         "II*" little-endian
TIFF (BE)   4D 4D 00 2A                          (none reliable)         "MM" big-endian
BMP         42 4D                                (none reliable)         "BM" (very short = collisions)
DOC/XLS/PPT D0 CF 11 E0 A1 B1 1A E1              (none reliable)         legacy OLE2 compound file
RAR (v5)    52 61 72 21 1A 07 01 00              (none reliable)         "Rar!"
7-Zip       37 7A BC AF 27 1C                    (none reliable)         "7z"
GZIP        1F 8B 08                             (none reliable)         deflate stream follows
MP3 (ID3)   49 44 33                             (none reliable)         "ID3" tag at start
SQLite 3    53 51 4C 69 74 65 20 66 6F 72        (none reliable)         "SQLite format 3\0"
            6D 61 74 20 33 00
PE / EXE    4D 5A                                (none reliable)         "MZ" DOS stub; PE header later

Three things in that table deserve emphasis, because they shape everything you do.

First, a footer of "none reliable" is the common case. JPEG, GIF, PNG, and PDF give you a clean ending; most other formats do not. A TIFF, a Microsoft Office .doc, an MP4 — these have no fixed terminating byte sequence. For them you cannot carve header-to-footer; you must use one of the other strategies below.

Second, the ZIP signature is everywhere. Modern Microsoft Office files (.docx, .xlsx, .pptx), OpenDocument files (.odt), Java archives (.jar), Android packages (.apk), and EPUB books are all ZIP containers underneath. They all begin with 50 4B 03 04 ("PK\x03\x04", named for ZIP's author Phil Katz). So when your carver reports thousands of "ZIP" files, many are actually Office documents — and to tell them apart you must look inside the archive (a [Content_Types].xml member means Office Open XML). This is your first hint that pure signature matching is only the beginning.

Third, some signatures don't live at offset 0. The MP4/MOV family (formally ISO Base Media File Format) begins each "box" with a four-byte size followed by a four-byte type. The very first box is usually ftyp, so the literal bytes 66 74 79 70 ("ftyp") appear at byte offset 4, not 0, preceded by the box's length. A carver must know to look slightly inside the file, not just at its first byte. Similarly, the EXIF metadata inside a JPEG is itself a little TIFF structure (4D 4D 00 2A or 49 49 2A 00) embedded after the JPEG's APP1 marker — which means a naive scan for TIFF headers will trip over every camera photo's internal EXIF block. Shape is not always at the start, and shapes nest inside other shapes.

Tool Tip. Before you carve anything, learn to read bytes by hand. xxd image.bin | less and xxd -l 64 file.jpg give you annotated hex+ASCII dumps; file mystery.bin runs the magic-number database and tells you the real type; hexdump -C is the BSD/macOS equivalent of xxd. On Windows, Format-Hex -Path file.jpg -Count 16 does the same. You should be able to glance at FF D8 FF E1 and say "Exif JPEG, straight off a camera or phone" without looking it up. Every carving tool is, at heart, an industrial-scale version of you reading hex.

Reading a file's fingerprint in hex

Let's read some real headers and footers, because the abstract table becomes intuition only once you have stared at the bytes. Here is the first 32 bytes of a JPEG taken on a phone, shown as xxd would render it — offset on the left, hex in the middle, ASCII on the right:

$ xxd -l 32 carved_000123.jpg
00000000: ffd8 ffe1 1a2c 4578 6966 0000 4d4d 002a  .....,Exif..MM.*
00000010: 0000 0008 000b 010f 0002 0000 0006 0000  ................
          ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^
          |    |    |    |             TIFF header for the EXIF block:
          |    |    |    |             4D 4D = big-endian ("MM"), 00 2A = 42 (magic)
          |    |    |    "Exif\0\0" identifies the APP1 payload
          |    |    APP1 segment length = 0x1A2C bytes
          |    APP1 marker (FF E1): application metadata segment follows
          SOI marker (FF D8): Start Of Image — the JPEG begins here

Everything a carver needs to start a JPEG is in the first three bytes: FF D8 FF. The fourth byte (E1) tells you it's an Exif JPEG — almost certainly from a camera or smartphone, and therefore likely to carry GPS coordinates and a camera model inside that 1A2C-byte APP1 block (you will mine that metadata in Chapter 20 — Photo, Video, and Document Forensics). Now the end of the same file:

$ xxd -s -16 carved_000123.jpg          # the last 16 bytes
00200ff0: 7f3a 9c10 e8d4 a2b6 5e1f 00c3 d9a7 ffd9  .:......^.......
                                              ^^^^
                                              EOI marker (FF D9): End Of Image

The file ends with FF D9. A carver that found FF D8 FF at offset 0x00202000 of the disk image and then scanned forward to the next FF D9 would copy out exactly these bytes — a complete, valid JPEG — without ever consulting a file system. That is carving in its purest, happiest form.

PNG is even friendlier, because both ends are long and distinctive:

$ xxd -l 16 carved_000987.png
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
          ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^ ^^^^^^^^^
          8-byte PNG signature  length=13  "IHDR" (first chunk)

$ xxd -s -12 carved_000987.png
.... 0000 0000 4945 4e44 ae42 6082
               ^^^^^^^^^ ^^^^^^^^^
               "IEND"    CRC of the IEND chunk (always AE 42 60 82)

The PNG signature is a small work of engineering: the leading 89 byte has the high bit set (so a transfer that strips the 8th bit corrupts it detectably), 50 4E 47 spells "PNG", 0D 0A and 0A catch Windows/Unix line-ending mangling, and 1A is the old DOS end-of-file character. The footer, 49 45 4E 44 AE 42 60 82, is the IEND chunk with its fixed CRC — eight bytes that essentially never occur by accident. A PNG carver almost never makes a mistake at the boundaries.

Now a ZIP-based Office document, to show why "found a ZIP" is not the same as "found a DOCX":

$ xxd -l 30 carved_000045.docx
00000000: 504b 0304 1400 0600 0800 0000 2100 6234  PK..........!.b4
          ^^^^^^^^^ ^^^^ ^^^^ ^^^^
          PK\x03\x04 |    |    compression method 08 00 = DEFLATE
          local file |    general-purpose bit flag 06 00
          header     version needed 14 00 = 2.0

Those bytes — 50 4B 03 04 14 00 06 00 08 00 — are a textbook ZIP local file header. To know this particular ZIP is a Word document and not a spreadsheet or a generic archive, a smart carver continues a little further and reads the name of the first stored member; in a DOCX it is [Content_Types].xml, and the presence of word/document.xml later confirms it. A dumb carver just labels it .zip and moves on. We will see that this gap — between matching the signature and validating the structure — is the entire frontier of carving.

Recovery vs. Forensics. The same hex dump serves both disciplines, but you read it with different questions. The recovery engineer asks: Can I reconstruct usable bytes? If FF D8 FF ... FF D9 yields a JPEG that opens in an image viewer, the job is essentially done. The forensic examiner asks a second question the recovery engineer can skip: What can I prove about these bytes, and how do I document the process so it survives cross-examination? A carved JPEG has its internal EXIF (camera, maybe GPS, maybe an embedded creation timestamp) but no file-system metadata — no filename the user chose, no folder, no NTFS MACB timestamps, no owner. The examiner records the exact byte offset where the file began, the tool and version that carved it, and the SHA-256 of the carved output, so the recovery is reproducible and the chain of custody is intact. Same bytes; two standards of proof.

Three ways to carve

Given a header (and maybe a footer), there are three classic strategies. A good carving tool uses all three, choosing per file type.

   Raw bytes of unallocated space — the file system metadata is GONE
   |
   v
   ...7E A0 [FF D8 FF E1 ....EXIF.... ....image data.... FF D9] 3C 9B...
             ^^^^^^^^^^^^                               ^^^^^
             HEADER (JPEG SOI + APP1)                   FOOTER (EOI)
             |<---------------- carved file ------------->|
             start offset (e.g. 0x00202000)          end offset (+2 bytes)

   The carver copies bytes[start .. end+2] into a new file: carved_000123.jpg

Header-and-footer carving

This is the strategy in the diagram and the one you want whenever the format allows it. Find the header; scan forward to the next footer; carve everything between, inclusive. It works beautifully for JPEG (FF D8 FF ... FF D9), GIF (47 49 46 38 ... 00 3B), and PNG (89 50 4E 47... ... IEND CRC). When header-and-footer carving works on a contiguous, unfragmented file, the result is bit-for-bit identical to the original. That is the gold standard.

It has two failure modes even in the easy case. The first is the nested footer problem: many JPEGs contain a small embedded thumbnail that is itself a complete JPEG, with its own FF D8 FF and its own FF D9. A naive carver that grabs from the outer FF D8 FF to the first FF D9 it sees will stop at the thumbnail's ending and truncate the real photo. The second is the missing footer: if the file was partly overwritten, or the footer fell in a sector that's now reused, there is no FF D9 to find, and the carver either runs on forever or gives up. Both push you toward smarter strategies.

Header-and-maximum-size carving

For the many formats with no reliable footer — TIFF, MP4, OLE2 .doc, raw camera files — you carve from the header forward a fixed maximum size and accept that the tail of the carved file is junk (the bytes that happened to follow the real file on disk). You set the maximum generously enough to capture a whole file but not so generously that one runaway carve swallows the disk: a typical JPEG cap might be 20 MB, a PDF cap 50 MB, a video cap several hundred megabytes. The carved file is "too long" but usually still opens, because most viewers stop reading at the format's internal end marker and ignore trailing garbage. You trim later, or you let validation (below) compute the true length.

The maximum-size cap is also a safety valve. Without it, a header found just before a huge run of unstructured data — or a corrupt header with no matching footer — can make a carver try to write a single multi-gigabyte "file," filling your output disk. Every carving tool lets you set per-type size limits for exactly this reason, and tuning them is part of the craft.

Header-only carving

The crudest strategy: find the header, carve a fixed block, and hope the file is smaller than the block. You use this when you have nothing else — a format with a header but no footer and no usable internal length. It produces the most junk and the most truncations, and it is the strategy that gives carving its reputation for messy output. Treat it as a fallback.

Limitation. Notice what all three strategies silently assume: that the file's bytes are laid out contiguously on the disk, one sector after another from header to footer. That assumption is the soft underbelly of carving, and the next section is about what happens when it fails.

The fragmentation problem

Disks do not store files in neat, unbroken runs. As a volume fills and files are created, deleted, and grown, free space becomes scattered, and the file system places new files wherever it finds room — sometimes in several non-adjacent pieces. A file split across two or more disjoint regions is fragmented. The file system tracks the fragments in its metadata (the cluster runs in an $MFT record, the extent tree in an inode), so to the operating system the file looks whole. But carving has no metadata. It sees only raw bytes, and it assumes the bytes between a header and a footer all belong to the same file. When they don't, the carve fails.

CONTIGUOUS file (linear carving SUCCEEDS):
   [ H .............. file A's data .............. F ]
     ^header                                       ^footer
     -> one clean carve, byte-perfect

FRAGMENTED into two pieces with an intruding block (linear carving FAILS):
   [ H ... A part 1 ...][ ... B's data ... ][ ... A part 2 ... F ]
     ^header             ^a different file   ^A resumes        ^footer
     A naive carve copies H .......................... F
     -> includes B's bytes in the middle -> file A is corrupt and won't open

How often does this actually happen? The classic study is Simson Garfinkel's 2007 analysis of several hundred used drives bought on the secondhand market. He found that roughly 6% of files overall were fragmented — but the rate was far higher for exactly the file types investigators care about most. Around 16% of JPEGs, a similar share of Microsoft Word documents, and well over half of PST email stores were fragmented, largely because those files are big, are written and rewritten over time, or are appended to repeatedly. On a busy, nearly full drive — the kind people actually own — fragmentation is the rule for large files, not the exception. So the contiguity assumption that makes carving simple is also the thing that makes it fail most painfully on the most valuable evidence.

There is a partial answer for the most common case, two fragments separated by a gap: bifragment gap carving (also from Garfinkel's work). The idea is to find a header and a footer that probably belong together, then search the region between them for the gap — the run of intruding sectors that don't belong — by trying candidate split points and testing whether stitching the two halves produces a file that validates (decodes cleanly, passes a CRC, has a sensible internal length). It is computationally expensive and practical mainly for two fragments; three or more fragments in arbitrary order is, in the general case, a combinatorial nightmare that no production tool solves reliably. This is an honest limitation, not a tooling gap you can buy your way out of.

War Story. A recovery shop spent two days "recovering" a client's irreplaceable family videos from a reformatted SD card. The carver happily produced two hundred MP4 files. Every single one failed to play. The cause was fragmentation: the camera had written each long clip in several pieces, and the linear carve had spliced unrelated fragments together. The bytes were all present on the card — the recovery was theoretically possible — but the metadata that recorded the fragment order had been overwritten by the format, and without it the pieces could not be reassembled in the right sequence. The lesson the shop took away, and that you should too: carving recovers contiguous files well and fragmented files badly, and you must set client expectations before you start, not after.

Smart carving: validating internal structure

The way out of "produces a lot of junk" is to stop treating files as opaque blobs between a header and a footer and start understanding the format. This is variously called smart carving, semantic carving, or file-structure-based carving, and it rests on a simple insight from Garfinkel and others: every real file format carries enough internal structure to validate a candidate carve and often to compute its exact length.

Consider what the formats themselves tell you:

• PNG is a sequence of length-prefixed chunks, each ending in a CRC-32. A structure-aware carver reads IHDR, then walks chunk to chunk — each chunk header gives the chunk's exact length — until it reaches IEND. It never has to "search for a footer"; it arrives at the footer by following the format, and it can verify every chunk's CRC along the way. The carved length is exact, and corruption is detected immediately.
• ZIP / DOCX / XLSX end with an end-of-central-directory record (50 4B 05 06) that points back to a central directory listing every member with its offset and size. A smart carver reads that directory and knows precisely where the archive ends — and, as a bonus, can confirm it's an Office document by checking the member names.
• JPEG is a stream of marker segments. A structure-aware carver parses the markers (FF E0, FF DB, FF C0, FF DA start-of-scan, ...) and knows to skip over the embedded EXIF thumbnail rather than stopping at its FF D9 — solving the nested-footer truncation that defeats naive carving. It can even attempt to decode the Huffman-coded scan data to confirm the bytes really are a coherent image.
• MP4 / MOV is a tree of boxes (atoms), each prefixed with its own size. Following the box sizes gives the exact file length without any footer — if the critical moov box (which holds the playback index) is present and intact. When a camera writes moov at the end of the clip and that tail was overwritten, even a perfect structural carve yields a file that won't play, which is why video is the hardest common format to carve.

This is the principle Garfinkel called object validation: pair every candidate carve with a fast validator for that file type, and only keep carves that pass. Validation kills false positives (a random FF D8 FF that isn't really a JPEG fails to decode), repairs the nested-footer bug, computes exact lengths, and — combined with bifragment gap carving — lets a tool test whether a proposed reassembly of fragments is correct. The best free carver, PhotoRec, is built on exactly this idea: it carries format-specific knowledge for hundreds of file families and validates as it goes, which is why its output is dramatically cleaner than a pure signature scanner's.

Why This Matters. Smart carving is the fourth theme of this book in miniature: technology changes, principles don't. New formats arrive constantly — HEIC and AVIF photos, WebP images, Matroska video, the next compressed container — and each needs its own signature and its own validator. But the method never changes: identify the shape (header), understand the structure (validate and compute length), reassemble (handle fragmentation), and verify (the carved file decodes; its hash is recorded). Learn the method once and you can carve formats that did not exist when you learned it.

Recovery technique: getting the bytes back

For a data-recovery job, carving is gloriously pragmatic. The client's NTFS volume was reformatted; Chapter 6's logical recovery pulled back the files still referenced by surviving $MFT` records, but a chunk of the old `$MFT was overwritten by the new install and those files are unreachable by metadata. So you carve, and your posture is maximally inclusive: recover everything that might be a file, sort it out afterward.

The recovery workflow is short and aggressive:

1. Work from the image, never the original. You imaged the drive in Chapter 5's process; you verified the image's hash; the original is bagged and on the shelf. Every carve runs against the image (or a copy of it). The original is sacred even in pure recovery, because it is irreplaceable and because a second pass with better settings must start from the same untouched source.
2. Point a structure-aware carver at the whole image (or, better, at just the unallocated space — see the worked example) and let it run. PhotoRec is the default choice because its validation produces usable files instead of a haystack of junk.
3. Accept false positives and partials. In recovery you would rather over-recover than miss the one photo that mattered. Ten thousand thumbnails and browser-cache images are an acceptable price for the two hundred real family photos hiding among them.
4. Triage by what the content tells you. Carved files have no names, but images have dimensions and EXIF dates, documents have internal authorship and creation metadata, and you can sort and filter on those. The human work of recovery is mostly here: turning a flat pile of f0001234.jpg files into "the wedding, the kids' first birthdays, the trip to the coast."

That is the whole recovery game: carve broadly, validate to keep the output usable, then let a human (often with a lot of scripting) find the needles. The client does not care that the file is named f0148261.jpg instead of Anna_wedding_first_dance.jpg; they care that the first dance is there.

Forensic technique: carving as evidence

In an investigation, carving recovers deleted evidence that logical recovery cannot reach — pictures emptied from the Recycle Bin long ago, documents from a "wiped" partition, fragments in file slack and unallocated space — and that makes it indispensable. But a carved file is evidentially thinner than a logically recovered one, and you must understand exactly how, because opposing counsel will.

A carved file has no file-system metadata. That is not a tooling limitation; it is intrinsic. The filename, the folder path, the owner, and the NTFS creation/modification/access timestamps all lived in the $MFT` — the very structure that, by definition, is gone or unreliable when you resorted to carving. So a carved JPEG can establish that *this image content existed in the unallocated space of this drive*. It generally cannot, by itself, establish *when* the file was created, *who* created it, *what it was named*, or *which folder it sat in*. Those questions need other evidence: the file's own internal metadata (EXIF dates, document authorship — internal, so they survive carving), correlation with surviving `$MFT records or $LogFile`/`$UsnJrnl entries (Chapter 6 and Chapter 21 — Timeline Analysis), browser cache databases, or link-file and registry artifacts (Chapter 16).

What the forensic examiner adds to a carve, beyond the recovery engineer's work, is documentation that makes it reproducible and defensible:

• The source and its hash. The carve ran against image case001.dd, SHA-256 8f2a..., the same hash recorded at acquisition. The original is untouched; the chain of custody is intact.
• The exact tool, version, and configuration. "PhotoRec 7.1, default file-options, carving free space only," or "Scalpel 1.60 with the configuration shown below." Tools differ; versions differ; the carve must be repeatable by another examiner who can get the same files from the same image.
• The byte offset of every carved file. Where in the image did this file start? The offset is the closest thing a carved file has to a "location," and it lets another examiner confirm the carve and lets you map the file back to a partition and (sometimes) to surrounding artifacts.
• A hash of every carved output. SHA-256 each carved file so that the specific bytes you are introducing as evidence are fixed and verifiable.

This rigor is not bureaucratic theater; it is what lets a carved file survive a Daubert/Frye challenge to the method (the legal standards are detailed in Chapter 25 — The Legal Framework). Carving is a well-established, peer-reviewed, reproducible technique — but only if your application of it is documented well enough that a second examiner can reproduce your result from your source image. "I ran a tool and got some pictures" is not admissible; "I ran this tool, this version, this configuration, against this hash-verified image, and here are the offsets and the hashes of what I recovered, reproducibly" is.

Chain of Custody. Carving multiplies your evidence inventory: one image can yield tens of thousands of carved files. You cannot bag-and-tag each one as a physical exhibit, so the chain of custody attaches to the source image and the carved files are documented as derivative products of a recorded, reproducible process. Your report states the source image and its hash, the tool and configuration, and provides (or makes reproducible) the per-file offset-and-hash manifest. The principle from Chapter 5 holds: it is not enough to have the file; you must be able to prove where it came from and that it is unaltered.

Ethics Note. Carving is indiscriminate by nature — it pulls everything with a recognizable shape out of unallocated space, including material wholly unrelated to your authorized scope: other people's intimate photos, financial records, medical data, and, in the cases nobody wants but everyone in this field must be ready for, child sexual abuse material. You will encounter things you were not looking for. Two duties follow. First, scope discipline: your authority (warrant, consent, engagement letter) defines what you may search for and review; surfacing out-of-scope material during a broad carve can create legal problems for the whole case, and you handle it according to the rules in Chapter 25. Second, mandatory reporting: if you encounter apparent CSAM, U.S. providers and examiners have obligations (18 U.S.C. §2258A); you stop, preserve, and escalate through the proper channel — you do not investigate further on your own initiative. The full treatment of this duty, and of the examiner's own well-being when exposed to such material, lives in Chapter 28 — Ethics. It is raised here because carving is the single technique most likely to surface it.

Tool demonstration

Four tools cover almost everything you will do in practice: PhotoRec (validate-as-you-go recovery), Foremost and Scalpel (configurable signature carvers), and bulk_extractor (a feature scanner that complements carving). They overlap, and running more than one is good practice — agreement between independent tools corroborates a result. Full command syntax for all of these is in Appendix H — Command-Line Reference.

PhotoRec — validate-as-you-go recovery

PhotoRec, part of the TestDisk package by Christophe Grenier, is the carver to reach for first. It understands the internal structure of hundreds of file families and validates as it carves, so its output is far cleaner than a raw signature scan. It is an interactive (ncurses) tool, but it can also be driven from the command line for repeatable, documentable runs. Interactively, it walks you through selecting the source, the partition, the file-system family, whether to scan whole space or free space only, and the destination:

PhotoRec 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>

Disk /dev/sdb - 500 GB / 465 GiB (RO)        <-- read-only: the source is protected
     Partition                  Start        End    Size in sectors
   P NTFS                    0  32 33  60799 81 17  976771072 [Data]

>[ Search ]  [ Options ]  [ File Opt ]  [ Quit ]
   Free:  scan only unallocated space (faster, avoids re-carving live files)
   Whole: scan the entire partition

Pass 1 - Reading sector  524288/976771072, 1843 files found
Elapsed 0h06m12s - Estimated time to completion 2h41m
   jpg: 18234 recovered
   mov:   412 recovered
   pdf:  1203 recovered
   docx:  311 recovered
   png:   942 recovered

PhotoRec writes its output into directories named recup_dir.1, recup_dir.2, and so on (each holds up to a few hundred files), with files named by recovered-file number and type — f0148261.jpg, f0150003.mov — plus a report.xml. To make a run scriptable and self-documenting for a report, drive it non-interactively:

# Scriptable PhotoRec run against an image, free space only, all file types
photorec /log /d /cases/wedding/recup_dir \
         /cmd /cases/wedding/unalloc.dd \
         partition_none,fileopt,everything,enable,freespace,search
#  /log        -> writes photorec.log (keep it for your report)
#  /d DIR      -> destination for carved files (recup_dir.N)
#  fileopt,everything,enable -> turn on every known file family
#  freespace   -> carve unallocated space only

Tool Tip. PhotoRec's "File Opt" menu lets you disable file families you don't want. On a photo-recovery job, turn off everything except jpg, png, tif, heic, mov, and mp4. The run finishes far faster and you don't have to wade through forty thousand carved .html and .txt fragments from the browser cache. Selecting only the formats you need is the single biggest time-saver in carving.

Foremost — the classic configurable carver

Foremost, originally written by Jesse Kornblum and Kris Kendall of the U.S. Air Force Office of Special Investigations, is a straightforward signature carver with built-in definitions for common types (-t) and a configuration file for custom ones. It is a fine corroborating second tool:

foremost -t jpg,png,pdf,doc,zip,mov -i unalloc.dd -o foremost_out

It writes one subdirectory per type (foremost_out/jpg/, .../pdf/, ...) and an audit.txt that is exactly the kind of artifact you paste into a report — it records the tool version, the exact invocation, the configuration file, and every carved file with its size and byte offset:

Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sun Jun 28 10:14:22 2026
Invocation: foremost -t jpg,png,pdf,doc,zip,mov -i unalloc.dd -o foremost_out
Output directory: /cases/wedding/foremost_out
Configuration file: /etc/foremost.conf

File: unalloc.dd
Start: Sun Jun 28 10:14:22 2026
Length: 30 GB (32212254720 bytes)

Num      Name (bs=512)        Size       File Offset      Comment
0:       00000016.jpg          2 MB              8192
1:       00004128.jpg        518 KB           2113536
2:       00010044.jpg        1 MB             5142528
...
24186:   62910784.mov        88 MB        32210321408

Finish: Sun Jun 28 10:41:07 2026

24187 FILES EXTRACTED

jpg:= 23004
png:=   388
pdf:=   712
doc:=    71
zip:=    12
mov:=     0          <-- note: no usable MOV carved (see "moov atom" limitation)
------------------------------------------------------------------
Foremost finished at Sun Jun 28 10:41:07 2026

The foremost.conf configuration file documents one signature per line, in the format extension case-sensitive max-size header [footer]:

# foremost.conf  --  extension  case  max-size   header              footer
  gif   y   5000000     \x47\x49\x46\x38\x37\x61   \x00\x3b
  gif   y   5000000     \x47\x49\x46\x38\x39\x61   \x00\x3b
  jpg   y   20000000    \xff\xd8\xff\xe0\x00\x10   \xff\xd9
  jpg   y   20000000    \xff\xd8\xff\xe1           \xff\xd9
  png   y   20000000    \x89\x50\x4e\x47\x0d\x0a\x1a\x0a   \x49\x45\x4e\x44\xae\x42\x60\x82
  pdf   y   50000000    \x25\x50\x44\x46           \x25\x25\x45\x4f\x46

Scalpel — fast, header/footer, configuration-driven

Scalpel, written by Golden G. Richard III as a faster re-engineering of an early Foremost, is configured entirely through scalpel.conf. Its line format adds a REVERSE option that makes the footer search find the last occurrence of the footer in the carve window — exactly what you want for formats like PDF and ZIP that can contain several footer-like sequences and whose real end is the final one:

# scalpel.conf   ext  case  max-size    header                  footer            [REVERSE]
  jpg   y   20000000   \xff\xd8\xff\xe0\x00\x10   \xff\xd9
  jpg   y   20000000   \xff\xd8\xff\xe1           \xff\xd9
  png   y   20000000   \x89\x50\x4e\x47\x0d\x0a\x1a\x0a   \x49\x45\x4e\x44\xae\x42\x60\x82
  gif   y    5000000   \x47\x49\x46\x38\x39\x61   \x00\x3b
  pdf   y   50000000   %PDF                       %%EOF\x0d   REVERSE
  pdf   y   50000000   %PDF                       %%EOF\x0a   REVERSE
  zip   y   50000000   \x50\x4b\x03\x04           \x50\x4b\x05\x06   REVERSE

scalpel -c scalpel.conf -o scalpel_out unalloc.dd

Scalpel version 1.60
Written by Golden G. Richard III, based on Foremost 0.69.

Opening target "/cases/wedding/unalloc.dd"

Image file pass 1/2.
unalloc.dd: 100.0% |***************************************|  30.0 GB    0.0 b/s
Allocating work queues...
Building carve lists...
Carving files from image.
Image file pass 2/2.
unalloc.dd: 100.0% |***************************************|  30.0 GB    0.0 b/s

Processing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 23792, elapsed = 1184 seconds.

Scalpel writes per-rule subdirectories (scalpel_out/jpg-1-0/, .../pdf-4-0/) and its own audit.txt. It works in two passes — first it builds the list of headers/footers, then it carves — which makes it fast but memory-hungry on large images. (Both Scalpel and Foremost are pure signature carvers with no internal validation, which is why their output is messier than PhotoRec's; their value is as fast, transparent, configurable corroborators whose every signature you can see and cite.)

bulk_extractor — features, not whole files

bulk_extractor, by Simson Garfinkel, is not a traditional file carver and that is exactly why it belongs in your kit. Instead of reconstructing whole files, it scans every byte of the image — ignoring the file system, recursively decompressing ZIP and GZIP streams as it goes — and extracts features: email addresses, URLs, domain names, credit-card numbers (validated with the Luhn checksum), phone numbers, EXIF metadata, and GPS coordinates. It is heavily parallelized and runs in one pass:

bulk_extractor -o bulk_out unalloc.dd

bulk_extractor version: 2.0.0
Input file: unalloc.dd
Output directory: bulk_out
Disk Size: 32212254720
Threads: 8

Phase 1: Counting/offset scan
14:03:55  Offset 1073MB (3.33%)  Done in  0:42:10 at 14:46:05
...
Phase 2: Shutting down scanners
Phase 3: Creating Histograms
   ... email_histogram.txt url_histogram.txt domain_histogram.txt
All Done.

Its output is a directory of tab-separated feature files — email.txt, url.txt, domain.txt, ccn.txt, telephone.txt, exif.txt, gps.txt — plus a histogram for each (so you instantly see the most common email address or domain), and a report.xml. Each feature line is offset <TAB> feature <TAB> context:

# bulk_out/email.txt
# BULK_EXTRACTOR-Version: 2.0.0
# Feature-Recorder: email
# Filename: unalloc.dd
2113984    photographer@studiolens.com    n John <photographer@studiolens.com> wrote
2114560    bride2024@gmail.com            To: bride2024@gmail.com\x0d\x0aSubject: pro

# bulk_out/email_histogram.txt
n=412   bride2024@gmail.com
n=88    photographer@studiolens.com

Two things make bulk_extractor special for forensics. First, it finds features in fragments that could never be carved as whole files — an email address sitting in 200 bytes of unallocated space, with no header or footer around it, surfaces in email.txt even though no file can be reconstructed there. Every action leaves a trace, and bulk_extractor finds the traces too small to be files. Second, its EXIF scanner pulls camera metadata and GPS coordinates out of partial JPEGs that a normal carver would reject as un-decodable — so you can sometimes recover where and when a photo was taken even when you cannot recover the photo. (It even has scanners for AES key schedules in memory images, which becomes relevant in Chapter 29 — Encrypted Device Forensics.) When it reports an offset inside a decompressed stream, it uses a forensic path such as 1048576-ZIP-3413, meaning "at offset 1,048,576 there is a ZIP; decompress it; the feature is at offset 3,413 inside." That path is reproducible and citable.

A minimal carver, to demystify the magic

You do not need a tool to carve a JPEG; you need a header, a footer, and ten lines of code. The point of writing one yourself is to internalize what every carver does — and to feel, first-hand, why naive carving fails. This is illustrative only; never run it against evidence (use validated tools for that), and note the deliberate bug discussed below.

#!/usr/bin/env python3
"""Minimal header/footer JPEG carver -- ILLUSTRATIVE, not for casework.
Scans a raw image for JPEG SOI (FF D8 FF) ... EOI (FF D9) and writes each
candidate to its own file. Demonstrates the technique AND its failure modes."""
import sys

SOI = b"\xff\xd8\xff"          # Start Of Image + first marker (the header)
EOI = b"\xff\xd9"              # End Of Image (the footer)
MAX_LEN = 30 * 1024 * 1024     # sanity cap: never carve more than 30 MB at once

def carve_jpegs(image_path, out_dir):
    with open(image_path, "rb") as f:
        data = f.read()        # fine for teaching; real tools STREAM, not slurp
    count, pos = 0, 0
    while True:
        start = data.find(SOI, pos)
        if start == -1:
            break              # no more headers
        end = data.find(EOI, start + 3)
        if end == -1 or (end - start) > MAX_LEN:
            pos = start + 3    # no footer in range -> skip this header
            continue
        end += 2               # include the 2-byte EOI marker
        carved = data[start:end]
        name = f"{out_dir}/carved_{count:06d}_off{start}.jpg"
        with open(name, "wb") as out:
            out.write(carved)
        print(f"[{count:05d}] offset={start:<12} size={len(carved):<9} -> {name}")
        count += 1
        pos = end              # continue scanning after this carve
    print(f"Done. {count} candidate JPEGs carved.")

if __name__ == "__main__":
    carve_jpegs(sys.argv[1], sys.argv[2])   # usage: carver.py image.dd out_dir/

This works on simple, contiguous, thumbnail-free JPEGs — and fails exactly where you now expect. It stops at the first FF D9, so any photo containing an EXIF thumbnail (almost every phone photo) gets truncated at the thumbnail's end marker. It assumes contiguity, so fragmented files come out corrupt. It reads the whole image into memory, which is impossible for a real 500 GB image. And it has no validation, so every stray FF D8 FF that isn't really a JPEG becomes a junk file. Fixing all four — parse markers instead of searching for FF D9, handle fragments, stream the input, validate the output — is, essentially, the difference between this toy and PhotoRec. A reusable, better-behaved version lives in Appendix B — Python Forensics Toolkit.

Finally, the forensic housekeeping you do after any carve — hash everything, confirm signatures — is easy to script. On Windows:

# Hash every carved file for the evidence manifest (reproducibility + integrity)
Get-ChildItem -Recurse -File .\recup_dir.* |
  ForEach-Object {
      $h = Get-FileHash -Algorithm SHA256 $_.FullName
      [PSCustomObject]@{
          File   = $_.Name
          Bytes  = $_.Length
          SHA256 = $h.Hash
      }
  } | Export-Csv -NoTypeInformation .\carved_manifest.csv

# Confirm a carved file really starts with the JPEG signature FF D8 FF
Format-Hex -Path .\recup_dir.1\f0148261.jpg -Count 4

Worked example: carving the wedding photos

Return to the anchor case. A client brought in a 500 GB external drive holding roughly ten years of family photos and video. In a moment of confusion she had quick-reformatted it (NTFS to NTFS) thinking it was a different, empty drive, and used it for about a day — copying perhaps 30 GB of new work files onto it — before realizing what she'd done. She stopped immediately and brought it in. In Chapter 6 you did the metadata-driven recovery: the quick format wrote a new, small $MFT`, but much of the *old* `$MFT survived in clusters the new file system had not yet reused, and from those surviving deleted records you recovered a large fraction of the photos with their original names and timestamps intact. That was the good part of the news.

The bad part is the regions where the new $MFT` and the 30 GB of new files landed on top of the old metadata. There, the old `$MFT records are gone — overwritten — and logical recovery has nothing to read. The photo data in those regions, though, is mostly still present (30 GB of new data cannot overwrite 470 GB of old data), sitting in unallocated clusters with no metadata pointing to it. That is the carving stage of the wedding-photos case: recover by content what can no longer be recovered by map.

You start, as always, from the verified image — the original drive is back in its antistatic bag on the shelf. The original is sacred; you will not carve a fingerprint of work onto the only copy of someone's life:

# 1. Confirm the working image still matches the acquisition hash (Chapter 5)
sha256sum wedding_500gb.dd
#   8f2a3c9e...   wedding_500gb.dd     <-- must equal the value in the intake log

# 2. Extract ONLY the unallocated blocks, so we don't re-carve the live files
#    that logical recovery already handled (Sleuth Kit's blkls)
blkls wedding_500gb.dd > unalloc.dd

# 3. Carve the unallocated space with a structure-aware tool, photos only
photorec /log /d /cases/wedding/recup_dir /cmd unalloc.dd \
         partition_none,fileopt,jpg,enable,heic,enable,mov,enable,everything,disable,search

# 4. Corroborate with an independent signature carver
foremost -t jpg,png,mov -i unalloc.dd -o foremost_out

Carving the ~30 GB of recovered unallocated space yields a flood: PhotoRec reports about 24,000 JPEGs. That number is shocking until you remember what lives in unallocated space — not just the user's real photos, but every thumbnail Windows ever cached, every image the browser downloaded, every duplicate, and the EXIF thumbnails that PhotoRec correctly separates from their parent images. Of those 24,000 carved files, perhaps a few thousand are full-resolution photographs the client actually took, and of those, a couple hundred are the ones that matter: the wedding, the kids' first steps, the grandparents who have since passed.

This is where carving stops being a technical problem and becomes a human one. The client does not want 24,000 anonymous f-number.jpg files; she wants her photographs, and she wants the wedding first. So you triage by the only context a carved file carries — its own internal content:

# Triage carved JPEGs by their internal EXIF date + resolution.
# Goal: separate the client's real, full-size photos from thumbnails/cache,
# and sort them by when they were actually taken. (illustrative)
import glob, os
from PIL import Image
from PIL.ExifTags import TAGS

def photo_info(path):
    try:
        img = Image.open(path)
        w, h = img.size
        dt = None
        raw = img._getexif() or {}
        for tag, val in raw.items():
            if TAGS.get(tag) == "DateTimeOriginal":
                dt = val          # "2016:07:23 15:42:10" -> the day of the wedding
        return (w * h, dt, path)
    except Exception:
        return None               # not a valid image -> a false-positive carve

photos = [p for p in (photo_info(f)
          for f in glob.glob("/cases/wedding/recup_dir/recup_dir.*/*.jpg"))
          if p and p[0] >= 1_000_000]        # drop tiny thumbnails (< ~1 MP)

photos.sort(key=lambda x: (x[1] or "0000"))  # order by DateTimeOriginal
print(f"{len(photos)} full-resolution photographs, sorted by capture date")
for area, dt, path in photos[:10]:
    print(f"  {dt}  {area//1_000_000} MP  {os.path.basename(path)}")

Filtering to images of at least a megapixel collapses 24,000 carves to a few thousand real photographs; sorting by DateTimeOriginal puts the wedding day's cluster of frames together; and from there the client herself picks the ones she wants. The EXIF dates survived because they are internal to the JPEG — the file system that held the "date modified" is gone, but the camera's own record of when it pressed the shutter rode along inside the file and came through the carve intact. That is the recurring lesson of carving in one sentence: you lose the context the file system held, but you keep the context the file holds about itself.

War Story. On this exact kind of job, the videos were the heartbreak. The still photos carved beautifully — most were small enough to be contiguous, and PhotoRec validated them cleanly. The wedding video, a single 12-minute 4K clip, came out as a 3 GB file that would not play. The camera had written the moov index atom at the end of the recording, and that tail had landed in a region the client's 30 GB of new work files overwrote. Every byte of the actual video frames was still on the drive; the index that explained how to play them was gone. We recovered 2,300 photographs and lost the one video — and explaining that asymmetry to a crying client ("the pictures are back, the wedding video is not, and no, paying more won't change physics") is the part of this job no tool prepares you for. The human cost is real, and honesty about limitations is part of the service.

Recovery vs. Forensics. Notice how the same carved photo would be handled if this were a custody dispute instead of a recovery job. For recovery, the EXIF date is a convenience for sorting. For forensics, that EXIF DateTimeOriginal and any embedded GPS become evidence — but evidence you must corroborate, because EXIF can be edited and a carved file has no file-system timestamp to cross-check against. You would hash each carved photo, record its offset in the image, note the tool and version, and in your report state plainly that the capture date rests on internal metadata that can be altered, pending correlation with other artifacts. Same carve; in one world it's a sorting key, in the other it's a fact you may have to defend on the stand.

Common mistakes

• Carving the original instead of an image. The fastest way to destroy what you're trying to save is to write carved output — or anything else — onto the source media. Carve from a hash-verified image, ideally a working copy of it, with the original write-blocked or shelved. This is non-negotiable in both recovery and forensics.
• Carving the whole volume when you only needed unallocated space. Carving allocated regions re-recovers files the file system can already give you (with their names and dates), wastes hours, and buries the actually deleted files in duplicates. Extract unallocated space first (blkls, or your tool's "free space only" mode) and carve that.
• Trusting a single tool's output as complete. PhotoRec, Foremost, Scalpel, and bulk_extractor have different signatures, validators, and blind spots. A type one tool misses, another catches; agreement between two corroborates a result. Run more than one, especially in casework.
• Stopping at the first footer (the thumbnail-truncation bug). Naive header-to-first-footer carving truncates JPEGs at their embedded EXIF thumbnail and PDFs at an early %%EOF. Use structure-aware tools (PhotoRec) or REVERSE-style "last footer" logic (Scalpel) so you find the file's end, not the first matching bytes.
• Setting maximum carve sizes carelessly. Too small and you truncate large legitimate files; too large and one bad header tries to write a multi-gigabyte "file" that fills your output disk. Tune per type, and watch your free space during long runs.
• Treating short signatures as reliable. Two-byte headers like BMP (42 4D) and three-byte ones collide constantly with random data; they produce floods of false positives. Validate, prefer longer/more-specific signatures, and align header searches to sector or cluster boundaries where the tool allows it (real file headers almost always sit on a cluster boundary).
• Reporting carved files as if they had file-system metadata. A carved file has no original name, path, owner, or NTFS timestamp — those died with the metadata. Inventing or implying them ("recovered file wedding.jpg created 2016-07-23") is a serious error that opposing counsel will exploit. Report what carving actually establishes: content present at a given offset, recovered by a documented method, with internal metadata noted as internal.
• Forgetting to hash the carved output. In forensics, an evidence file with no recorded hash is an evidence file whose integrity you cannot prove. Hash every carve you intend to rely on.

Limitations: knowing when to stop

Carving is powerful, but its limits are hard, and a professional states them up front rather than discovering them after burning a client's money or an investigation's credibility. The fifth theme of this book — know your limitations — applies to no technique more sharply than carving.

Fragmentation defeats linear carving. This is the big one, covered above: any file stored in non-adjacent pieces will, with linear carving, come out spliced with unrelated data and corrupt. Bifragment gap carving rescues some two-fragment cases at high computational cost; three-or-more-fragment files in arbitrary order are, in general, not reliably reassemblable by content alone. Large files — video, big PSTs, disk images within the image — are exactly the ones most likely to be fragmented and least likely to carve.

Files without distinctive headers cannot be carved. Plain text, CSV, many log formats, and proprietary blobs have no magic number — no shape to recognize — so signature carving simply cannot find them. (Feature scanning with bulk_extractor can still pull content like email addresses and URLs out of such regions, which is part of why it complements carving rather than competing with it.)

Compressed and encrypted data looks like noise. A carver scans for structure, and well-compressed or encrypted bytes have no externally visible structure. A photo inside a password-protected ZIP, a document in an encrypted container, the contents of a BitLocker volume — none of it presents a carve-able signature until it is decompressed or decrypted. Encryption, in particular, is where carving (and recovery generally) hits a wall that is mathematical, not procedural; Chapter 29 takes that up.

False positives are inherent. Every signature occasionally appears by chance in unrelated data, and short signatures appear constantly. Validation suppresses most false positives but not all; you will always sift some junk out of carved output. This is a cost you manage, not a bug you eliminate.

Carved files have no file-system context. No name, no path, no owner, no MACB timestamps — by definition, because you carve precisely when that metadata is gone. Carving proves content existed on the media; it does not, by itself, prove when, who, or where.

Overwritten data is gone — deleted is not destroyed, but overwritten is. Carving recovers data that persists in unallocated space; it cannot recover bytes that new data has physically replaced. In the wedding case, the 30 GB of new files overwrote some old data permanently, and no tool brings that back. The same applies, even more absolutely, to securely wiped regions.

On SSDs, TRIM may have already erased unallocated space. This is the limitation that surprises people coming from the hard-drive world. On most modern SSDs, when the operating system deletes a file the file system issues a TRIM command, and the drive's controller proactively zeroes those blocks in the background — often within seconds. Carve the unallocated space of a TRIM-enabled SSD after a delete and you may find nothing, because there is nothing left to find. The full mechanics, and the narrow conditions under which SSD recovery is still possible, are the subject of Chapter 9 — SSD and Flash Recovery. For now, internalize the asymmetry: the carving techniques of this chapter assume hard-drive-style persistence, and that assumption is exactly what TRIM breaks.

Knowing when to stop is itself a skill. If two structure-aware tools, run against properly extracted unallocated space, with the right file types enabled, return nothing usable for the file you need — and the media is a TRIM'd SSD, or the region was overwritten, or the file is fragmented beyond reassembly — then the honest professional finding is "the data is not recoverable from this media by carving," not another week of billable hours. In forensics the equivalent statement, "the evidence is insufficient to reach a conclusion," is a complete and respectable result.

Legal Note. Two legal points ride along with carving. First, scope. A broad carve of an entire image surfaces everything in unallocated space, including material outside the authority that let you examine the media in the first place. What you may search for and review is bounded by your warrant, consent, or engagement; how you handle responsive-but-out-of-scope and plainly contraband material is governed by the rules in Chapter 25. Second, authentication. Because a carved file lacks file-system metadata, authenticating it under evidentiary rules (showing it is what you claim) leans on the documented carving method, the source-image hash, the offset, and corroborating internal or external evidence — not on a filename or a path, which the carve did not preserve.

Progressive project: carving the case image's unallocated space

Time to advance your Forensic Case File. In Chapter 5 you acquired and hash-verified the case image; in Chapter 6 you recovered deleted files that the file system still partly described. Now you will recover what the file system can no longer describe at all — by carving the unallocated space — and, crucially, document it to the forensic standard so it can join the case file as defensible evidence.

1. Verify the source. Recompute the SHA-256 of your working image and confirm it matches the acquisition record from Chapter 5. Note the result in your examiner's log. (If it doesn't match, stop — you have an integrity problem to resolve before anything else.)
2. Isolate unallocated space. Run blkls case001.dd > case001_unalloc.dd (Sleuth Kit) to extract only the unallocated blocks, so you carve deleted content rather than re-carving live files. Record the size of the extracted unallocated region.
3. Carve with a structure-aware tool. Run PhotoRec against case001_unalloc.dd with the /log option, output to a clearly named directory. Capture the photorec.log and the per-type counts.
4. Corroborate with a signature carver. Run Foremost (or Scalpel) against the same unallocated image. Save the audit.txt. Compare the type counts to PhotoRec's and note any file types one tool found and the other missed.
5. Feature-scan for context. Run bulk_extractor -o be_out case001_unalloc.dd and review email.txt, url.txt, and exif.txt (and their histograms). These features give your carved files context the carve itself cannot — an email address or a URL near a carved document can connect it to a person or an event. Save the feature files.
6. Build the carved-evidence manifest. For every carved file you intend to rely on, record its byte offset (from the tool's audit/log), its size, and its SHA-256. The PowerShell snippet above produces this as a CSV; keep it with the case file.
7. Write the limitation note. In your case file, add a short, explicit statement that carved files lack file-system metadata (no original name, path, owner, or MACB timestamps), that any dates shown derive from internal metadata which can be altered, and that the recovery is reproducible from the named source image, tool, version, and configuration. This note is what makes your carved evidence survive scrutiny.

When you finish, your case file contains a documented, reproducible carve of the image's unallocated space, corroborated across tools, with a feature-context scan and an integrity-verified manifest — and an honest statement of what the carved files do and do not prove. You will fold all of this into the complete investigation in Chapter 38 — The Capstone Investigation.

Try This. Make your own ground-truth practice image so you can see carving's behavior with the answers known. Format a small USB stick (or a disk image) as FAT32, copy on a dozen photos of varied sizes plus a multi-page PDF and a long video, then delete them and reformat. Image the stick, run blkls and PhotoRec, and compare the carved output to the originals you still have: which came back byte-perfect (hash-match the carves against the originals), which got truncated, which video failed for lack of its index. There is no faster way to build carving intuition than carving files whose true contents you already know. The practice images and public test corpora in Appendix J — Practice Images and Lab Setup let you do the same at larger scale.

Summary

When the file system's map is destroyed — reformatted, repartitioned, overwritten, corrupted — the techniques of Chapter 6 run out of metadata to read, but the data itself persists in the raw sectors. File carving recovers that data by its content rather than its metadata: it scans the bytes for the signatures (magic numbers) that mark the start of known file types — FF D8 FF for JPEG, 89 50 4E 47... for PNG, 50 4B 03 04 for ZIP and the Office documents built on it, 25 50 44 46 for PDF, ftyp at offset 4 for MP4 — and, where the format provides one, the footer that marks the end (FF D9, the IEND chunk, %%EOF). From a header and a footer you carve a file out of undifferentiated data with no file system involved at all. The three classic strategies — header-and-footer, header-and-maximum-size, and header-only — handle progressively harder formats, and smart carving improves on all of them by understanding file structure: following PNG chunks and their CRCs, reading a ZIP's central directory, parsing JPEG markers to skip the embedded thumbnail, and validating every candidate so that false positives and truncations fall away. Carving's hard limits are honest and worth stating before you start: fragmentation corrupts linearly carved files; headerless, compressed, and encrypted data cannot be carved; overwritten data is truly gone; and on TRIM-enabled SSDs the unallocated space you would carve may already be zeroed. Tooling spans PhotoRec (validate-as-you-go, the default), Foremost and Scalpel (fast, transparent, configuration-driven signature carvers), and bulk_extractor (a feature scanner that finds content too fragmentary to be a file). The dual-discipline lens runs through all of it: for recovery, carving means pulling a client's wedding photos out of a reformatted drive and triaging 24,000 carves down to the few hundred that matter, accepting that the names and folders are gone as long as the pictures come back; for forensics, the same carve must be documented to a reproducible standard — source-image hash, tool and version, byte offsets, and per-file hashes — because a carved file proves that content existed on the media but, lacking all file-system metadata, cannot by itself prove when, who, or where. That distinction, more than any signature table, is what separates getting the bytes back from proving what happened.

You can now: - Explain why files remain recoverable after a format or partition loss, and how carving recovers them by content when file-system metadata is gone. - Recognize the major file signatures (headers and footers) in a hex dump and choose header-and-footer, header-and-maximum-size, or header-only carving appropriately. - Describe why fragmentation, headerless/compressed/encrypted data, overwriting, and SSD TRIM limit carving, and articulate when to stop. - Run and corroborate carves with PhotoRec, Foremost, Scalpel, and bulk_extractor, including writing and reading a scalpel.conf/foremost.conf and interpreting an audit.txt. - Document a carve to forensic standard — source hash, tool/version/config, offsets, per-file hashes — and state honestly what a carved file does and does not prove. - Triage thousands of carved files down to the ones that matter using internal metadata (EXIF dates, dimensions, document authorship).

What's next. Chapter 8 — Hard Drive Recovery — moves from logical destruction to physical failure: what to do when the drive itself is the problem. You'll learn to read the click of a failed head, decide when a drive belongs in a clean room and when it never should be powered on again, and understand the imaging-the-dying-patient techniques (ddrescue, head maps, donor parts) that get bytes off failing hardware so that the logical and carving techniques of these last two chapters even have an image to work on.

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.