Chapter 4 — Exercises

Thirty problems in seven groups (A–G), mixing concept checks, by-hand parsing of real on-disk structures (partition entries, MFT records, inodes, data runs, directory entries), judgment calls about which recovery route a given file system supports, and hands-on labs ("walk this image with The Sleuth Kit," "build the timeline," "write the report"). Parse the structures on paper before you reach for a tool — the byte-level fluency you build here is what separates an examiner who understands a file system from one who merely runs software that does. (answer in Appendix) marks problems with a full worked solution in Answers to Selected Exercises. ⭐ marks a stretch problem that pushes past the chapter. Keep your written work; several problems feed directly into your Forensic Case File.

Group A — What a file system does, and the partition table

4.1 A file system does four jobs. (a) Name all four (the chapter calls them namespace, space, metadata, and integrity management) and give a one-sentence description of each. (b) A quick format "destroys the file system" in four seconds — which of the four jobs' bookkeeping does it throw away and rewrite, and which job's underlying data (the actual file content) does it leave physically untouched? (c) In one sentence, state why that split is the foundation of both data recovery and digital forensics. (answer in Appendix)

4.2 A 16-byte MBR partition entry, read from offset 446 of LBA 0, contains these bytes:

00 20 21 00 83 FE FF FF 00 08 00 00 00 00 20 00

(a) Read the boot indicator (byte 0) — is this partition marked bootable? (b) Read the partition type (byte 4) and name the file system it implies. (c) The LBA of the first sector is bytes 8–11, little-endian — compute it in decimal. (d) The sector count is bytes 12–15, little-endian — compute it, then compute the partition's size in bytes and in GiB. (e) Why do you read bytes 8–11 little-endian here, and what would you have computed had you read them big-endian by mistake? (answer in Appendix)

4.3 ⭐ MBR has two hard limits an examiner must recognize on sight. (a) Using the fact that the LBA fields are 32 bits and sectors are 512 bytes, compute the maximum disk size MBR can address, and confirm it is roughly 2.2 TB. (b) MBR allows only four primary partitions; explain the mechanism (extended + logical partitions, type 0x05/0x0F) used to get more, and why that chain is a frequent recovery target. (c) A 6 TB disk is handed to you reporting a single MBR partition of about 2.2 TB. What is the most likely explanation, and what scheme should a disk that size be using?

4.4 GPT is the modern scheme. (a) What two-structure redundancy makes GPT more robust than MBR, and where on the disk does the backup live? (b) What 8-byte ASCII signature begins the GPT header at LBA 1, and what are its hex bytes? (c) Match each partition-type GUID to what it marks: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, 0FC63DAF-8483-4772-8E79-3D69D8477DE4, C12A7328-F81F-11D2-BA4B-00A0C93EC93B, 7C3457EF-0000-11AA-AA11-00306543ECAC. (d) Why does a GPT disk still carry a "protective MBR" at LBA 0, and what would happen without it? (e) GPT checksums both the header and the entry array with CRC32; explain how a tool uses those checksums to decide whether to trust the primary header or fall back to the backup, and why that makes silent partition-table corruption far less dangerous than on MBR.

4.5 (Judgment — recovery vs. forensics.) A disk arrives with a wiped or corrupted partition table; the operating system shows it as raw/unallocated. (a) Describe the recovery technician's move (which tool, what it does to the disk). (b) Describe the forensic examiner's opposite reflex (what they refuse to do, what they document instead). (c) Explain why a missing partition table can itself be a finding in an investigation. (d) Which recurring theme makes the examiner able to be patient where the recovery tech must be fast?

Group B — NTFS: the MFT and the anatomy of a record

4.6 The byte at offset 0x16 of an MFT record header — the flags field — is "the one that decides deleted or not." (a) Which bit value means the record is in use (a live file), and which additional flag value marks a directory? (b) When that in-use bit is cleared by a deletion, what happens to the rest of the record's contents — the name, timestamps, and data runs? (c) Explain, in two sentences, why this single bit is the reason NTFS is the most forgiving major file system to recover from. (answer in Appendix)

