44 min read

> Where you are: Part II, Chapter 6 of 40. Part I gave you the foundations: how data is stored as bits, sectors, and clusters (Chapter 2), the physical media that hold it (Chapter 3), the file systems that organize it (Chapter 4), and the...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 6: Logical Recovery — Deleted Files, Formatted Drives, and Corrupted Partitions

Where you are: Part II, Chapter 6 of 40. Part I gave you the foundations: how data is stored as bits, sectors, and clusters (Chapter 2), the physical media that hold it (Chapter 3), the file systems that organize it (Chapter 4), and the disciplined forensic process that protects it (Chapter 5). This chapter is where you finally get data back. It covers the single most common recovery scenario you will ever meet — the data is physically intact but logically inaccessible — and it works the book's first anchor case, the deleted wedding photos, from intake to delivery.

Learning paths: This is a core chapter for everyone. 💾 Data Recovery technicians live here: deleted-file, formatted-drive, and lost-partition recovery are the bread and butter of the trade. 🔍 Forensic Examiners must understand the same mechanics from the other side — recovering deleted files for evidence, defensibly, without altering the original. 🛡️ Incident Responders recover deleted logs, scripts, and staged data that an intruder tried to erase. 📜 Legal/eDiscovery professionals need to know what "deleted" really means so they can advise on preservation, spoliation, and what is realistically recoverable.

The most common case: intact data, broken signposts

A client sets a 1-terabyte external drive on your bench. It holds — held — ten years of family photographs: a wedding, two births, holidays, the ordinary irreplaceable record of a life. Two days ago the client connected it to a new laptop, clicked through a Windows dialog they did not fully read, and the drive was reformatted. Now it shows up as empty. They have no other copy.

Here is the thing that matters most, and it is the foundation of this entire discipline: almost certainly, every one of those photographs is still on that drive, byte for byte, exactly as it was. The format did not erase the pictures. It erased the index to the pictures. The data is intact; the signposts that point to it are broken. Recovering it is largely a matter of rebuilding or bypassing those signposts.

This is logical recovery: getting data back when the storage device works perfectly but the logical structures — the partition table, the file system, the directory entries — are damaged, deleted, or overwritten. It stands in contrast to physical recovery (Chapters 8 and 9), where the device itself has failed: a seized spindle, a cracked read/write head, a dead controller, worn-out NAND. Logical problems are far more common than physical ones, and they are the kind you can solve at a desk with software, a write-blocker, and patience. No clean room required.

To understand why logical recovery works so well, recall the central insight from Chapter 2, the one that underwrites both halves of this book: deletion removes the pointer, not the data. When you "delete" a file, the operating system does not march out to the platters and scrub the bytes. That would be slow and pointless. Instead it does the cheap thing: it edits a small bookkeeping structure to say "this space is available now" and moves on. The file's actual content sits untouched in its clusters until something else happens to be written there. The same is true, on a larger scale, when you format a volume or lose a partition. The bookkeeping changes; the bulk data does not.

Why This Matters. The gap between "the system says it's gone" and "the bytes are still there" is the entire opportunity space of data recovery — and the entire risk space of digital forensics. A user who believes a file is destroyed will speak and act freely; the examiner who knows it persists can often prove what happened. Deleted is not destroyed. Internalize that sentence. Everything in Part II and Part III grows from it.

Logical versus physical: deciding which problem you have

Before you touch anything, you need to know which kind of problem is in front of you, because the wrong move on a physical failure can turn a recoverable drive into a dead one. The decision flow looks like this:

                 Can the device be read at all?
                 (does it spin up / enumerate / respond?)
                          │
            no ───────────┴──────────── yes
            │                            │
            ▼                            ▼
   PHYSICAL recovery            Does it read RELIABLY,
   (Ch.8 HDD / Ch.9 SSD):       without clicking, stalling,
   clean room, head swap,       or growing reallocated-sector
   PCB repair, chip-off.        counts (SMART)?
   STOP using software.         │
                       no ──────┴────── yes
                       │                │
                       ▼                ▼
              Image with ddrescue   IMAGE the device (always).
              FIRST, gently, then   Work only on the copy.
              treat the IMAGE as          │
              a logical problem.          ▼
                                  Partition table intact?
                                   │ no → rebuild it (TestDisk)
                                   │ yes
                                   ▼
                                  File system intact?
                                   │ no (formatted/corrupt) →
                                   │    find residual FS structures,
                                   │    then carve (Ch.7)
                                   │ yes
                                   ▼
                                  Files merely deleted?
                                   │ yes → undelete from FS metadata
                                   │       (MFT / inode / dir entry)
                                   │ metadata gone → carve (Ch.7)

The single most important branch is the first one. A drive that clicks, that disappears and reappears in the device list, that throws read errors, or whose SMART data shows climbing reallocated-sector or pending-sector counts is a physical problem wearing a logical disguise. Every read you perform on a dying drive may be one of the last it will ever give you. If you suspect physical failure, do not run recovery software against the original — image it gently with a tool built for failing media (GNU ddrescue, covered in Chapter 8) and then perform logical recovery on the resulting image. For the rest of this chapter we assume the device reads reliably, which is the common case.

Image first — yes, even for recovery

In forensics, imaging the original before you analyze it is non-negotiable because the law demands it: the copy is what makes your findings admissible (Chapter 5, deepened in Chapter 14). But here is a point new technicians often miss: you image first in pure data recovery too, even when no court will ever see the work, and even when you are in a hurry to give a relieved client good news. The reasons are different but no less compelling:

  • The original is irreplaceable. That is the whole premise of the job. If your recovery attempt makes things worse — and many do — you want to make it worse on a copy you can discard, then start over from a clean image. You can re-acquire a copy from a good image a thousand times; you cannot un-write a clobbered original.
  • Recovery tools write. Some recovery and "repair" tools modify the source by default. chkdsk /f, fsck, partition-table "fixers," and even the act of mounting a volume read-write can permanently destroy recoverable data by reusing freed space, replaying a journal, or rewriting metadata. On an image, nothing you do can reach back and harm the original.
  • The device may be weaker than it looks. A drive that seems healthy can fail mid-recovery. Capture the data once, completely, while you can; then take your time on the copy.
  • Unlimited retries. Carving, undelete, and partition rebuilds are iterative. You will run them, get partial results, adjust parameters, and run again. Doing that against an image is fast and safe; doing it against the original is slow and dangerous.

This is the book's second recurring theme in its most practical form: the original is sacred. Protect it, copy it, verify the copy, and from that moment forward touch only the copy.

For a healthy drive you are recovering (not litigating), a straightforward forensic-style image is appropriate. Attach the source through a hardware write-blocker (or at minimum mount it read-only), and capture every sector:

# Image a healthy source to a raw (dd) file, capturing every sector.
# /dev/sdb = the source (verify with lsblk!), wedding.dd = the image.
sudo dcfldd if=/dev/sdb of=wedding.dd bs=4M \
     hash=sha256 hashlog=wedding.sha256 \
     conv=noerror,sync status=on

