Chapter 6 — Exercises

Thirty problems across seven groups: concept checks you can answer in a sentence, byte-level math you work by hand, hands-on labs you run against a practice image, and judgment calls with no single right answer. (answer in Appendix) = worked solution in Answers to Selected Exercises. ⭐ = stretch. Run every lab against an image, never an original — building that reflex is half of what this chapter teaches. Several problems supply the raw bytes or tool output you need; work from what is printed rather than guessing. For the judgment questions there is often no single right answer — you are graded on whether your reasoning would hold up explained to a client or, where relevant, to a court.

Group A — Deleted is not destroyed (concept checks)

These warm up the chapter's foundation: deletion changes bookkeeping, not content, and your first job is to tell which kind of problem you actually have.

6.1 A client stands at your bench, pale, holding a 1 TB external drive that "got formatted" two days ago. It held ten years of family photos and there is no backup. In plain language a non-technical person will believe — no jargon — explain why the photographs are almost certainly still on the drive, what "formatted" actually did to them, and the one instruction you give the client about the drive's use going forward. (answer in Appendix)

6.2 Define logical recovery and physical recovery in one sentence each. Then give two concrete, observable symptoms that tell you a problem you had assumed was logical is in fact physical and must not be touched with recovery software. For each symptom, name the tool you would reach for instead and the chapter that owns it. Finally, for a drive that does read reliably, write the one-line dcfldd command that images it to a raw file with inline SHA-256, and name the conv flags you would add if a handful of sectors were weak.

6.3 A drive clicks rhythmically, disappears and reappears in the device list, and its SMART reallocated-sector count has risen from 0 to 240 since yesterday. The client begs you to "just run the recovery program now, please." State exactly what you do, the single-sentence reason, and what each additional read of this drive costs you. Why is running undelete software here the opposite of helping, and what is the correct first action on this drive and the tool that performs it?

6.4 ⭐ The book's third theme holds that every action leaves a trace — and the absence of a trace is itself a trace. Apply it to one deleted file on NTFS: name one trace the deletion leaves behind (still present after delete), one trace it removes, and one piece of evidence an examiner can build from the gap the removal creates. Then state which of the chapter's six themes this same scenario also illustrates. (Hint: consider what the surviving $FILE_NAME attribute and the cleared parent-directory index entry each reveal on their own.)

Group B — What "delete" leaves behind (file-system mechanics)

This is the technical heart. To recover a deleted file you must know precisely what deletion changed and what it left — and that answer is different on every file system.

6.5 List the four — and only four — things NTFS changes when a file is deleted. Then identify the single most decisive field, with its byte offset within the MFT record, that lets you tell from raw bytes that the file is deleted, and state what value that field holds for a deleted file versus an in-use file. Finally, name the one attribute whose survival is the reason NTFS undelete is "near-perfect," and list two things NTFS deliberately does not do on deletion — the omissions that are precisely why the data persists. (answer in Appendix)

6.6 When FAT deletes a file it changes exactly two things. Name both. State which character of the filename is permanently lost and the exact byte that replaces it, and explain why recovered FAT files so often appear to tools as _ACATION.JPG. In one further sentence, explain how exFAT's handling differs specifically for fragmented files and why that detail matters for recovery. As a concrete check, a 9 MB photo and a 9 MB video clip were both deleted from the same exFAT card — predict which is more likely to recover cleanly, and why.

6.7 Explain why deleted-file recovery on ext4 is harder than on NTFS. Name the specific structure inside the inode that ext4 zeroes on deletion, state which two pieces of information do survive in the inode (one of which is itself useful evidence), and describe the two avenues — one journal-based, one signature-based — that remain for recovering the data anyway. Then state, in one sentence each, the condition under which each avenue succeeds and the single condition that defeats both.

6.8 ⭐ Without looking back at the chapter, reproduce the "what survives a deletion" comparison for NTFS, FAT, and ext4 across five rows: file name, size, timestamps, map-to-data, and data clusters. Then check it against the chapter's table, correct any row you missed, and write one sentence explaining why the "map-to-data" row is the one that most determines how automatic recovery will be. Then add a sixth row, "explicit deletion timestamp," and fill it for all three file systems — noting which one records a deletion time directly in the metadata and where the others' deletion times might still be found.

Group C — Hex, offsets, and the math (calculate and verify)

Decode the structures by hand at least once. The tools automate all of this, but you cannot trust a tool you cannot check.