4.7 Every MFT record begins with a 4-byte signature. (a) Give the ASCII signature and its hex bytes. (b) What is the default size of an MFT record in bytes, and where in the boot sector is that size encoded (note the signed-byte trick at offset 0x40)? (c) The record header carries a sequence number that increments each time the entry is reused. Explain what a high sequence number tells a forensic examiner about how "busy" that slot has been, and why it matters when you are trying to prove a specific file once lived there.

4.8 Below is an abbreviated istat-style summary of a single MFT record. Read it and answer:

MFT Entry: 9871   Sequence: 4
Flags: (none set)            <- in-use bit is CLEAR
$STANDARD_INFORMATION: present
$FILE_NAME: "IMG_0423.JPG"  parent: 9803
$DATA: non-resident, 3 cluster runs, logical size 4,210,688 bytes

(a) Is this file live or deleted, and how do you know from one field? (b) Is its content likely recoverable, and by what mechanism — name the attribute that makes it possible? (c) The $DATA is non-resident with three runs; what does "non-resident" mean and why does the run count of 3 tell you the file is fragmented? (d) Which TSK command would pull this file's bytes back, and what address would you give it? (e) The record's parent is entry 9803. Explain what the parent reference lets you reconstruct about where the file lived, and what you would do if fls showed entry 9803 itself as deleted (hint: orphans).

Group C — NTFS attributes, data runs, streams, and journals

4.9 ⭐ A file is "a bag of attributes." Match each attribute type code to its role and say whether it is normally resident: 0x10 ($STANDARD_INFORMATION), `0x30` ($FILE_NAME), 0x80 ($DATA), `0x90`/`0xA0` ($INDEX_ROOT / $INDEX_ALLOCATION). (b) A 200-byte text file and a 4 GB video both have a `$DATA` attribute, but they are stored completely differently. Explain resident vs. non-resident and state which file is which. (c) What delightful recovery consequence follows from a small deleted text file being resident?

4.10 Decode this NTFS data run and state plainly what it means: 21 18 34 56 00. (a) Break down the header byte 21 into its low and high nibbles and say what each counts. (b) Read the length field and the starting-cluster (LCN) field, remembering the LCN is little-endian. (c) State the run in plain English ("N clusters starting at cluster M") and compute how many bytes it maps if clusters are 4096 bytes. (d) Convert the run's starting LCN to an absolute byte offset in the disk image, given that the partition starts at sector 2048, sectors are 512 bytes, and there are 8 sectors per cluster — use the chapter's offset formula and show your work. (e) Why is being able to do (d) by hand the difference between trusting icat and being able to verify it independently in a hex editor? (answer in Appendix)

4.11 A fragmented file's $DATA holds this run list: 21 04 00 01 21 04 06 00 00. Decode both runs. (a) Give run 1 as "length clusters at LCN x." (b) Run 2's starting field is a signed delta from the previous run's start — apply it and give run 2's absolute LCN. (c) Identify the gap that proves the file is fragmented, and explain in one sentence why a recovery method that ignored the runs (pure carving) would risk stitching the wrong clusters together.

4.12 The two timestamp sets — $STANDARD_INFORMATION` (`$SI) and $FILE_NAME` (`$FN) — are the examiner's secret weapon. (a) Which set does Windows Explorer display, and which set can an ordinary user-space tool rewrite with a single API call? (b) Which set is normally written only by the kernel on create/move/rename and is not exposed to ordinary timestamp-setting calls? (c) You find a record whose $SI` "modified" time is *earlier* than its `$FN "created" time. Explain why that ordering is a logical impossibility under normal operation and what it proves. (answer in Appendix)