# dcfldd hashes as it reads, so acquisition and verification are one pass.
# conv=noerror,sync: on a read error, pad the bad block with zeros and
# keep going rather than aborting (important if a few sectors are weak).

1907729+0 records in
1907729+0 records out
Total (sha256): 7b1c0a4e9f2d3c8a... (image)

Then prove the copy equals the source by hashing both and comparing. If the source is failing, you would instead reach for ddrescue, which reads the good regions first, keeps a mapfile of what it has, and returns to scrape the difficult sectors with retries — the right tool for unstable media, detailed in Chapter 8. Either way, once you have an image, generate and record its hash. That single value is your anchor:

sha256sum wedding.dd
# 7b1c0a4e9f2d3c8a5b6e1d0f9c4a2b8e7d6c5f4a3b2c1d0e9f8a7b6c5d4e3f2a1  wedding.dd

Recovery vs. Forensics. The act of imaging is identical for both disciplines — read every sector, write it to a copy, hash to prove fidelity. What differs is the paperwork around it. For a recovery job you record the hash so you can confirm your working copies are faithful and detect media degradation between attempts. For a forensic job that same hash, recorded on a chain-of-custody form and reproduced in your report, is what lets you testify that the evidence presented in court is bit-for-bit what you seized. Same action, two purposes. Build the habit on every job and the forensic discipline is already in your hands when a recovery turns into a case.

Chain of Custody. Even on a "just get my photos back" job with no legal dimension, log it: device make/model/serial, capacity, the date and time you received it, who handed it to you, its condition, the image filename, and the image hash. It costs sixty seconds. It protects you if the client later claims you damaged the drive or lost a file — and roughly one recovery job in a hundred turns into a dispute, a divorce exhibit, or a small-claims matter you never saw coming. The template lives in Appendix F.

Try This. Make your own test image so you can follow along safely. On a spare USB stick, copy a dozen photos, note their names and sizes, then delete them and empty the recycle bin. Image the stick with dcfldd to a file, hash it, and use that image as your practice subject for the rest of this chapter. You will see your "deleted" files reappear, which teaches the lesson better than any paragraph can. (More practice images: Appendix J.)

What "delete" actually does — and it depends on the file system

To recover a deleted file you must know precisely what deletion changed and what it left behind, and that answer is different for every file system. This is the technical heart of the chapter. The method is constant — find the surviving metadata, follow it to the data — but the specifics of NTFS, FAT, and ext4 diverge sharply, and those differences decide how successful, and how automatic, your recovery will be. We met these structures in Chapter 4; here we look at exactly what survives a deletion.

NTFS: the MFT keeps the map

NTFS is the recovery technician's friend, because its design makes deleted files unusually easy to bring back. Everything NTFS knows about a file lives in the Master File Table (MFT), a giant array of records, one (sometimes more) per file or directory. Each MFT record is normally 1,024 bytes and begins with the ASCII signature FILE (bytes 46 49 4C 45). A record is a small container of attributes: $STANDARD_INFORMATION` (type `0x10`, holding the timestamps Windows shows), `$FILE_NAME (type 0x30, holding the name, the parent-directory reference, and a second copy of the timestamps), and $DATA (type 0x80, holding the file's actual content — or, for larger files, a map to where that content lives on disk).