6.9 Below are the first 32 bytes of an MFT record. Using only these bytes, state: (a) whether this is a valid record, and how you know; (b) whether the file is in use or deleted; (c) whether it is a file or a directory; (d) what the two bytes at offset 0x16 would read instead for an in-use file and for an in-use directory; (e) the used size (offset 0x18) and allocated size (offset 0x1C) of this record, and why the two differ; and (f) the meaning of the all-zero base-record reference at offset 0x20. (answer in Appendix)

Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
00000000  46 49 4C 45 30 00 03 00  5E 2A 1C 00 00 00 00 00
00000010  02 00 01 00 38 00 00 00  A8 01 00 00 00 04 00 00
00000020  00 00 00 00 00 00 00 00  06 00 00 00 8C 14 00 00

6.10 Decode the non-resident $DATA data run 32 00 03 00 20 00 00. Show your work in full: the header byte's two nibbles, how many bytes encode the length and how many the starting-cluster offset, the cluster count, the starting cluster, the file size in bytes (assume 4 KiB clusters), and the absolute byte offset of the file's first byte on the volume. Then a follow-up: if the same volume instead used 512-byte sectors grouped into 8-sector clusters, would your byte-offset answer change, and why or why not? (answer in Appendix)

6.11 ⭐ Decode the data run 21 10 00 04 on a volume with 4 KiB clusters: the header nibbles, the length, the starting cluster, the total file size in bytes, and the byte offset where the data begins. Then explain in one or two sentences why a second run in the same $DATA attribute encodes its starting cluster relative to the previous run's start (signed), and what that means if a parser misreads a single run header.

6.12 A FAT32 directory entry for a deleted file records the values below; the volume uses 4 KiB clusters. (a) How many clusters does the file occupy? (b) If it was stored contiguously, which exact cluster range do you read? (c) What single fact, now zeroed in the FAT, prevents you from being certain the read is correct if the file was fragmented, and what is the symptom of reading a fragmented file as if it were contiguous? (d) Sketch what the recovered JPEG would look like — at roughly which byte would it go wrong — if you read 768 contiguous clusters but the file had in fact jumped elsewhere after its 400th cluster. (answer in Appendix)

  first cluster (low word 0x1A, high word 0x14) = 10
  file size (offset 0x1C)                       = 0x00300000 = 3,145,728 bytes

6.13 An NTFS partition starts at LBA 2048 on a disk with 512-byte sectors and uses 4 KiB clusters. Compute, showing the arithmetic: (a) the byte offset of the partition's start on the physical disk; (b) the byte offset of cluster 8192 within the volume; and (c) the absolute byte offset of cluster 8192 on the physical disk. Which of these three numbers do you hand to icat-style tools, and which do you give a raw hex editor opening the whole disk? (d) If the file's true size were 3,000,000 bytes rather than a whole number of clusters, how many bytes of slack would sit unused in its final cluster, and why does that slack sometimes hold recoverable fragments of a previous file?

6.14 ⭐ You imaged a drive and recorded SHA-256 ending …d4e3f2a1. A week later, before a second recovery pass, you re-hash your working copy and get a value ending …91bc77. List three things this could mean, ordered from most to least likely, and state your next action for each. Which copy do you now trust, why do you keep the original image read-only and untouched, and what does this exercise illustrate about why you hash in the first place?

Group D — Hands-on recovery labs (work from an image)

Do these against a practice image you build or download (Appendix J). Submit the commands you ran and the relevant output. If you do not own a hardware write-blocker, mount every source strictly read-only — better yet, do all work against the image so the question never arises.

6.15 Build your own practice subject and prove you can image it. On a spare USB stick, copy a dozen photos; note their names and sizes; delete them; empty the Recycle Bin. Image the stick with dcfldd to a file, hash the image, and record the hash. Submit the exact command and the resulting SHA-256, and state which sector range you expect your deleted photos to still occupy and why they are still there. Confirm the deletion actually took effect by showing the files no longer appear in a normal directory listing of the stick, even though their data clusters are untouched. Keep this image — the next four labs use it.

6.16 Using The Sleuth Kit against the image from 6.15, complete the three-step undelete-and-verify workflow. Write out all three exact commands — including the -o partition offset and the -f file-system type — and paste the file output line confirming the extracted file is a real JPEG. The output of step (a) will look like the sample below; explain what the asterisk and the 128-1 mean, and what the d/d line carrying index attribute type 144 represents.