4.13 Alternate Data Streams (ADS) exist because a file may have more than one $DATA` attribute. (a) Name the legitimate stream Windows attaches to downloaded files and state what investigative fact it records (including a source URL). (b) Give the colon syntax for a hidden stream and the `dir` switch that reveals streams plain `dir` hides. (c) Theme #3 says "every action leaves a trace" — explain how *hiding* an executable in an ADS is itself a trace rather than a perfect concealment. (d) A 4 KB document reports a logical size of 4 KB in Explorer but its MFT record lists two `$DATA attributes totaling far more; explain why the reported file size does not include the named stream, and which two tools from the chapter (one PowerShell, one TSK) would surface the discrepancy.

4.14 NTFS "keeps a diary" in two metafiles. (a) Name the two journals and where $UsnJrnl` lives (entry, path, and the stream it is read from). (b) State the single most powerful thing the `$UsnJrnl can prove that a surviving MFT record often cannot — specifically about a file whose MFT entry has since been reused. (c) Name two USN reason flags and explain how they let you reconstruct that a file was created, renamed, then deleted. (answer in Appendix)

Group D — ext4: inodes, extents, the journal, and why recovery is hard

4.15 The ext4 inode is "the analog of the MFT record with one enormous difference." (a) What does the inode conspicuously lack that the MFT record contains, and where does that information actually live? (b) Why does this single fact mean a recovered inode can give you a file's content but not, by itself, its name or path? (c) One inode can be referenced by several names; what field counts these, and what value of it signals "this inode has been freed"?

4.16 Two inode fields are deletion flags. (a) i_dtime is normally zero on a live file — what does a nonzero i_dtime on an inode whose bitmap bit is clear tell you? (b) i_links_count reaching what value triggers the inode's release? (c) ext4 tracks four timestamps; name them and flag the common trap (which one is not a creation time, and which extra field actually holds true creation time). (d) A junior examiner reports "the file was created at the ctime." Correct them: what does ctime actually record, how does it differ from mtime, and where would you look for the genuine creation time on an ext4 volume whose inodes are 256 bytes?

4.17 ⭐ The ext-family deletion behavior changed across versions, and the history explains why modern recovery is hard. (a) What did ext2 leave intact on delete that allowed debugfs undelete to work? (b) What did ext3 deliberately do to the inode's block pointers, and what side effect did it have on undeletion? (c) Why is ext4 with extents similarly hostile to inode-based recovery? (d) Given all that, state the ordered three-step ext4 recovery strategy from the chapter (journal → directory-entry name salvage → carving) and say what each step recovers.

4.18 The ext4 journal is your recovery lifeline and a time bomb. (a) The journal (jbd2) frequently holds a recent past copy of an inode — why is that copy more valuable than the current deleted inode for recovery? (b) The journal is a fixed-size ring buffer; explain what "wrapping" does to your recovery window, even if you never touch the disk. (c) Name the operational consequence: what is the single most important thing to do to an ext4 volume the moment you learn a needed file was deleted, and which recurring theme does it serve? (answer in Appendix)

Group E — APFS, FAT/exFAT, and HFS+

4.19 A FAT volume "tells you where a file starts; the FAT tells you the rest of the chain." Deletion does two things, and the second is the trap. (a) What specific byte value is written into the first character of the directory entry, and why does this cause undeleted files to show as _ILENAME.JPG? (b) What happens to the file's FAT chain entries? (c) The directory entry keeps two facts — name them. (d) Explain precisely why a contiguous deleted file recovers trivially while a fragmented one degrades to guesswork or carving. (answer in Appendix)

4.20 Parse this 32-byte FAT short (8.3) directory entry:

00000000: 5245 504f 5254 2020 5458 5420 0000 0000  REPORT  TXT ....
00000010: 0000 0000 0000 0000 0000 0a00 0004 0000  ................