Here are the first 64 bytes of a real MFT record for a deleted JPEG, annotated:

Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
00000000  46 49 4C 45 30 00 03 00  5E 2A 1C 00 00 00 00 00   FILE0...^*......
00000010  02 00 01 00 38 00 00 00  A8 01 00 00 00 04 00 00   ....8...........
00000020  00 00 00 00 00 00 00 00  06 00 00 00 8C 14 00 00   ................
00000030  10 00 00 00 60 00 00 00  00 00 18 00 00 00 00 00   ....`...........

  0x00  46 49 4C 45            "FILE"  — record signature (valid record)
  0x04  30 00                  offset to the fixup/update-sequence array (0x30)
  0x06  03 00                  3 fixup entries (1 USN + 2 sectors = 1024 bytes)
  0x10  02 00                  sequence number (incremented on reuse)
  0x12  01 00                  hard-link count
  0x14  38 00                  offset to first attribute (0x38)
  0x16  00 00   <── FLAGS:     0x0000 = NOT IN USE  →  THIS FILE IS DELETED
                               (an allocated file would read 01 00 here;
                                01=in-use, 02=directory, 03=in-use directory)
  0x18  A8 01 00 00            used size of this record (0x1A8 = 424 bytes)
  0x1C  00 04 00 00            allocated size of record (0x400 = 1024 bytes)
  0x20  00 00 00 00 00 00 00 00  base-record reference (0 = this IS the base)
  0x30  10 00 00 00            first attribute: type 0x10 = $STANDARD_INFORMATION

The decisive field is at offset 0x16: the record flags. When a file is deleted, NTFS does four small things, and only these four:

  1. Clears the in-use bit in the MFT record flags (0x16): 0x0001 becomes 0x0000. The record is now marked "available for reuse."
  2. Clears the record's bit in $MFT's allocation bitmap, so the system knows the record slot can be recycled.
  3. Clears the file's cluster bits in $Bitmap (the volume cluster bitmap, MFT record 6), marking those clusters free.
  4. Removes the file's entry from the parent directory's $INDEX B-tree so it no longer appears in listings.

Now notice everything NTFS does not do. It does not erase the MFT record's contents. The $FILE_NAME` attribute still holds the original name, the parent-directory reference, the timestamps, and the size. The `$STANDARD_INFORMATION timestamps are intact. And most important of all, the $DATA attribute still contains its full data runs — the compact list of cluster ranges where the file's bytes live. The file's content in those clusters is untouched.

A data run is a tiny encoded map. For a non-resident $DATA attribute (any file too big to fit inside the 1,024-byte record — every photo qualifies), the runs are a sequence of (length, offset) pairs. The first byte of each run is a header whose low nibble is the number of bytes used for the length and whose high nibble is the number of bytes used for the starting-cluster offset:

Data run bytes:  32 00 03 00 20 00 00
                 ┌┘ └──┬──┘ └──┬───┘ └─ 0x00 terminates the run list
                 │     │       └─ 3 offset bytes (high nibble = 3):
                 │     │             00 20 00  → 0x002000 = 8192  (start cluster)
                 │     └─ 2 length bytes (low nibble = 2):
                 │           00 03     → 0x0300 = 768            (cluster count)
                 └─ header 0x32

Meaning: 768 clusters starting at cluster 8192.
With 4 KiB clusters: 768 × 4096 = 3,145,728 bytes ≈ 3.0 MB,
beginning at byte offset 8192 × 4096 = 33,554,432 on the volume.

So to recover this deleted JPEG you do not need to guess anything. The surviving MFT record tells you the file was 3 MB, named what it was named, and that its bytes occupy 768 contiguous clusters starting at cluster 8192. Read those clusters from your image and you have a perfect copy. This is why NTFS undelete is so reliable: the map survives the deletion. The two things that defeat it are (a) the MFT record getting reused for a new file before you recover, which overwrites the runs, and (b) the data clusters getting overwritten by new file content — both consequences of continuing to use the drive after the deletion, which is why the first thing you tell any client is "stop using it now."

A short, illustrative Python pass over a dumped MFT shows how mechanical the detection is. (As with every code listing in this book, it is illustrative — internally correct, but never executed in our environment.)

import struct

MFT_RECORD_SIZE = 1024

def record_state(rec: bytes):
    """Return ('FILE'|'BAAD'|None, in_use, is_dir) for one MFT record."""
    sig = rec[0:4]
    if sig not in (b"FILE", b"BAAD"):
        return (None, False, False)          # wiped or non-record slot
    flags = struct.unpack_from("<H", rec, 0x16)[0]   # flags at offset 0x16
    return (sig.decode(), bool(flags & 0x0001), bool(flags & 0x0002))

def filename(rec: bytes):
    """Walk attributes to find $FILE_NAME (0x30) and decode the name."""
    off = struct.unpack_from("<H", rec, 0x14)[0]     # first-attribute offset
    while off < len(rec) - 8:
        atype = struct.unpack_from("<I", rec, off)[0]
        if atype == 0xFFFFFFFF:                       # end-of-attributes marker
            break
        alen = struct.unpack_from("<I", rec, off + 4)[0]
        if alen == 0:
            break
        if atype == 0x30:                             # $FILE_NAME, always resident
            content_off = off + struct.unpack_from("<H", rec, off + 0x14)[0]
            name_len = rec[content_off + 0x40]        # length in UTF-16 chars
            name_off = content_off + 0x42
            return rec[name_off:name_off + name_len * 2].decode("utf-16-le",
                                                               "replace")
        off += alen
    return None

with open("mft.bin", "rb") as f:
    idx = 0
    while (rec := f.read(MFT_RECORD_SIZE)) and len(rec) == MFT_RECORD_SIZE:
        sig, in_use, is_dir = record_state(rec)
        if sig == "FILE" and not in_use and not is_dir:
            print(f"MFT #{idx:>7}: DELETED FILE  ->  {filename(rec)!r}")
        idx += 1

Tool Tip. Before you trust the bytes of any MFT record (or NTFS index), remember the fixup/update-sequence array. NTFS overwrites the last two bytes of every 512-byte sector inside a multi-sector structure with a sequence number, and stashes the originals in the fixup array at the offset given at 0x04. A correct parser must restore those bytes (apply the fixups) before reading fields that fall in the last two bytes of a sector. The major tools do this automatically; if you are hand-decoding and a value looks wrong near a 512-byte boundary, suspect a missing fixup.

FAT: the start cluster survives, the chain does not

FAT (the FAT16/FAT32 family still ubiquitous on memory cards, USB sticks, and cameras) behaves very differently, and the difference dictates a hard recovery limitation. In FAT, a file is described by a 32-byte directory entry plus a cluster chain stored in the File Allocation Table itself — a linked list where each FAT slot names the next cluster of the file. Here is a deleted directory entry for VACATION.JPG:

Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
00000000  E5 41 43 41 54 49 4F 4E  4A 50 47 20 00 64 9E 6D   .ACATIONJPG .d.m
00000010  7A 54 7A 54 00 00 9F 6D  7A 54 0A 00 00 00 30 00   zTzT...mzT....0.

  0x00  E5                     deleted marker (was 'V' = 0x56; FIRST CHAR LOST)
  0x01  41 43 41 54 49 4F 4E   "ACATION"  (rest of the 8.3 name survives)
  0x08  4A 50 47               "JPG" extension
  0x0B  20                     attributes (0x20 = archive)
  0x14  00 00                  high word of first cluster (FAT32)
  0x1A  0A 00                  low word of first cluster  → first cluster = 10
  0x1C  00 00 30 00            file size = 0x00300000 = 3,145,728 bytes (3 MB)

When FAT deletes a file it does just two things:

  1. Overwrites the first byte of the filename with 0xE5, the universal "this entry is deleted" marker. You permanently lose the first character of the name (which is why recovered FAT files so often appear as _ACATION.JPG and tools prompt you to supply the missing letter).
  2. Zeroes the file's cluster chain in the FAT — every FAT slot the file used is set back to 0 (free).

The directory entry retains the starting cluster and the exact file size. So you always know where the file begins and how long it is. What you have lost is the chain — the map of which clusters follow the first one. And here is the consequence that defines FAT recovery:

  • If the file was stored contiguously (its clusters ran one after another, which is common on freshly written cards and for files written in one shot), recovery is trivial: start at the recorded first cluster and read ceil(size / cluster_size) consecutive clusters. For our example, 3,145,728 bytes ÷ 4,096 = 768 clusters, so read clusters 10 through 777. Done.
  • If the file was fragmented, you are in trouble. The directory entry tells you the first cluster, but the chain that told you where the file jumped next is gone. After cluster 10, did the file continue at 11, or leap to 4,000? FAT no longer knows, and neither do you. You can read forward optimistically and hope it was contiguous, but if it wasn't, the result is a file that is correct at the start and garbage after the first fragment boundary. Recovering fragmented files from FAT generally means falling back to carving (Chapter 7) and accepting that some files cannot be cleanly reassembled.

Recovery vs. Forensics. That lost first character is a small thing for recovery (you rename the file) but a real one for forensics: you cannot state the original filename with certainty, so your report must say _ACATION.JPG (first character unknown) rather than inventing a V. The discipline is the same throughout this book — report what the evidence supports, not what you assume. A confident guess that turns out wrong on cross-examination costs you far more than an honest "the first character of the filename was overwritten by the deletion marker and cannot be recovered."

exFAT, FAT's modern successor for large cards, complicates this further: it tracks allocation in a separate bitmap and only records a cluster chain in the FAT for fragmented files, flagging contiguous files with a "no FAT chain" bit. On deletion it clears the bitmap bits and the allocation flag. The net effect for recovery is similar — contiguous files come back cleanly, fragmented ones are hard — but the structures you inspect differ. See Appendix G for the exFAT layout.

ext4: the timestamps survive, the map is wiped

Linux's ext4 is the hardest of the three, and understanding why prevents you from promising a client something you cannot deliver. In ext4, file metadata lives in an inode — by default 256 bytes — containing the mode, owner, size, link count, four timestamps (access, change, modify, and crucially dtime, the deletion time), and a small extent tree describing where the data blocks are. ext4 replaced the old ext2/ext3 system of direct/indirect block pointers with extents: compact (logical-block → physical-block-range) mappings. The extent tree begins inside the inode with a header whose magic number is 0xF30A (on disk, little-endian, the bytes 0A F3).

When ext4 deletes a file it:

  1. Sets the inode's link count to 0.
  2. Sets dtime to the current time (a clear "this was deleted, and when" marker — useful evidence).
  3. Marks the inode free in the inode bitmap.
  4. Marks the data blocks free in the block bitmap.
  5. And — the killer — it zeroes the extent tree in the inode, destroying the map from inode to data blocks. (ext3 did the equivalent by zeroing the indirect block pointers, which is the origin of the long-standing "you can't undelete on Linux" lore.)

So on ext4, the inode survives with the size and the timestamps — you can often tell that a file existed, how big it was, and exactly when it was deleted — but the pointers telling you where its data lives are gone. The data blocks themselves are intact (marked free, not erased), but you have lost the index to them. Unlike NTFS, the map does not survive.

That leaves two avenues, both more laborious than NTFS undelete:

  • The journal (jbd2). ext4 is journaled. Before it commits metadata changes, it writes copies of the affected blocks to the journal. Recently deleted inodes frequently still have an older copy in the journal — a copy made before the extent tree was zeroed, still holding the original mapping. The tool extundelete works exactly this way: it scans the journal for prior versions of the target inodes and uses their surviving extents to reassemble the file. It works best for recently deleted files on a quiet file system, and degrades as the journal cycles.
  • Carving. When the journal no longer holds the mapping, you fall back to signature-based carving (Chapter 7) of the freed blocks — recovering content without the benefit of any file-system structure.

Limitation. This is theme #5 — know your limitations — made concrete. The same deletion, on three file systems, leaves three very different amounts of help: NTFS hands you the whole map, FAT hands you the start and the length, ext4 hands you the size and a timestamp but takes away the map. When a client with a Linux server asks for the same "undelete everything" you cheerfully promised the NTFS client, your answer must be more guarded: "recently deleted files via the journal, likely yes; older deletions, partial and carving-dependent." The technology dictates the honest promise.

The three behaviors, side by side:

WHAT SURVIVES A DELETION
─────────────────────────────────────────────────────────────────────────
                    NTFS (MFT)        FAT (dir entry)     ext4 (inode)
─────────────────────────────────────────────────────────────────────────
file name           full              all but 1st char    no (in inode);
                                      (1st byte → 0xE5)   name was in dir
size                yes               yes                 yes
timestamps          yes ($SI + $FN)   yes                 yes (+ dtime!)
map to data         YES (data runs)   START cluster only  NO (extents
                    survive intact    (chain is zeroed)   zeroed in inode)
data clusters       intact            intact              intact (freed)
─────────────────────────────────────────────────────────────────────────
practical result    near-perfect      perfect if          journal/extundelete
                    undelete          contiguous;         for recent; else
                                      carve if fragmented carve
─────────────────────────────────────────────────────────────────────────

Why This Matters. Technology changes; principles don't (theme #4). You will meet APFS, ZFS, Btrfs, ReFS, and file systems not yet invented. The specifics above will shift — but the method never does: learn what the file system records about a file, learn exactly what deletion changes, and recovery becomes a matter of reading what survived. Master the question, not just today's three answers.

Recovering deleted files: the recovery technique

With the mechanics understood, the recovery procedure follows naturally, and for the common cases your tools automate it. Working always on your image:

On NTFS, point an undelete-capable tool (TestDisk, DMDE, R-Studio, UFS Explorer) at the volume. It walks the MFT, finds every record whose 0x16 flag is clear (FILE present, in-use bit 0), reads each one's surviving $FILE_NAME` (original name, parent reference → so it can even rebuild the folder tree) and `$DATA data runs, and copies the referenced clusters out to your destination. Resident files (tiny ones whose content sat inside the MFT record) come straight out of the record. Because the map survives, recovered NTFS files are usually byte-perfect, complete with their original names and timestamps. Your only adversaries are reuse and overwrite.

On FAT/exFAT, the tool reads each 0xE5-marked directory entry for its start cluster and size, then reads that many consecutive clusters. It will ask you to confirm or supply the lost first character of the name. Trust contiguous recoveries; treat large or clearly fragmented files with suspicion and verify they open correctly.

On ext4, run extundelete against the image to mine the journal:

# Recover everything extundelete can reconstruct from the journal, to ./out
extundelete wedding.img --restore-all -o ./out
# Or target a single path the user remembers:
extundelete wedding.img --restore-file home/user/report.odt

Loading filesystem metadata ... 240 groups loaded.
Loading journal descriptors ... 1893 descriptors loaded.
Searching for recoverable inodes in directory / ...
312 recoverable inodes found.
Looking through the directory structure for deleted files ...
89 recoverable files found.
Writing output to directory ./out/RECOVERED_FILES/

Whatever the file system, the same caution applies: recover to a different device than the one you are recovering from (here, from the image, to a clean output disk). Writing recovered files back onto the source — or onto the very image you are reading — risks overwriting the still-unrecovered files you have not gotten to yet.

Tool Tip. Recover more than the client asked for, then triage. Disk space is cheap; a second pass over a degrading drive is expensive and risky. Pull everything recoverable in one sweep, then sort and select on your own storage. The selective, human part of the job — "which of these 8,000 photos does the client actually want?" — should happen on your bench, not at the cost of extra reads on a fragile original.

Recovering deleted files for court: the forensic technique

A forensic examiner recovers the same deleted files using the same file-system facts, but with two differences in posture: defensibility (every step reproducible and documented, nothing written to the original) and completeness (you recover and catalog deleted files as evidence, including ones the user clearly tried to destroy — recall anchor #2, the employee who covered their tracks). The open-source Sleuth Kit is the canonical toolset, and it operates read-only on an image by design.

fls lists files, including deleted ones, marking deleted entries with an asterisk. The -o flag gives the partition's start sector (here 2048); for NTFS, metadata addresses take the form MFTentry-attrtype-attrid (attribute type 128 = 0x80 = $DATA):

# List deleted entries (the asterisk) across the NTFS volume at sector 2048.
fls -r -o 2048 -f ntfs wedding.dd | grep '\*'

r/r * 5132-128-1:   IMG_2009_0612_first_dance.jpg
r/r * 5133-128-1:   IMG_2009_0612_cake_cutting.jpg
r/r * 5134-128-1:   IMG_2011_0903_hospital.jpg
d/d * 4087-144-2:   2009_Wedding   (deleted directory; index attr type 144)

icat extracts a file's content by its metadata address — reading the $DATA runs and streaming the clusters — without altering anything:

icat -o 2048 -f ntfs wedding.dd 5132-128-1 > recovered/first_dance.jpg
file recovered/first_dance.jpg
# recovered/first_dance.jpg: JPEG image data, Exif standard, 4928x3264, ...

For bulk work, tsk_recover exports all deleted files (default) or all files (-a) in one command, preserving paths where the metadata allows:

tsk_recover -e -o 2048 wedding.dd ./out      # -e = every file (alloc + deleted)
# Files Recovered: 8,412

The forensic value goes beyond the file content. Because the MFT record survives, so do its timestamps — both sets. NTFS keeps timestamps in $STANDARD_INFORMATION` (the ones Windows updates and that user tools and timestomping utilities can rewrite) and a second copy in `$FILE_NAME (updated by the kernel, far harder to forge). When the two disagree, that discrepancy is itself evidence of tampering — the thread we pick up in detail in Chapter 21. The point for now: a "deleted" file often carries, in its surviving metadata, the record of when it existed and when it was destroyed.

Recovery vs. Forensics. A recovery technician runs an undelete wizard, gets the files, and hands them over — speed and restoration are the goal. An examiner runs fls/icat/tsk_recover from the command line precisely because it is scriptable, read-only, and reproducible: another examiner can run the identical command against the same image hash and get bit-identical output, which is what "defensible" means. Same recovered bytes, two standards of proof. Notice, too, that the recovery tool's GUI may be perfectly capable forensically — what makes the difference is the documented, repeatable process around it, not the brand of the tool.

Legal Note. Recovering a deleted file does not, by itself, prove who deleted it or why. Deletion can be routine (a program clearing its cache), automatic (a retention policy), or accidental, not just deliberate. In litigation, the recovered file is one fact; intent and attribution require corroboration — user-account context, timeline correlation, and other artifacts. Spoliation findings (sanctions for destroying evidence) hinge on intent and duty to preserve, not merely on the fact that something was deleted. Keep the technical finding and the legal inference separate in your report; the frameworks are in Chapter 25.

Formatted-drive recovery

Our wedding-photos client did not delete files one by one; they reformatted the drive. Recovering from a format requires understanding what a format actually does — and, like deletion, the answer is "less than you fear," with one important exception.

A quick format (the default, the fast option, the one most people click) writes a fresh, empty set of file-system structures — a new boot sector, an empty new MFT or new FATs or new ext superblock and inode tables — over the small regions those structures occupy. It then declares the volume empty. It does not touch the data area. Every file's content still sits in its old clusters, now considered "free" by the brand-new, empty file system laid on top. The old directory tree is gone from the new file system's point of view, but the bytes are right there.

A full format is the exception, and the behavior changed with the operating system version — a distinction that has decided many cases:

  • Windows Vista and later: a full format performs a complete write pass over the entire volume, typically writing zeros to every sector, in addition to a bad-sector scan. After a completed full format on Vista+, the data is genuinely gone — overwritten — and this chapter's techniques will not bring it back. (If the full format was interrupted partway, the un-reached tail of the volume may still hold data.)
  • Windows XP and earlier: a "full format" only read-scanned for bad sectors; it did not overwrite the data. So a full format on XP-era systems is as recoverable as a quick format.
  • diskpart clean all, dd if=/dev/zero, ATA Secure Erase, and vendor "secure format" utilities likewise overwrite, and after them logical recovery fails by design.

Then there is reformatting to a different file system — say, an NTFS drive reformatted as exFAT, or vice versa. The new file system writes its structures in the locations it uses, but those locations rarely coincide perfectly with the old ones, so much of the old file system's metadata survives in the gaps, and essentially all of the old data survives in the cluster area. Recovery here is a treasure hunt for residual old structures: scan the whole volume for orphaned FILE records (old MFT entries the new file system never overwrote), for old FAT boot signatures, or for ext superblock copies — and recover from whichever survived.

Two pieces of built-in redundancy make formatted-drive recovery more tractable than it sounds:

  • NTFS keeps a backup boot sector at the very last sector of the volume, and an $MFTMirr` (MFT record 1) mirroring the first four MFT records. A format that rewrote the *primary* boot sector often left the backup, and tools use it to relocate the old `$MFT.
  • ext2/3/4 scatters superblock backups across block groups (with the common sparse_super option, at groups 0, 1, 3, 5, 7, 9, …). If the primary superblock was overwritten, a backup (e.g., at block group 1) lets you mount and read the old file system: mount -o ro,sb=<backup_block> ... or fsck -b <backup> against the image.

The practical workflow, then: determine whether the format overwrote the data (Was it Vista+ full format? diskpart clean all? A secure-erase tool? If so, manage expectations.). If not, look first for surviving old file-system structures (residual MFT, superblock backups) because they let you recover with original names and folders intact; and where those structures were overwritten by the new file system's metadata, fall back to carving the data area by signature (Chapter 7), accepting the loss of names and structure. The wedding-photos recovery, below, does exactly this.

War Story. A technician received a 2 TB drive that a Windows installer had "formatted" before the customer cancelled. The customer, panicking, had run a third-party "drive repair" tool that offered to "fix" the file system — it ran chkdsk-style repairs on the original, replayed structures, and in doing so reused dozens of the clusters that still held the customer's QuickBooks data, permanently destroying records that a simple image-first approach would have recovered in full. The lesson is the one this chapter opens and closes with: the first tool you run is image, and you run it on the original exactly once. Repair tools "fix" file systems by writing to them. Never let them write to the only copy that exists.

Lost and corrupted partitions

Sometimes the problem is one level up from the file system: the partition table — the master index that says "partition 1 is NTFS, starts at sector 2048, runs for N sectors" — is damaged or gone, even though the partitions themselves (their internal file systems and all their files) are perfectly intact. The drive shows as "unallocated" or "not initialized," and the operating system offers, alarmingly, to initialize it (which would write a new, empty table — decline). Causes include a botched repartition, a virus, a bad USB enclosure, a dd written to the wrong device, or simple corruption of sector 0.

Recall the two partitioning schemes from Chapter 4. MBR stores its table in the first sector (LBA 0): four 16-byte entries beginning at offset 0x1BE, ending with the boot signature 55 AA at 0x1FE. GPT keeps a protective MBR in LBA 0 (one entry of type 0xEE), a primary header in LBA 1 (signature EFI PART = 45 46 49 20 50 41 52 54), and a partition-entry array starting at LBA 2 — plus a complete backup header and array at the very end of the disk, CRC32-protected. One annotated MBR partition entry:

Offset    bytes                       field
000001BE  80                          boot flag (0x80 = active/bootable)
000001BF  20 21 00                    CHS start (legacy; ignore on modern disks)
000001C2  07                          partition TYPE: 0x07 = NTFS/exFAT
                                       (0x0B/0x0C = FAT32, 0x83 = Linux,
                                        0xEE = GPT protective, 0x05/0x0F = ext.)
000001C3  DF 13 0C                    CHS end (legacy)
000001C6  00 08 00 00                 LBA start = 0x00000800 = 2048
000001CA  70 6D 70 74                 sector count = 0x74706D70 = 1,953,503,600
                                       → 1,953,503,600 × 512 ≈ 1.0 TB
...
000001FE  55 AA                       MBR boot signature

The key realization parallels everything else in this chapter: a damaged partition table does not damage the partitions. Each file system still begins with its own recognizable signature at the start of its area:

  • NTFS boot sector: bytes EB 52 90 then the OEM ID NTFS␣␣␣␣ (4E 54 46 53 20 20 20 20) at offset 0x03.
  • FAT32 boot sector: EB 58 90 jump, with FAT32␣␣␣ at offset 0x52.
  • exFAT boot sector: EB 76 90 then EXFAT␣␣␣ at offset 0x03.
  • ext2/3/4 superblock: magic 0x53EF (bytes 53 EF) at offset 0x438 from the partition start (1024-byte superblock offset + 0x38 within it).

So to rebuild a lost partition table you scan the whole disk for these signatures, and each hit marks a partition's start. The matching backup structures confirm the size: an NTFS partition's backup boot sector sits at its last sector, so finding the start signature and the backup boot sector brackets the partition exactly. This signature-scan-and-bracket is precisely what TestDisk does, and it can then write a corrected, valid partition table — non-destructively, because rewriting the 64-byte MBR table or the GPT headers does not touch the partitions' data at all. (For GPT, when the primary header is corrupt, recovery is often as simple as restoring from the intact backup at the end of the disk — the redundancy is built in for exactly this.)

War Story. An administrator meant to wipe a scratch disk and typed the device name one letter off: dd if=/dev/zero of=/dev/sda bs=1M count=10 — zeroing the first ten megabytes of the production disk, obliterating the GPT primary header and the start of the first partition. The data was fine; the signposts were gone. Recovery took twenty minutes: restore the GPT from its backup at the end of the disk, then repair the file system's primary boot sector from its backup — all performed against an image first, then replayed on the original once verified. The absence of a structure is not the absence of the data.

Tools, step by step

Five tools dominate logical recovery. The first two are free and superb; the last three are commercial and earn their price on hard cases (deep file-system reconstruction, RAID, exotic file systems). All of them should be run against your image, not the original. A fuller reference is in Appendix C; command syntax in Appendix H.

TestDisk — partition repair and undelete

TestDisk is the free, open-source workhorse for partition recovery and for FAT/NTFS/ext undelete. It is menu-driven in a terminal. A typical session to repair a lost partition table:

TestDisk 7.2, Data Recovery Utility
Disk /dev/loop0 - 1000 GB / 931 GiB

Please select the partition table type:
 [Intel ]  [EFI GPT]  [Mac ]  [None]  ...
>> (TestDisk auto-detects; here: Intel/MBR)

  [ Analyse  ]  Analyse current partition structure, search for lost partitions
  [ Advanced ]  Filesystem Utils
  ...

>> Analyse  →  shows the (broken/empty) current table  →  [Quick Search]

Quick Search:
   NTFS  2048  1953503647  1953501600  [WeddingBackup]
   >> found one NTFS partition where the table said "empty"

   Structure: Ok.   Press 'P' to list files; Enter to continue.

>> P (list files) confirms the file system is readable:
   drwxr-xr-x  2009_Wedding/
   drwxr-xr-x  2011_Hospital/
   -rw-r--r--  IMG_2009_0612_first_dance.jpg   3,145,728

>> Enter → choose [Write] to write the recovered partition table
   "Write partition table, confirm ? (Y/N)"  → Y

If Quick Search misses a partition (heavily overwritten table), you escalate to Deeper Search, which scans the whole disk sector by sector for file-system signatures and backup boot sectors. TestDisk also does file-level undelete: from the file list, deleted entries appear in red; press c to copy selected files to a chosen output directory — your safe destination disk.

PhotoRec — the bridge to carving

PhotoRec ships with TestDisk and ignores the file system entirely: it scans the raw device for file signatures (headers and footers) and reconstructs files from the data area regardless of whether any metadata survives. That makes it the right tool exactly when this chapter's methods run out — when the MFT was overwritten by a reformat, when the FAT chain is gone and the file is fragmented, when ext4 zeroed the extents and the journal is exhausted. It is signature carving, the subject of Chapter 7, so we only preview it here:

PhotoRec 7.2, Data Recovery Utility
Disk /dev/loop0 - 1000 GB    File family to recover: [jpg] [png] [tiff] ...
Analyse  Pass 1 ...
   13,847 / jpg recovered
   1,204  / png recovered
Destination: /mnt/recovery/recup_dir   (NEVER the source!)

The trade-off, which you will learn to manage in Chapter 7, is that carving recovers content but not names or folders — you get f013847.jpg, not IMG_2009_0612_first_dance.jpg — and it cannot reassemble fragmented files. That is why you always try metadata-based recovery (surviving MFT/inode/dir entries) first, and carve only for what is left.

DMDE — disk editor plus reconstruction

DMDE (DM Disk Editor and Data Recovery) pairs a precise hex/disk editor with strong file-system reconstruction. Its strength is virtual reconstruction: it can rebuild a deleted or formatted volume's directory tree from residual structures and present it as a browsable file system you recover from, without writing to the source. The hex editor is invaluable when you need to see the bytes — confirm a FILE record's flag at 0x16, read a data run by hand, verify a partition signature — which is also why DMDE is a fine teaching tool for everything in the sections above. Its workflow: select the physical disk or image → "Full Scan" to find lost file-system structures → open the reconstructed volume → mark files/folders → "Recover" to your output disk.

R-Studio — commercial scan and reconstruction

R-Studio is a polished commercial suite favored in professional shops. It scans a disk or image, recognizes a wide range of file systems (NTFS, FAT/exFAT, ext2/3/4, APFS, HFS+, ReFS, UFS), reconstructs directory trees from residual metadata, carves "extra found files" by signature where metadata is gone, and — important for the next several chapters — reconstructs RAID arrays (Chapter 10) from member images. Its scan presents recovered files in three tiers: those with intact metadata (real names, folders), those reconstructed from partial metadata, and raw carved files grouped by type. You preview files (open a photo, check a document) before committing to a full recovery, which helps you estimate success honestly for a client.

UFS Explorer — broad file-system coverage

UFS Explorer (and its sibling Recovery Explorer) is another strong commercial option, particularly when you face less-common or mixed environments: many file systems, RAID and JBOD reconstruction, virtual-disk formats (VMDK, VHD/VHDX, VDI), and storage-pool layouts (LVM, Storage Spaces, ZFS). Like the others it scans read-only, reconstructs what it can, and previews before recovery.

Ethics Note. Commercial tools are licensed software. Use a legitimate license, not a cracked "data recovery" build downloaded from a forum — a cracked tool handling a client's irreplaceable data (or a court's evidence) is a malware risk and a professional-integrity failure waiting to surface on cross-examination. Most of these tools run in a free preview/scan mode that shows you what is recoverable before you pay; use that to scope the job and quote the client honestly. And remember the people behind the data: a recovery scan will surface a stranger's private photos, financial records, and messages. Look only at what you need to verify recoverability, and never further. The human cost is real (theme #6) — protect the privacy of someone who will never know you held their whole digital life on your bench.

Worked example: the wedding photos, end to end

Now we run the anchor case from the front of the chapter all the way through. The client's 1 TB external drive (originally NTFS, accidentally reformatted) is on the bench, and they have not used it since — the single most important fact in their favor.

1 — Intake and triage. Record the device: WD Elements 1 TB, serial WX...4821, received 2026-06-26 14:10 from the client in person, condition: physically sound, powers on, enumerates cleanly, no clicking, SMART reads healthy with zero reallocated sectors. Conclusion: a logical problem (format), not a physical one. Set client expectations honestly: most or all photos likely recoverable; filenames and folders recoverable where the old MFT survives, lost where the reformat overwrote it; a small number of fragmented or overwritten files may not come back. Log it all on the chain-of-custody/intake form (Appendix F).

2 — Image first. Attach the drive through a write-blocker. Capture every sector with verification:

sudo dcfldd if=/dev/sdb of=wedding.dd bs=4M hash=sha256 \
     hashlog=wedding.sha256 conv=noerror,sync status=on
sha256sum wedding.dd
# 7b1c0a4e9f2d3c8a5b6e1d0f9c4a2b8e7d6c5f4a3b2c1d0e9f8a7b6c5d4e3f2a1  wedding.dd

The image hash is recorded. From here the original goes back in its anti-static bag and is not touched again; all work happens on wedding.dd.

3 — Assess what the format did. Examine the start of the volume with a hex editor (or DMDE). The current boot sector is a fresh NTFS one from the reformat. But scanning the disk reveals thousands of residual FILE records — the old MFT — still present wherever the new, small empty MFT did not overwrite them. That is the good news: much of the original metadata survived, so we can recover with original names and folders intact.

4 — Recover from residual MFT (named, structured recovery). Run TestDisk's Deeper Search; it locates the old NTFS structure via the residual MFT and backup boot sector. List files — the old directory tree appears, deleted/orphaned entries in red:

Directory  2009_Wedding/
>  rd  IMG_2009_0612_first_dance.jpg    3,145,728   2009-06-12 19:42
   rd  IMG_2009_0612_cake_cutting.jpg   2,981,124   2009-06-12 20:15
Directory  2011_Hospital/
   rd  IMG_2011_0903_first_photo.jpg    3,402,901   2011-09-03 04:55

Select all and copy (c) to a clean output disk. In parallel, an examiner-style pass with Sleuth Kit catalogs and extracts the same deleted files reproducibly:

tsk_recover -e -o 2048 wedding.dd ./out_named
# Files Recovered: 7,108

Spot-check the results with file and by opening a sample — the photos open, EXIF intact, full resolution.

5 — Carve the overwritten region (content-only recovery). Where the reformat's new MFT and metadata overwrote part of the old MFT, those records are gone — but the photo data in the cluster area survives. Carve it with PhotoRec (full treatment in Chapter 7):

PhotoRec  →  file family: jpg, cr2, heic, png, mp4
   recovered: 1,389 jpg, 212 cr2, 47 mp4
   (output: recup_dir.1 ... names lost, content intact)

These come back as f0001234.jpg with no folder structure, but the pixels are the wedding. Total recovered set: ~7,100 named files plus ~1,650 carved files.

6 — Selective recovery and triage. The client most wants the wedding (June 2009) and the births (2011, 2014). Rather than hand over 8,700 files, triage by EXIF date — the camera stamped each photo's capture date inside the JPEG, which survives carving because it is in the file, not in the file system:

# Triage carved photos into year folders by EXIF DateTimeOriginal.
import os, shutil
from PIL import Image
from PIL.ExifTags import TAGS

SRC, DST = "recup_dir.1", "by_year"
for name in os.listdir(SRC):
    path = os.path.join(SRC, name)
    try:
        exif = Image.open(path)._getexif() or {}
        dt = next((v for k, v in exif.items()
                   if TAGS.get(k) == "DateTimeOriginal"), None)
        year = dt.split(":")[0] if dt else "unknown"   # "2009:06:12 ..." -> "2009"
    except Exception:
        year = "unknown"
    os.makedirs(os.path.join(DST, year), exist_ok=True)
    shutil.copy2(path, os.path.join(DST, year, name))

Now the carved chaos is sorted into 2009/, 2011/, 2014/, and the client's priority years are easy to verify and review.

7 — Verify, deliver, document. Open a representative sample from every year to confirm integrity (carving occasionally yields a truncated or false-positive file — verify, do not assume). Copy the recovered, organized set onto fresh media (never back onto the source), generate a manifest with hashes of each delivered file, and write a short recovery report: device details, image hash, method (residual-MFT recovery + signature carving), counts recovered, known gaps (a handful of fragmented videos that would not reassemble), and the delivery hash manifest. Return the original drive. The client gets ten years back.

Ethics Note. A wedding-and-births drive is the most intimate kind of data there is. You will see this family's most private moments scroll past during verification. Look only at what the job requires — enough to confirm files are intact and correctly sorted — and not one image more. Discretion is part of the craft; the people in those photos trusted a stranger with their entire visual history, even if they will never think of it that way.

Chain of Custody. Notice that this "non-forensic" recovery produced a complete, defensible record anyway: intake form, image hash, documented method, delivery manifest. If the drive turns out to be evidence in a custody dispute or an insurance claim — and you cannot predict which jobs will — you are already prepared. Working forensically by default costs almost nothing and protects you completely. Same action, two purposes, one more time.

Common mistakes

  • Working on the original. The cardinal sin. Every technique in this chapter runs on an image. Recovery and repair tools write; mounting writes; the OS writes; a failing drive degrades with every read. Image first, verify the hash, work on the copy — without exception.
  • Continuing to use the affected drive. The number-one destroyer of recoverable data is the user (or technician) who keeps using the volume after a deletion or format. Every new file written may land on the clusters that still hold the data you want. The first words to any client are "stop using it and bring it to me powered off."
  • Running chkdsk, fsck, or a "repair" tool on the original. These fix a file system by writing to it — replaying journals, reallocating clusters, rebuilding structures — and routinely overwrite recoverable data in the process. If you must run them, run them against an image.
  • Mounting the volume read-write. Even a read-only-intentioned mount can write if you forget the flag; a journaled file system may replay its journal on mount and change the disk. Always mount -o ro (and ideally behind a write-blocker), or better, do not mount the source at all — work from the image.
  • Recovering onto the source disk. Writing recovered files back to the disk you are recovering from overwrites the files you have not yet recovered. Always recover to a different device.
  • Trusting fragmented FAT recoveries blindly. A FAT file recovered by reading forward from the start cluster is only valid if it was contiguous. Large or fragmented files may be correct at the head and garbage after the first fragment. Verify; do not assume.
  • Promising ext4 results as if it were NTFS. The extent tree is zeroed on deletion. Recent files may come back via the journal (extundelete); older deletions often will not. Calibrate the promise to the file system.
  • Confusing "deleted" with "destroyed" — in both directions. Telling a client their formatted drive is "gone" (it usually is not) loses you the recovery; telling a court a wiped drive is "recoverable" (it may not be) loses you your credibility. Know what each operation actually did.

Limitations: knowing when to stop

Logical recovery is powerful, but it is not magic, and a professional knows the boundaries (theme #5). It fails — sometimes completely — when:

  • The data was overwritten. This is the absolute limit. Once new bytes occupy the clusters, the old bytes are gone; no logical technique retrieves them. Continued use, a Vista+ full format, diskpart clean all, dd if=/dev/zero, and secure-erase tools all overwrite. Old myths about magnetic-force microscopy recovering overwritten data from modern high-density drives do not hold in practice — a single overwrite pass is, for recovery purposes, the end.
  • The metadata was reused. Even if the data clusters survive, NTFS undelete needs the MFT record's data runs; if that record was recycled for a new file, the map is gone and you are reduced to carving (Chapter 7) — content possibly recoverable, names and structure not.
  • SSDs with TRIM. This is the big modern caveat and it deserves its own chapter (Chapter 9). On an SSD, when you delete a file the OS issues a TRIM command telling the drive those blocks are free; the SSD's controller then erases them in the background (often within seconds to minutes) so it can write to them quickly later. The result is that on a TRIM-enabled SSD, deleted-file recovery frequently returns zeros — the data is genuinely gone, fast, no matter how quickly you act. The reliable NTFS undelete you can count on for a spinning disk often simply does not work on a modern SSD. Do not promise it.
  • ext4's zeroed extents past the journal's horizon. As covered above, once the journal no longer holds an older copy of the inode, the map is unrecoverable and you are carving.
  • Strong encryption. If the volume was encrypted (BitLocker, FileVault, LUKS, VeraCrypt) and you do not have the key or password, the recovered ciphertext is useless. Encryption is covered in Chapter 29; the short version is that recovery from an encrypted volume without credentials is generally not feasible, by design.
  • Physical failure underneath. If the drive is actually failing, logical tools are the wrong layer; you need the physical-recovery techniques of Chapters 8–9, working from a ddrescue image.

Knowing when to stop is itself a professional skill. "The data was overwritten by continued use after the format, and is not recoverable" is a complete, honest, defensible finding — for a client and for a court alike. It is far better than burning a client's money on a hopeless deep-carve, or testifying to a recovery you cannot actually stand behind.

Progressive project: image the case evidence and recover the deleted files

This chapter is where your Forensic Case File stops being paperwork and starts containing recovered evidence. In Chapter 5 you received the assignment and learned the process; now you acquire and analyze.

Working from the practice image referenced in your case packet (or one you build per Appendix J):

  1. Acquire and verify. Image the case device (or, if you already have the supplied .dd/.E01, treat it as the original). Record the acquisition hash (MD5 and SHA-256) on your chain-of-custody form. Confirm your working copy's hash matches before doing anything else. This is the foundation every later finding rests on.
  2. Identify the file system(s) on the evidence (NTFS? FAT/exFAT? ext4?). Note, in your examiner's notes, what deletion means on this file system — because it determines what you can recover and what your report can claim.
  3. List the deleted files with fls -r -d -o <offset> <image> (or your tool's deleted view). Record the count and the metadata addresses of items of interest. Capture the surviving timestamps — you will need them when you build the timeline in Chapter 21.
  4. Recover the deleted files with icat/tsk_recover (or TestDisk/DMDE), extracting to a separate output directory, never to the image. Hash each recovered file and add it to your evidence manifest.
  5. Document everything: the exact commands you ran (so another examiner can reproduce them against the same image hash and get identical output), the tool versions, and any files that could not be recovered and why. Reproducibility is what makes the work defensible.

Add to your growing case file: the acquisition record (hashes + chain of custody), the list of deleted files with their metadata, the recovered files with their own hashes, and your notes on method. In Chapter 7 you will carve the regions where the file system itself was destroyed, recovering what the metadata-based methods here could not reach.

Summary

Logical recovery addresses the most common data-loss scenario of all: the storage device works perfectly, but the logical structures that organize the data — the partition table, the file system, the directory entries — are deleted, formatted, or corrupted. The data itself is almost always still there, because deletion and quick formatting change bookkeeping, not content. Recovery is the work of rebuilding or bypassing that bookkeeping.

The technical core of the chapter is that what "delete" leaves behind depends entirely on the file system. NTFS keeps the full map — the MFT record survives a deletion with its name, timestamps, and (crucially) its $DATA data runs intact, so undelete is near-perfect until the record is reused or the clusters overwritten; the deleted state is just the in-use flag cleared at offset 0x16. FAT keeps the start cluster and the size but zeroes the cluster chain and stamps the filename's first byte with 0xE5, so contiguous files recover perfectly and fragmented files often do not. ext4 keeps the size and the timestamps (including a deletion time) but zeroes the extent tree, destroying the map — so recovery leans on the journal (extundelete) for recent deletions and on carving for the rest. Formatted-drive recovery hinges on the difference between a quick format (metadata only — data intact) and a completed Vista-plus full format (a full overwrite — data gone), and on hunting for residual old structures and backup boot sectors/superblocks. Lost-partition recovery exploits the fact that damaging the partition table does not damage the partitions: scan for file-system signatures, bracket each partition with its backups, and rewrite a correct table non-destructively — which is exactly what TestDisk does, alongside PhotoRec for carving and DMDE, R-Studio, and UFS Explorer for deeper reconstruction.

Through all of it run the discipline that makes the difference between an amateur and a professional: image first, verify with a hash, and work only on the copy — even for pure recovery — and recover to a different device than you recover from. We worked the wedding-photos anchor from intake through imaging, residual-MFT recovery, carving the overwritten region, EXIF-based triage, verification, and documented delivery — and saw that the same defensible habits that protect a court case also protect a relieved family and the technician who served them.

You can now: - Explain precisely what deletion changes — and what it leaves intact — on NTFS, FAT/exFAT, and ext4, and predict how recoverable a deleted file is on each. - Image a drive before recovery, verify it with a hash, and conduct all work on the copy. - Recover deleted files by reading surviving file-system metadata (MFT data runs, FAT directory entries and start clusters, ext4 journal inodes) using both GUI recovery tools and the read-only, reproducible Sleuth Kit workflow. - Distinguish quick from full formats, recover from a reformatted drive via residual structures and backup boot sectors/superblocks, and rebuild a lost or corrupted partition table from file-system signatures with TestDisk. - Run TestDisk, PhotoRec, DMDE, R-Studio, and UFS Explorer for logical recovery, and choose between metadata-based recovery and carving for a given case. - State honestly when data is unrecoverable — overwritten clusters, reused metadata, TRIM-erased SSD blocks, or strong encryption — and document that finding professionally.

What's next. Chapter 7 — File Carving — picks up exactly where the file system gives out: when the MFT is overwritten, the FAT chain is gone, or ext4 has zeroed its extents, you recover files directly from raw data by their signatures — headers, footers, and internal structure — with no help from any metadata at all. It is how we rescued the carved portion of the wedding drive, and it is the technique you reach for when "undelete" has nothing left to read.

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.