r/r * 5132-128-1:   IMG_2009_0612_first_dance.jpg
r/r * 5133-128-1:   IMG_2009_0612_cake_cutting.jpg
d/d * 4087-144-2:   2009_Wedding

6.17 ⭐ Run tsk_recover -e against the same image to export every file (allocated and deleted), then compare the recovered count to the number of deleted entries fls -r -d reported. Explain at least two legitimate reasons the two numbers differ (consider reused records, resident files, and entries whose data runs point at overwritten clusters), and describe how you would spot-check that the recovered files are genuinely intact rather than truncated. Then re-export at least one of the same files through TestDisk's copy feature and confirm the two tools produced byte-identical output by hashing both results.

6.18 Open a copy of the image in TestDisk and recover one deleted file using the file-undelete view (deleted entries appear in red; press c to copy). Recover it to a different device than the source image. In two or three sentences, explain precisely what goes wrong — at the cluster level — if you instead recover onto the source, and why "I have plenty of free space" does not make it safe. Note also what TestDisk lets you see before you commit to a copy — the file list and a preview — and why that preview helps you quote a client honestly.

6.19 On a practice ext4 image with recently deleted files, run extundelete <image> --restore-all -o ./out and report how many recoverable inodes and files it found. Then explain, referencing the journal (jbd2) and the zeroed extent tree, why some deleted files were reconstructed and others were not — and predict how the success rate would change on a busy production server versus a quiet one. Finally, explain why you run extundelete against the image and not the live file system, even though the tool itself only reads.

Group E — Formatted drives and lost partitions

The problem may be one level up from the file system. These exercises separate "the data is gone" from "the signposts are gone."

6.20 A user reports they did a "full format" of a drive that held important files. For each scenario, state whether logical recovery can succeed, and the one-sentence reason: (a) Windows 11, full format that ran to completion; (b) Windows XP, full format; (c) diskpart clean all; (d) a quick format on any Windows version; (e) a Windows 11 full format that the user cancelled a quarter of the way through. As a final cue: for (a) the user mentions the format "took over an hour to finish," whereas a quick format completes "in a few seconds" — what does that duration alone tell you about your odds? (answer in Appendix)

6.21 A 2 TB NTFS drive was reformatted as exFAT, and the files appear "gone." Describe the treasure hunt: where do you look for residual old NTFS structures so you can recover with original names and folders intact, and why does reformatting to a different file system leave more of the old metadata than reformatting to the same one? Name the two NTFS built-in redundancies, and their exact locations, that help you relocate the old $MFT. As part of your answer, interpret the TestDisk Quick Search result line below: state what was found, where the partition starts, how many sectors long it is, and what the bracketed [WeddingBackup] field is.

NTFS  2048  1953503647  1953501600  [WeddingBackup]

6.22 ⭐ An administrator typed one letter wrong and ran dd if=/dev/zero of=/dev/sda bs=1M count=10 against a GPT production disk, zeroing the first 10 MB. The data is intact; the signposts are not. Outline the full recovery in order: at which step do you make an image and why; which GPT redundancy lets you restore the partition table; and which file-system structure do you repair next, from what backup? Explain why this entire recovery is non-destructive to the partitions' data, and state the one verification step you perform after rewriting the table but before declaring the job done.

6.23 Identify the file system from the opening bytes of a partition. For each, name the file system and the field you keyed on: (a) EB 52 90 followed by 4E 54 46 53 20 20 20 20 at offset 0x03; (b) EB 58 90 with 46 41 54 33 32 at offset 0x52; (c) the magic 53 EF found at offset 0x438 from the partition start. For (c), name the structure those two bytes belong to and explain why the offset is 0x438 rather than 0. (d) Finally, decode the 16-byte MBR partition entry below — the boot flag, the partition type, the starting LBA, and the sector count — and from the sector count (512-byte sectors) give the partition's approximate size.

000001BE  80  20 21 00  07  DF 13 0C  00 08 00 00  70 6D 70 74
          │   └─CHS──┘  │   └─CHS──┘  └──LBA────┘  └──count──┘
          boot          type

Group F — Recovery vs. forensics, and the timeline

The same bytes, two standards of proof. These exercises build the dual-lens habit the book returns to in every chapter.