(a) Read the 8.3 name and give the human-readable filename. (b) Read the first cluster (combine the HIGH word at 0x14 with the LOW word at 0x1A, each little-endian). (c) Read the file size at 0x1C (little-endian). (d) With 4096-byte clusters, how many clusters does this file occupy, and is it contiguous? (e) If this entry were deleted, write the two on-disk changes and explain why recovery here would be trivial. (f) Now suppose the file had been 12,000 bytes and fragmented across clusters 10, 14, and 15. After deletion, what exactly would you no longer know, and why does that single missing fact turn a trivial recovery into a carving problem? (g) Long file names are stored in extra entries with attribute 0x0F that precede the 8.3 entry — explain why a recovery tool can sometimes restore a deleted file's full long name even though the 8.3 entry's first character was clobbered by 0xE5.

4.21 ⭐ exFAT improves on FAT32 in two ways that help recovery. (a) Instead of scanning the FAT for free space, exFAT uses what structure (shared with NTFS/ext4)? (b) Explain the NoFatChain flag and why a contiguous file that sets it carries its entire block map in the directory entry alone — surviving deletion better than FAT32's zeroed chain. (c) exFAT entry sets use typed records with a high "in-use" bit; show what happens to the type bytes 0x85 (File), 0xC0 (Stream Extension), and 0xC1 (File Name) on deletion, and explain how recovery tools scan for the cleared-bit signatures. (d) Which of the three entry types holds the start cluster and length, and why does its survival explain why a deleted-but-contiguous SDXC video usually comes back clean?

4.22 APFS tells "a more pessimistic story than NTFS." (a) Give the magic for the APFS container superblock and the volume superblock. (b) State the overriding reason freed blocks usually do not survive on APFS, naming the underlying storage behavior. (c) Name the two APFS features that do preserve prior state and are therefore your best recovery and forensic sources, and explain why copy-on-write is what makes one of them instant and space-free.

4.23 HFS+ is "the file system you will still meet." (a) Give one very common modern device where you will still encounter HFS+ rather than APFS, and explain why that makes HFS+ more relevant than its 2017 retirement suggests. (b) Name the HFS+ master index (the B-tree mapping every file/folder by CNID to its metadata). (c) What is the typical HFS+ recovery route when the catalog records for a file are gone? (answer in Appendix)

Group F — What "deleted" means, across file systems

4.24 Reproduce the chapter's master comparison from memory for four file systems. For NTFS, FAT32, ext4, and APFS, fill a four-column table: (1) what the system does on delete, (2) what survives and is recoverable, (3) the primary recovery route, (4) the gotcha. Then write one sentence explaining the column you would read first when a job lands on your bench, and why. Finally, reading down the "what survives" column, arrange the four file systems on a spectrum from "keeps the entire map" to "burns the map," and state where the storage technology underneath (HDD vs. TRIM-enabled SSD) can move a file system's real-world position on that spectrum. (answer in Appendix)

4.25 (Judgment.) For each device, state the file system you'd expect, what "deleted" will mean on it, the recovery route you'd reach for first, and your honest prognosis: (a) a 64 GB SDXC card from a camera, files deleted yesterday; (b) a Linux web server's /var/www on ext4, a directory rm'd 20 minutes ago and the server still running; (c) a 2024 MacBook's internal volume, a document trashed last week; (d) a Windows 10 laptop's HDD (not SSD), files Shift-Deleted last month. Rank the four from most to least recoverable and justify the ranking in one sentence. Then state, for the two cases where the storage technology (not the file system) is the dominant factor in your prognosis, which underlying mechanism — magnetic persistence, TRIM, or the journal ring buffer — controls the outcome and why.

4.26 ⭐ (Ethics.) While walking an authorized NTFS image with fls, you surface a deleted directory and its orphaned children that plainly fall outside your engagement's scope — they concern a different matter and a different person. (a) State what you should and should not do next. (b) Distinguish "I found it while doing authorized work" from "I went looking for it," and explain why the former does not license you to act on the latter's terms. (c) Name the principle from this chapter and the later chapter (Chapter 28 — Ethics) that governs incidental, out-of-scope finds.