6.24 Same deleted JPEG, two jobs: in job one you are recovering it for a relieved client; in job two it may become an exhibit in court. The bytes you read are identical. List four things that change between the two jobs (consider tooling, documentation, what you recover, and how you state the filename), and name the one thing that does not change at all. For the filename in particular, explain why a recovery technician may quietly rename a FAT file to VACATION.JPG while an examiner must report it as _ACATION.JPG. (answer in Appendix)

6.25 An examiner can undelete a file with a friendly GUI wizard or with fls/icat/tsk_recover at the command line — both produce the same bytes. Give two reasons the examiner deliberately chooses the command-line tools, and tie each reason to a specific element of what "defensible" means in court. Then explain why the brand of tool matters less than the process around it, and give one concrete documentation element that turns an ordinary GUI recovery into a defensible one.

6.26 ⭐ A recovered, "deleted" NTFS file carries two sets of timestamps: one in $STANDARD_INFORMATION` (`$SI), one in $FILE_NAME` (`$FN). Explain how a disagreement between them can be evidence of tampering, why $FN is the harder of the two for a user-level tool to forge, and which later chapter develops this into full timeline and timestomping analysis (give its relative path). Which of the four anchor cases does this technique serve most directly? Then sketch, in one sentence, how an examiner would phrase a finding of timestamp inconsistency in a report without overstating intent.

6.27 Build a minimal timeline from the chapter's worked example. Using the three files and create-times below, draft a small MACB-style table: one row per file, columns for the timestamp shown plus placeholders for modify/access/birth and (where it exists) deletion time. Then write two sentences: what you would do if any row's $SI` and `$FN create-times disagreed, and how this mini-timeline feeds the larger one you will build in Chapter 21. Add one more observation: which of these file-system timestamps would be lost if a file had to be recovered by carving (Chapter 7) instead of from surviving metadata — and where, inside a JPEG, does a capture date survive regardless of the file system?

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

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

The professional layer: say what you can prove, name what you cannot, and protect the people behind the data.

6.28 Write a 200-word recovery report for the wedding-photos job, suitable to hand a client. Include: device make/model/serial, the image hash, the method used (residual-MFT recovery plus signature carving), the counts recovered (named files and carved files), the known gaps (a handful of fragmented videos that would not reassemble), and a one-line note that a hashed delivery manifest accompanies the files. Close with a single sentence recording the chain-of-custody facts you kept (intake date, who handed you the device, and the image hash) so the report stands on its own if the job later turns into a dispute. Use the device facts and SHA-256 from the chapter's worked example. (Template: Appendix F.)

6.29 A client's laptop SSD had files deleted yesterday; TRIM is enabled. Write the two- or three-sentence expectation-setting statement you give before quoting the job. Explain honestly why deleted-file recovery here is far less certain than on a spinning disk, what the controller most likely already did to those blocks and how quickly, and name the chapter that covers SSD and flash limits in depth. Then contrast: if the very same files had instead been deleted yesterday from a spinning secondary drive in the same laptop, and the machine was powered off immediately after, how would your statement change? (answer in Appendix)

6.30 Progressive project — acquire and recover the case evidence. Working from your Forensic Case File assignment (Chapter 5) and the supplied practice image: (a) acquire/verify the image and record both MD5 and SHA-256 on your chain-of-custody form, confirming your working copy matches before touching anything; (b) identify the file system(s) and note in your examiner's notes what "deleted" means on each, because that governs what your report can claim; (c) list the deleted files with fls -r -d -o <offset> <image>, recording the count, the metadata addresses of items of interest, and their surviving timestamps (you will need them for the Chapter 21 timeline); (d) recover the deleted files with icat/tsk_recover to a separate output directory, hashing each recovered file into your evidence manifest; (e) document the exact commands and tool versions so another examiner can reproduce your output against the same image hash. Finally, write one sentence committing to this chapter's Ethics Note — that during verification you look only at what confirms recoverability, and not one file more. Submit the chain-of-custody form, the full command log, and the hashed evidence manifest as the deliverables for this milestone of your case file.

Self-check. You have mastered this chapter when you can look at a deleted file on any of the three file systems and predict — before running a tool — exactly what will come back and what will not, and when imaging first has become reflex rather than a step you remember. If labs 6.15–6.19 ran cleanly on your own practice image, and you decoded the data run in 6.10 and read the MFT flags in 6.9 by hand without peeking, you are ready for Chapter 7 — File Carving, where you recover what the file system can no longer help you find.