Group G — Hands-on labs and the Progressive Project

4.27 (Lab — walk this image with The Sleuth Kit.) Using any NTFS practice image (see Appendix J — Practice Images and Lab Setup) opened read-only, run the five-step pipeline and record the output of each: (a) mmls — note the partition scheme and the NTFS partition's start sector; (b) fsstat -o <start> — note the file-system type and the cluster size; (c) fls -o <start> -r -p — find one entry flagged * (deleted) and copy its metadata address; (d) icat -o <start> <addr> — recover it to a file; (e) verify with file and a SHA-256 hash. State which one piece of fsstat output you would have needed for any hand-done offset arithmetic. (f) Decode the TSK metadata address 9871-128-4 into its three components and explain what each says about the attribute you are recovering. (g) TSK reads the image read-only by design — explain why that property, not just your own discipline, is what lets you re-hash the image afterward and prove nothing changed. (answer in Appendix)

4.28 (Lab — recover from a formatted volume.) On a practice image of a quick-formatted NTFS volume: (a) run fls -o <start> -r -p and look specifically for entries under the synthetic $OrphanFiles folder; (b) explain why a quick format leaves these orphaned records while a full format would not; (c) icat two orphans back and confirm they open; (d) write one sentence for your notes stating where, on this image, metadata recovery ends and carving (Chapter 7) would have to begin. (e) The new (empty) MFT was written near the front of the volume and clobbered the first slice of the old MFT. Explain, in terms of the wedding-photos worked example, why this means the earliest files are the ones you must carve while later files come back named via their surviving records.

4.29 (Lab — build the timeline / detect timestomping.) Pick a file on an NTFS practice image and run istat -o <start> <addr>. (a) Record both timestamp sets, $STANDARD_INFORMATION` and `$FILE_NAME. (b) State whether they agree. (c) Describe the two specific patterns that would flag timestomping — a $SI` time *earlier* than the matching `$FN time, and suspiciously round $SI` times against precise `$FN times. (d) Name the independent corroborating source you would consult before resting any conclusion on the timestamps, and why a single artifact is never enough. (e) Write the one-sentence finding two ways: the over-claimed version ("the suspect backdated this file") and the defensible version that states the observed contradiction and the corroboration without asserting more than the artifacts prove. Explain what makes the second version survive cross-examination.

4.30 ⭐ (Lab — write the report / Progressive Project: characterize your evidence.) Using the verified image you will acquire in Chapter 5 (for now, any practice image): (1) run mmls and record the partition scheme (MBR/GPT), each partition's start sector, length, and type, noting whether a backup GPT is present; (2) for each partition run fsstat and record the file-system type, cluster/block size, and volume serial number; (3) write the one-paragraph media profile that opens your report's "Examined Media" section ("Evidence item 1 is a [GPT/MBR] disk containing N partitions; partition 2 is [NTFS/ext4/APFS/exFAT] with X-byte clusters, volume serial Y"); (4) for each file system found, write one sentence pre-committing what "deleted" will mean and which recovery route (surviving-record, start+size, journal/snapshot, or carving) you expect to use. Keep this profile — Chapter 6 builds directly on it. (Templates: Appendix F.)

Self-check. You have mastered this chapter when you can parse an MBR or GPT entry from a raw dump, read an MFT record's in-use flag and decode its data runs by hand, explain why an ext4 inode cannot lead you to a file's name and why its deletion sends you to the journal, and state — without hesitating — exactly what "deleted" means on NTFS, FAT/exFAT, ext4, APFS, and HFS+ along with the matching recovery route. If the data-run decoding in 4.10–4.11 or the deletion comparison in 4.24 still feels slow, drill them until they are automatic; every recovery chapter in Part II and every artifact chapter in Part III assumes this fluency. Next, turn these recovery instincts into a defensible method in Chapter 5 — The Forensic Process — where "I found this" becomes "I can prove I found this, unaltered."