Answers to Selected Exercises

Purpose. Worked solutions to the exercises marked (answer in Appendix) throughout the book — one representative cluster per chapter, restated briefly and solved in the book's voice so you can check both your answer and your reasoning. Where an exercise is a calculation, the arithmetic is shown in full; where it is a judgment call, the model answer states the finding, names the limit, and stops.

This is a study aid, not an answer bank to copy. The unmarked and ⭐ exercises are deliberately left open. Three references are used so often below that they are collected here once: file signatures live in Appendix A — File Signatures Reference, reusable scripts in Appendix B — Python Forensics Toolkit, and command syntax in Appendix H — Command-Line Reference.

Timestamp epoch reference (used in Ch. 18, 19, 20, 21, 24)

More wrong timelines come from epoch errors than from missing data. Keep this beside the keyboard.

A timestamp is a number plus a convention: get the epoch or the time zone wrong and the number is worse than useless because it looks authoritative.

Chapter 1 — Two Disciplines, One Technical Foundation

See ../part-1-foundations/chapter-01-two-disciplines/index.md.

1.1 — Define each discipline; underline the distinguishing phrase. Data recovery is the practice of restoring access to data that has become inaccessible through deletion, corruption, formatting, or hardware failure. Digital forensics is the practice of identifying, preserving, analyzing, and presenting digital evidence in a manner admissible in a legal proceeding. The distinguishing phrase for recovery is restoring access (the goal is the data itself); for forensics it is admissible in a legal proceeding (the goal is provable, defensible truth about the data). The same act — pulling a deleted file off a disk — serves both, which is why they share a technical core but diverge in discipline.

1.20 / 1.21 — Sector-to-byte arithmetic. The master equation is byte offset = LBA × sector size. - 1.20: LBA 2,048 on a 512-byte-sector drive → 2048 × 512 = 1,048,576 bytes = 0x100000 = 1 MiB. This is the conventional first-partition offset on modern GPT disks; partitions are aligned to 1 MiB so that 4 KiB physical sectors and SSD pages never straddle a boundary. - 1.21: Data at LBA 1,000,000. (a) 512-byte sectors → 1,000,000 × 512 = 512,000,000 bytes. (b) 4Kn (4,096-byte) sectors → 1,000,000 × 4,096 = 4,096,000,000 bytes. The same logical address resolves to a different byte offset depending on sector size — which is exactly why you record the sector size before you seek into a raw image.

1.26 — Recoverable, unrecoverable, or it depends?

The pair (a) vs. (d) is the chapter's whole thesis in two lines: deletion is reversible, overwriting is not.

Chapter 2 — How Data Is Stored

See ../part-1-foundations/chapter-02-how-data-is-stored/index.md.

2.1 — The round trip for 0110 0001. (a) Nibbles: 0110 and 0001. (b) Hex digits: 0110 = 6, 0001 = 1. (c) 0x61. (d) Decimal place-value: 0×128 + 1×64 + 1×32 + 0×16 + 0×8 + 0×4 + 0×2 + 1×1 = 64 + 32 + 1 = 97. (e) ASCII 97 = 'a'. The binary → hex → decimal → character cycle is the single most basic literacy in the book; run it without a tool.

2.4 — Hex/decimal both directions. 0x1F4 = 1×256 + 15×16 + 4×1 = 256 + 240 + 4 = 500. Back: 500 ÷ 16 = 31 r 4 (LSD = 4); 31 ÷ 16 = 1 r 15 (= F); 1 ÷ 16 = 0 r 1. Reading remainders bottom-up: 1 F 4 → 0x1F4. The answers agree.

2.10 — Endianness on an NTFS field E8 03 00 00. (a) Little-endian (NTFS convention): reverse the bytes to 00 00 03 E8 = 0x000003E8 = 1000. (b) Read big-endian by mistake: 0xE8030000 = 3,892,314,112. (c) Lesson: a parsed value that looks absurd (a four-byte "cluster count" of nearly four billion on a small volume) is itself a diagnostic clue — it usually means you read the byte order, the field width, or the field's meaning wrong.

2.17 — Partition start at LBA 2048. (a) 2048 × 512 = 1,048,576 bytes. (b) Decimal 1,048,576; hex 0x100000; 1,048,576 ÷ 1,048,576 = 1 MiB. (c) Tools start partitions here for 1 MiB alignment, so logical clusters line up with 4 KiB physical sectors and SSD erase pages — misalignment forces read-modify-write cycles that cost performance and endurance.

Chapter 3 — Storage Technology

See ../part-1-foundations/chapter-03-storage-technology/index.md.

3.4(f) — The service area (System Area). Beyond the platters, heads, actuator/voice-coil, spindle motor, and PCB, the service area is a reserved region on the platters (not in user LBA space) holding firmware modules, the defect lists (P-list and G-list), adaptive head/preamp calibration parameters, and the translator that maps LBAs to physical cylinder/head/sector locations. If the translator or a critical firmware module is corrupt, the drive cannot map user requests and reports 0 bytes / 0 LBA capacity even though every byte of user data is intact on the platters — a firmware-repair job (PC-3000-class tooling), not a clean-room job.

3.9 — The bits-per-cell ladder. (a) SLC = 1 bit / 2 voltage states; MLC = 2 bits / 4 states; TLC = 3 bits / 8 states; QLC = 4 bits / 16 states. (b) "The windows get narrower": squeezing 16 distinguishable charge levels into the same physical voltage range makes each level's margin tiny, so reads need finer sensing (slower) and small charge leakage flips a level (more errors, fewer program/erase cycles before the cell is unreliable). (c) Two clawbacks: SLC caching (treat a fast SLC region as a write buffer) and stronger ECC / LDPC error correction. This is the same noise-immunity argument that made two-state storage attractive in the first place.

RAID-capacity exercise — usable space, fault tolerance, minimum disks. For n disks of size S:

RAID 0 is fastest with no protection; RAID 1 (and 10) give the cleanest, fastest rebuild (straight copy, no parity recalculation).

Chapter 4 — File Systems

See ../part-1-foundations/chapter-04-file-systems/index.md.

4.14 — NTFS's two journals. (a) The two metafiles are $LogFile`** (transaction journal for file-system consistency) and the **`$UsnJrnl change journal. $UsnJrnl` lives in MFT-referenced metadata at path **`\$Extend\$UsnJrnl`**, and the records are read from its **`$J alternate data stream (its size cap is in $Max). (b) Its most powerful proof: because it logs changes by file reference number and name, it can establish that a file existed, was created/renamed/deleted even after its MFT entry has been reused** by another file — the surviving MFT record alone cannot tell you about a file that no longer owns its entry. (c) USN reason flags such as USN_REASON_FILE_CREATE, USN_REASON_RENAME_OLD_NAME / RENAME_NEW_NAME, and USN_REASON_FILE_DELETE, read in sequence, let you reconstruct "created → renamed → deleted" as a dated chain.

4.23 — HFS+, the file system you still meet. (a) You still meet HFS+ on Time Machine backup drives (Apple kept Time Machine on HFS+ for mechanical disks well after APFS shipped in 2017), and on older external drives and bootable clones — so it long outlived its desktop "retirement." (b) The master index is the Catalog File, a B-tree keyed by CNID (Catalog Node ID) that maps every file and folder to its metadata. (c) When the catalog records for a file are gone, the recovery route is file carving by signature (Ch. 7), supplemented by the Attributes File and journal where they survive.

Chapter 5 — The Forensic Process

See ../part-1-foundations/chapter-05-the-forensic-process/index.md.

5.1 — The four phases and their cousins. This book's phases: Acquisition (obtain a verified copy of the evidence), Preservation (protect the original and the copy from change), Analysis (extract and interpret the data), Reporting (communicate findings defensibly). Mapped to NIST SP 800-86: Collection → Examination → Analysis → Reporting (NIST folds preservation into collection and splits examination from analysis). Mapped to the four ACPO principles: (1) don't change the data; (2) if you must access original data, be competent and explain it; (3) keep an audit trail another examiner could follow; (4) the case officer is responsible for compliance. The thing the process diagram shows running underneath all four phases is documentation / chain of custody — it is not a fifth phase because it is not something you finish and move past; it is continuous, recorded at every step in every phase.

5.x — The chain-of-custody gap. Lay the log in the standard columns:

Date/Time           Released by   Received by   Purpose            Signature(s)
2024-03-10 09:15    Det. Alvarez  J. Park (exam) Imaging            AA / JP
2024-03-10 17:40    J. Park       Evidence room  Storage            JP / EV
2024-03-13 ??:??    (no entry)    (no entry)     —                  —          <-- GAP
2024-03-14 08:05    Evidence room J. Park        Continued analysis EV / JP

(a) The cross-examiner asks: who had this drive, and what did they do to it, during the undocumented window? (b) The maxim violated: if it isn't documented, it didn't happen (and conversely, an undocumented custody window cannot be vouched for). (c) The corrective entry that should have existed names the releaser, the receiver, the date/time, the purpose, and both signatures for each transfer. (d) The defense does not have to prove tampering — a gap shifts the burden by creating reasonable doubt about integrity; the evidence's weight (and sometimes admissibility) suffers from the possibility alone.

Chapter 6 — Logical Recovery

See ../part-2-data-recovery/chapter-06-logical-recovery/index.md.

6.1 — Explaining a "formatted" drive to a frightened client (no jargon). "When the drive was formatted, the computer did not erase your photographs. It rewrote the table of contents — the index that says where each photo lives — so the drive now looks empty. The pictures themselves are still sitting in place, the way the chapters of a book remain even if you tear out the index page. They stay there until something new is written on top of them. So the one thing I need you to do is stop using this drive immediately — don't save to it, don't 'repair' it, ideally don't even leave it plugged in — because every new file the computer writes could land on top of a photo and overwrite it for good. Bring it to me as it is, and we image it first so we're always working on a copy, never the only surviving original." This answer carries themes one (deleted ≠ destroyed) and two (the original is sacred) without ever saying their names.

Chapter 7 — File Carving

See ../part-2-data-recovery/chapter-07-file-carving/index.md.

7.4 — Three carving strategies and their shared assumption. Header–footer carving (read from a known start signature to a known end signature — JPEG FF D8 … FF D9); header–maximum-size carving (start at the header, stop at a type-specific size cap when there is no footer — many RAW or audio formats); file-structure / semantic carving (parse the format's internal length fields to find the true end — ZIP/PDF/MP4). The assumption all three silently share is contiguity — that a file's bytes are laid out in one unbroken run. When the file is fragmented, every naive carver fails, splicing in foreign data or truncating at the gap.

7.12 — GiB vs GB and sector count for 32212254720 bytes. GiB: 32,212,254,720 ÷ 2^30 (1,073,741,824) = 30.0 GiB exactly. GB: 32,212,254,720 ÷ 10^9 = 32.21 GB. The tool's "30.0 GB" label is therefore really 30 GiB (the binary number wearing a decimal unit). Sectors at 512 bytes: 32,212,254,720 ÷ 512 = 62,914,560 sectors.

7.14 — The nested-footer bug. A phone JPEG contains an embedded EXIF thumbnail, which is itself a complete little JPEG with its own FF D9 end marker before the full image's real FF D9. A naive "header → first FF D9" carver stops at the thumbnail's footer and truncates the photo. A structure-aware carver walks the JPEG segment markers (SOI → APPn → … → SOS → entropy-coded scan) and keeps going until the final FF D9 that closes the primary image, ignoring the thumbnail's footer.

7.24 — Three scalpel.conf lines. Format is extension case max-size header footer [REVERSE]:

gif    y    5000000    \x47\x49\x46\x38\x39\x61    \x00\x3b
png    y   20000000    \x89\x50\x4e\x47\x0d\x0a\x1a\x0a    \x49\x45\x4e\x44\xae\x42\x60\x82
pdf    y   50000000    %PDF    %%EOF    REVERSE

PDF and ZIP want REVERSE because they may contain many %%EOF / end-of-archive markers (incremental updates, appended objects); REVERSE searches backward from the size limit so the carve ends at the last footer — the true end of the file — rather than the first.

Chapter 8 — Hard Drive Recovery

See ../part-2-data-recovery/chapter-08-hard-drive-recovery/index.md.

8.5 — The single most consequential question. Is this failure physical or logical? The branches demand opposite reflexes. A logically failed drive (deleted/formatted/corrupt FS, healthy hardware) rewards more access: power it up, image it fully, even read it repeatedly. A physically failing drive (bad heads, seized motor, degrading platters) rewards less access: every spin-up risks turning a recoverable drive into scrap. Concrete crossover: running a full, repeated surface scan is a correct reflex on a logical case — and the wrong one on a head-degradation case, where the extra passes can crash a marginal head into the platter and destroy the data you were trying to read.

8.13 — Why dd is dangerous on an unstable drive. dd (and dcfldd) read sequentially and retry hard on errors: hitting a bad area, the driver re-reads the same failing sectors many times, hammering a weak head and stressing the drive — it can kill the patient before ever reaching the readable majority. ddrescue does two things differently: (1) it reads the good areas first at full speed and only returns to scrape difficult areas later, in shrinking passes; and (2) it keeps a mapfile recording exactly which regions are done, bad, or untried. The mapfile is what lets you stop and resume across power cycles — even swap to a clone of the drive — without ever re-reading good data, so every minute of fragile drive-life buys new sectors, not repeats.

Chapter 9 — SSD and Flash Recovery

See ../part-2-data-recovery/chapter-09-ssd-and-flash-recovery/index.md.

9.1 — Three facts that break "logical N = physical N." (1) The Flash Translation Layer (FTL) maps logical block addresses to physical NAND pages dynamically — there is no fixed correspondence, so "imaging the surface" reaches only what the controller chooses to expose. (2) Wear leveling moves data physically to spread erase wear — yesterday's data may sit somewhere new, and old copies linger in pages the host can't address. (3) Garbage collection + TRIM proactively erase blocks marked free — deleted data can vanish with no host involvement, even with a write blocker attached. Recovery consequence of each, respectively: you cannot bypass the controller to read raw user data normally; old versions may survive in unmapped pages (chip-off territory); deleted data is on a deletion countdown you cannot pause.

9.5 — The most important SSD questions and TRIM. Most important: Was TRIM active on this volume? Second: How long has the drive been powered since deletion? (garbage collection runs on power). TRIM is the ATA command by which the OS tells the SSD which logical blocks are no longer in use so the controller may erase them ahead of time; its SCSI equivalent is UNMAP and its NVMe equivalent is Deallocate (Dataset Management). Before TRIM, the controller only knew a block was free when the host overwrote it — so on a nearly full drive it had no pre-erased blocks ready and had to do slow read-modify-erase-write cycles on the write path, collapsing performance.

9.23 — Two images, two different hashes, nobody tampered. (a) Mechanism: the SSD's controller runs garbage collection and wear-leveling autonomously while powered, so the physical contents behind unallocated LBAs change between the two reads even with no host writes — the hashes differ legitimately. (b) The paper that named this for the field is Bell & Boddington (2010), "Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?" (c) The four professional responses: acquire immediately / minimize powered time (less time for GC to act); write-block anyway (close off host-side change and document diligence); hash file-resident data separately (allocated files are stable even when unallocated drifts, so per-file hashing still proves those files unchanged); document the medium's behavior (disclose in the report that SSD non-determinism, not tampering, explains any whole-disk hash variance — disclosing it first is what protects you).

Chapter 10 — RAID Recovery

See ../part-2-data-recovery/chapter-10-raid-recovery/index.md.

10.8 — XOR parity for two RAID-5 stripes. Parity P = D0 ⊕ D1 ⊕ D2.

Stripe 0: 0x3C ⊕ 0xA5 ⊕ 0x66

  0x3C = 0011 1100
  0xA5 = 1010 0101   XOR -> 1001 1001 = 0x99
  0x66 = 0110 0110   XOR -> 1111 1111 = 0xFF

Stripe 1: 0x0F ⊕ 0xF0 ⊕ 0xFF

  0x0F = 0000 1111
  0xF0 = 1111 0000   XOR -> 1111 1111 = 0xFF
  0xFF = 1111 1111   XOR -> 0000 0000 = 0x00

This is the whole magic of RAID 5: any one missing element is the XOR of the survivors, so a lost disk is rebuilt by re-XORing the rest.

10.17 — The degraded-rebuild cascade.

Day 0  All disks healthy.                 Redundancy budget: 1 fault.
Day 1  Disk fails. Array DEGRADED.        Budget: 0 — every read now needs all survivors.
Day 1  Hot spare begins rebuild.          Budget: 0 — full-stripe reads stress aging disks.
Day 2  A second disk throws a URE/fails   *** UNRECOVERABLE MOMENT ***
       mid-rebuild.                        RAID 5 cannot reconstruct two missing elements.
Day 2  Array OFFLINE.

The exact moment a fully recoverable situation becomes mathematically unrecoverable is the second fault while the array is already degraded — before the rebuild completes there is zero redundancy, which is why large RAID-5 arrays are dangerous (rebuild time + unrecoverable-read-error probability) and why RAID 6 (two-fault tolerance) exists.

Chapter 11 — Mobile Device Recovery

See ../part-2-data-recovery/chapter-11-mobile-device-recovery/index.md.

11.5 — The iOS Data-Protection key hierarchy. From passcode to bytes: the passcode-derived key is tangled (via a slow KDF) with the device's UID key to produce the passcode key; class keys in the keybag are wrapped by that passcode key (and by hardware keys); each file key (per-file AES key in the file's metadata) is wrapped by its class key; the file key encrypts the file's bytes in NAND. The crucial fact: the UID is a 256-bit AES key fused into the Secure Enclave / SoC silicon at manufacture — it can be used but never read out. Because the UID never leaves the chip, you cannot copy the encrypted NAND to a fast cluster and brute-force the passcode offline: every guess must be tangled with the UID on that specific device, which also rate-limits and escalates delays. That single fact is why mobile recovery so often depends on the device cooperating, not on raw compute.

11.14 — adb prerequisites and the /sdcard vs /data/data line. All three must be true before adb reads a non-rooted device's user data: (1) USB debugging enabled in Developer Options (protects against casual cable access); (2) the host's RSA key authorized on the device via the "Allow USB debugging?" prompt (protects against an unknown computer); (3) the device unlocked (protects data-at-rest behind the screen lock). Even then, adb pull /sdcard/DCIM succeeds while adb pull /data/data/com.whatsapp fails because /sdcard is shared, world-readable media storage whereas /data/data is app-private storage protected by per-app Linux UIDs/SELinux — the shared-vs-private boundary is the line. A /sdcard pull is forensically weak even when it works: it captures only media, not the app databases where the conversations and metadata live.

Chapter 12 — Ransomware Recovery

See ../part-2-data-recovery/chapter-12-ransomware-recovery/index.md.

12.5 — The first-hour phone checklist. Six actions, each replacing a wrong instinct:

The most counterintuitive, most-often-botched action is #1: leave the machines on but disconnected. People reflexively shut down "to stop it," destroying volatile evidence and any encryption keys still in memory (Ch. 22).

12.13 — Five recovery options, most to least reliable. (1) Restore from a known-good, offline backup — most reliable; the only true cure. (2) Volume Shadow Copies / system snapshots — reliable if the malware didn't delete them (it usually tries). (3) A free, legitimate decryptor (e.g., No More Ransom) — reliable only for cracked/older families. (4) Carving and recovering unencrypted remnants — slack space, temp files, partially-processed files — partial at best. (5) Pay the ransom — last resort, unreliable (no guarantee of a working key, funds crime, may breach OFAC sanctions). Skipping straight to "should we pay?" marks someone who hasn't worked options 1–4 — which is where the actual, lawful, reliable recovery lives.

Chapter 13 — The Data Recovery Business

See ../part-2-data-recovery/chapter-13-the-data-recovery-business/index.md.

13.4 — A Tier-1 logical bench (illustrative figures). Verify current pricing yourself; the point is the shape of the number.

That figure is "the floor under every quote you will ever give" because it is the fixed cost of being able to do a job safely at all — it must be amortized across jobs before a single recovery turns a profit, and undercutting it means cutting the safety it buys.

13.11 — Three pricing models. Flat fee — predictable for clients; fails when a "simple" job turns invasive (you eat the loss or cut corners). Tiered by difficulty — matches price to effort; fails if tiers are vague or you misclassify on intake. No-data-no-charge (NDNC) — humane and trust-building; fails as a pure model because evaluation/cleanroom time has real cost someone must cover. "Tiered, with NDNC and a firm quote before any billable work" is the honest consumer standard because it aligns price with actual difficulty, protects the client from paying for failure, and removes surprise. A pure flat fee is honest "only if your work is genuinely uniform — which recovery never is," since two visually identical drives can be a ten-minute logical job or a multi-day head swap.

Chapter 14 — Forensic Acquisition

See ../part-3-digital-forensics/chapter-14-forensic-acquisition/index.md.

14.3 — Capacity math for 500,118,192 sectors. (a) 500,118,192 × 512 = 256,060,514,304 bytes. Decimal GB: ÷ 10^9 = 256.06 GB. Binary GiB: ÷ 2^30 = 238.47 GiB. (b) A "256 GB" drive shows as ~238.5 GiB because the maker counts in decimal GB while your tool reports binary GiB — same bytes, different unit. (c) Destination has 240 GiB free: a raw image needs 238.47 GiB → yes, it fits (with ~1.5 GiB to spare). A compressed E01 stores the same evidence smaller (empty/repetitive regions compress), so it also fits, usually with far more headroom. Always reason in bytes before trusting a GB/GiB label.

14.18 — 47 files sharing MD5 d41d8cd98f00b204e9800998ecf8427e. (a) Without computing anything: that is the MD5 of a zero-length (empty) file. All 47 files are empty. (b) Their SHA-256 would be the empty-file constant e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. (c) Recognizing these constants is a triage skill: it lets you instantly dismiss "matching hashes" that mean nothing was there, and it flags placeholder/zeroed files at a glance instead of opening each one.

14.28 — A powered-on machine with an unlocked FDE volume. (a) The dilemma in one sentence: pull the plug and you get a perfect image of unreadable ciphertext; keep it running and you preserve the decrypted state but accept a live, non-atomic acquisition. (b) Pulling the plug preserves a clean, hashable image but destroys your access to plaintext (the keys evaporate from RAM). Keeping it running preserves the decrypted volume and the keys in memory but destroys the "untouched original" purity (you must write to the running system or capture live). (c) This pushes you toward capture RAM first (to grab the keys), then image the unlocked volume live, documenting every step — the workflow owned by Ch. 15 — Live Response and Triage and Ch. 29 — Encrypted Device Forensics.

Chapter 15 — Live Response and Triage Forensics

See ../part-3-digital-forensics/chapter-15-live-response-and-triage/index.md.

15.1 — RFC 3227 order of volatility. Most to least volatile, with one artifact each:

(a) The ladder makes one decision easy under pressure: what to grab first when you cannot grab everything — capture the thing that disappears soonest. (b) "Collect top-down" means run your most volatile-targeting tools first (RAM capture, then netstat/connection state, then process listing) before anything that touches disk, because disk survives and RAM does not.

15.10 — What a dead-box vs. live SHA-256 proves. A dead-box image hashed with SHA-256 proves "bit-for-bit copy of the original" — the source was static (write-blocked, powered off), so the hash binds the image to an unchanging original. A live image's hash cannot make that claim because the system was changing as you read it; the image is a smear across time. (a) The defensible claim for a live image is "integrity from the moment of acquisition forward" — i.e., nothing has changed since you captured it, provable by re-hashing your image. (b) "Bit-for-bit copy of the original" is not available because there was no single, frozen "original" state to copy. (c) Disclosing this first, in your report, strengthens you: you look like the careful examiner who understands the medium, leaving the cross-examiner nothing to "expose" — state the finding, name the limit, stop.

15.20 — Triage at scale. (a) 1,000 machines × 500 GB = 500 TB to store; at a sustained ~150 MB/s per imaging stream that's ~55 minutes/machine, so even ten parallel imagers run ~3.5 days of pure copy time, before analysis. (b) Disciplined triage is "the rigor applied to scale," not a shortcut: it collects the high-value, low-volume artifacts (memory, registry, event logs, prefetch, browser, EDR telemetry) from many hosts fast, and decides which few machines deserve full imaging. (c) The failure mode of the examiner who insists on full images of all 1,000 hosts: the investigation drowns in storage and time and the adversary keeps operating while you copy idle disks — thoroughness misapplied becomes negligence.

Chapter 16 — Windows Forensics

See ../part-3-digital-forensics/chapter-16-windows-forensics/index.md.

16.1 — The registry as a runtime assembly. It is not one database; the live registry is assembled at boot from several on-disk hive files plus volatile keys. The five machine-wide hives in C:\Windows\System32\config\ and the roots they mount:

On a dead-box image there is no HKEY_CURRENT_USER (that is a per-user view built at logon from each user's NTUSER.DAT in the profile, plus UsrClass.dat), and no CurrentControlSet (a runtime pointer). You instead read the on-disk control sets ControlSet001 / ControlSet002, and to learn which one was active at shutdown you check SYSTEM\Select\Current (and LastKnownGood).

16.5 — The three-key USB correlation chain.

1. SYSTEM\CurrentControlSet\Enum\USBSTOR\...        (hive: SYSTEM)   -> DEVICE SERIAL + model
        |
2. SYSTEM\MountedDevices  /  ...\DeviceClasses\{GUID}  (hive: SYSTEM) -> VOLUME GUID + drive letter
        |
3. NTUSER.DAT\...\Explorer\MountPoints2\{VOLUME-GUID}  (hive: per-user NTUSER.DAT) -> USER ATTRIBUTION

Step 1 (USBSTOR) gives the device serial; step 2 (MountedDevices / DeviceClasses) gives the volume GUID; step 3 (the user's MountPoints2, which contains that same volume GUID) proves this user account mounted *this volume* — and EMDMgmt/setupapi logs add first/last connection times.

16.10 — Event IDs and the .evtx signatures.

For 4624, the Logon Type (in the event data) is what matters more than the bare event: Type 2 = interactive (at the keyboard), 3 = network (SMB), 10 = RemoteInteractive (RDP) — "someone logged on" is far less useful than "someone logged on over RDP from elsewhere." The .evtx file signature is ElfFile\0 (45 6C 66 46 69 6C 65 00); carved fragments are recognized by the per-record marker ** (2A 2A 00 00) and the chunk header ElfChnk\0.

16.15 — Execution vs. presence.

Witness-stand compression: "Prefetch, UserAssist, and BAM tell me a program ran; Amcache and ShimCache tell me only that it was present on the system."

Chapter 17 — macOS and Linux Forensics

See ../part-3-digital-forensics/chapter-17-macos-and-linux-forensics/index.md.

17.14 — A file beginning 62 70 6C 69 73 74 30 30. (a) Those bytes spell bplist00 — a binary property list. (b) A text editor shows garbage because the body is packed binary (offset tables, typed objects), not text; convert it with plutil -convert xml1 -o - file.plist (or plistutil). (c) An XML plist instead begins with <?xml followed by the <!DOCTYPE plist …> declaration — human-readable from byte one. (d) Plists answer "what was configured / recently used / connected" — e.g., recent items, login items, and com.apple.wifi/known-networks; a concrete location is ~/Library/Preferences/com.apple.recentitems.plist (recently opened documents and servers).

17.21 — Why ext4 deletion is harder than NTFS. (a) On deletion ext4 (1) marks the inode free in the inode bitmap, (2) marks the data blocks free in the block bitmap, (3) decrements the link count, and (4) — the fatal one — zeroes the extent tree / block pointers in the inode, so the inode no longer says where the file's data was. (b) By contrast an NTFS MFT record retains the data runs (the $DATA run list) until the record is reused, so NTFS deleted-file recovery is often a simple matter of reading the still-present run list. (c) The consolation ext4 leaves is in the directory entry: the entry's bytes (filename and the inode number it pointed to) often survive in directory slack, letting you recover the filename and the former inode number — and from there, metadata if the inode hasn't been reused — even when the block map is gone. The journal (jbd2) sometimes holds a stale copy of the inode with its extents intact, which is the other route back.

17.25 — SQLite, where the chapter's threads meet. (a) When SQLite "deletes" a row it does not erase the bytes; it marks the cell free and links the page space onto the freelist — the old row content lingers in freelist pages and in unused (slack) areas of B-tree pages. (b) The sidecars are the -wal (write-ahead log) and -shm (shared-memory index). The -wal can contain committed-but-not-yet-checkpointed transactions and superseded older page images — rows and versions absent from the main .db. (c) Operational rule: always copy the .db together with its -wal and -shm and open read-only (ideally immutable=1) — merely opening the database with a default connection can checkpoint the WAL, changing the file and its hash. VACUUM is the enemy because it rewrites the database compactly, purging freelist pages and slack — the very places deleted rows survive.

Chapter 18 — Browser and Internet Forensics

See ../part-3-digital-forensics/chapter-18-browser-and-internet-forensics/index.md.

18.1 — SQLite magic and the WAL trap. (a) Every SQLite database begins with the 16-byte string SQLite format 3\0 = 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00. (b) In WAL mode recent changes live in the -wal file and have not yet been merged into History, so the file named History is often not the whole database; you must copy History-wal and History-shm alongside it. (c) Copying History alone in a case where the decisive activity happened in the last powered hour loses exactly that activity — the most recent, most relevant rows are the ones still sitting in the uncheckpointed WAL.

18.13 — Convert WebKit 13355010535000000 to UTC. Step 1: ÷ 1,000,000 = 13,355,010,535 seconds since 1601-01-01. Step 2: − 11,644,473,600 = 1,710,536,935 Unix seconds. Step 3: resolve 1,710,536,935 → 2024-03-15 21:08:55 UTC (sanity check: lands in March 2024 ✓). In the worked anchor case this is a saved-login date_last_used. Present it as "2024-03-15 21:08:55 UTC (Chromium/WebKit epoch)" — never as the bare integer, and never without the epoch name.

Chapter 19 — Email, Chat, and Social Media Forensics

See ../part-3-digital-forensics/chapter-19-email-chat-social-media-forensics/index.md.

19.1 — A file beginning 21 42 44 4E …. (a) 21 42 44 4E spells !BDN — the signature of a Microsoft Outlook PST/OST personal store. (b) The version word wVer sits at offset 0x0A; the bytes there are 0E 00, little-endian = 0x000E = 14, which denotes an ANSI store (Unicode PST uses wVer = 23). (c) The practical risk: an ANSI PST is capped near 2 GB, and stores at that ceiling are prone to corruption and refusal-to-open — a known recovery hazard.

19.24 — Three timestamp conversions (and the classic errors). - (a) WhatsApp 1700000000000 is milliseconds → ÷ 1000 = 1,700,000,000 s → 2023-11-14 22:13:20 UTC. Error avoided: treating ms as seconds (which throws you to the year ~55,000). - (b) Unix seconds 1710524400 → 2024-03-15 17:40:00 UTC. (Straight Unix; no offset.) - (c) Apple absolute 732218400 (seconds since 2001-01-01) → + 978,307,200 = 1,710,525,600 Unix s → 2024-03-15 18:00:00 UTC. Error avoided: forgetting the 2001-epoch offset (which lands you in 1993).

All three resolve to the same afternoon once the conventions are applied correctly — proof that the hard part is the convention, not the number.

Chapter 20 — Photo, Video, and Document Forensics

See ../part-3-digital-forensics/chapter-20-photo-video-document-forensics/index.md.

20.4 — Decode FF D8 FF E1 2A 7C 45 78 69 66 00 00 4D 4D 00 2A 00 00 00 08.

TIFF offsets are measured from the start of the TIFF header (the MM/II byte). The TIFF header begins at file offset 12, so IFD0 starts at file offset 12 + 8 = 20 (0x14). This differs from the chapter's little-endian (II) example only in byte order; misreading MM as II would byte-swap and corrupt every value you extract.

20.6 — EXIF GPS to decimal degrees. Latitude [(51,1),(30,1),(0,1)], ref N: 51 + 30/60 + 0/3600 = 51.500000; N is positive → +51.500000. Longitude [(0,1),(7,1),(39,1)], ref W: 0 + 7/60 + 39/3600 = 0.116667 + 0.010833 = 0.127500; W is negative → −0.127500. Final pair (51.500000, −0.127500) — central London (Westminster). Altitude (32,1) with GPSAltitudeRef = 0 → 32 m above sea level (ref = 1 would mean 32 m below sea level).

20.24 — Convert the MP4/QuickTime 1904 epoch 3822147843. (a) MP4 mvhd counts seconds since 1904-01-01; the constant to Unix is 2,082,844,800 s. (b) 3,822,147,843 − 2,082,844,800 = 1,739,303,043 Unix s → 2025-02-11 19:44:03 UTC (sanity: February 2025 ✓). (c) Besides mvhd, creation/modification times also appear in tkhd (track header) and mdhd (media header); Apple udta atoms (©day, ©xyz) store a date string and a GPS string. You must pass ExifTool -api QuickTimeUTC=1 because QuickTime dates are stored without a zone and ExifTool otherwise assumes local time, silently shifting your timeline.

Chapter 21 — Timeline Analysis

See ../part-3-digital-forensics/chapter-21-timeline-analysis/index.md.

21.1 — "A timestamp is a number plus a convention." The two parts of the convention you must know before a raw value means anything are the epoch (the zero point and the unit — see the reference table above) and the time zone (the offset, plus DST handling). Get the epoch wrong and an event lands in the wrong century (read a 1601-based FILETIME as if it were Unix seconds and you are off by ~369 years); get the precision/unit wrong and you manufacture false precision (read milliseconds as microseconds and a clean second becomes a meaningless sub-millisecond fraction). This — not finding timestamps, which tools do for you — is the hard part, because a confidently mislabeled time corrupts the entire reconstruction while still looking authoritative.

21.9 — The MACB model. M = modified (content last changed); A = accessed (content last read); C = changed — the metadata/MFT-record (inode) change time, not the file's creation time; B = born (created). The letter that trips everyone is C: people assume "C = created," but creation is B. C records when the metadata (permissions, name, MFT/inode fields) last changed. The Sleuth Kit's mactime tool fixed this vocabulary for the field by adopting the explicit MACB letters instead of the ambiguous everyday "created/modified/accessed," forcing examiners to say exactly which time they mean.

Chapter 22 — Memory Forensics

See ../part-3-digital-forensics/chapter-22-memory-forensics/index.md.

22.4 — Four on-disk sources of memory contents.

The closest to an atomic snapshot is the VM memory file captured while the guest is paused — the hypervisor freezes the entire guest at one instant, so it is a true point-in-time image (the hibernation file is the closest native equivalent, but it reflects the suspend moment, not "now").

22.12 — Pool tags to hex, and enumerate vs. scan. ASCII per character (P=0x50, r=0x72, …):

Enumerating walks the OS's official linked list of objects (e.g., pslist), so it sees only what the list admits. Scanning sweeps physical memory for the pool tag's byte signature (e.g., psscan), so it can find a structure that was unlinked from the list — exactly what rootkits do to hide a process. A tool can find by scan what the list omits, which is why you run both and treat the difference as a lead.

Chapter 23 — Network Forensics

See ../part-3-digital-forensics/chapter-23-network-forensics/index.md.

23.5 — A minimum-viable forensic tcpdump.

tcpdump -i eth0 -s 0 -n -w cap.pcap -C 1000 -W 50

• -i eth0 — capture interface.
• -s 0 — full snaplen (capture whole packets, not truncated headers) so payloads survive for later analysis.
• -n — no name resolution during capture (prevents the capture host generating its own DNS traffic and avoids skew/contamination).
• -w cap.pcap — write raw packets to file (analyze later; never analyze live).
• -C 1000 -W 50 — rotate at 1000 MB per file, 50-file ring, so a long run produces manageable, bounded files.

For a multi-day, high-rate capture the better engine is dumpcap:

dumpcap -i eth0 -w cap.pcapng -b filesize:1000000 -b files:200

dumpcap is purpose-built for capture (lower overhead, fewer drops, native ring-buffer) whereas tcpdump/tshark carry dissection machinery you don't want competing for CPU while packets are arriving.

23.14 — Wireshark display filters.

Filters (e) and (f) survive encryption because SNI is sent in the clear in the TLS ClientHello (before the session is encrypted), revealing the destination host even when payload is unreadable; and stream reassembly is metadata about the connection (endpoints, timing, byte counts, direction) that exists regardless of payload secrecy — you learn who talked to whom, when, and how much without reading a word.

Chapter 24 — Mobile Device Forensics

See ../part-3-digital-forensics/chapter-24-mobile-device-forensics/index.md.

24.9 — adb prerequisites and the storage line. All three must hold before adb reads a non-rooted Android's user data: (1) USB debugging enabled (guards against casual cable access); (2) the host's RSA key authorized on-device (guards against an unknown computer); (3) the device unlocked (guards data-at-rest behind the lock screen). adb pull /sdcard/DCIM succeeds where adb pull /data/data/com.whatsapp fails because /sdcard is shared, world-readable external storage while /data/data is per-app private storage isolated by Linux UID and SELinux — that shared-vs-private distinction is the line. A /sdcard pull sits at the bottom of the extraction pyramid (a logical/file-copy acquisition): it captures media but not the app databases, deleted records, or SQLite WAL contents, so it is forensically weak even when it works — and it acquires no unallocated space for deleted-data recovery.

Chapter 25 — The Legal Framework

See ../part-4-legal-framework-and-reporting/chapter-25-the-legal-framework/index.md.

25.11 — Public vs. private employer authority. For a public-sector employer the controlling case is O'Connor v. Ortega (1987): a government employee can have a reasonable expectation of privacy at work, and a workplace search is judged by reasonableness (at inception and in scope) rather than warrant-and-probable-cause; City of Ontario v. Quon (2010) applies that reasonableness standard to electronic communications (the texts on a government pager). For a private-sector employer the Fourth Amendment does not apply (no state action), but "anything goes" is wrong — three federal statutes still constrain: the ECPA / Stored Communications Act (stored communications and access), the Wiretap Act (real-time interception of communications), and the Computer Fraud and Abuse Act (authorized access), alongside state wiretap and privacy laws. Authority comes from policy, consent, and ownership, not from the absence of the Constitution.

25.x — Custody audit and FRE 902(14). (a)/(b) A one-character hash discrepancy between the acquisition value and the re-verification value is "a cross-examination gift" because a cryptographic hash has the avalanche property — a single changed bit flips ~half the digest — so any mismatch (even a typo in the log) invites the argument that the evidence is not what you say it is; the discrepancy must be found and explained (usually a transcription error, proven by re-hashing). (c) FRE 902(14) makes electronic data self-authenticating when it is "copied from an electronic device, storage medium, or file" and authenticated by a hash (or other reliable digital identification) certified by a qualified person — meaning a matching hash plus your written certification lets the image come in without live foundational testimony. The audit command that proves nothing changed:

hashdeep -a -k known-hashes.txt -r /evidence/    # -a audit mode against known set, recursive
# -> "hashdeep: Audit passed"

Chapter 26 — The Forensic Report

See ../part-4-legal-framework-and-reporting/chapter-26-the-forensic-report/index.md.

26.5 — Eight standard sections and the inverted pyramid.

The inverted-pyramid ordering puts the most important findings early (executive summary) and the densest proof late (appendices) because the report has three readers with different needs: the front matter serves the decision-makers (attorney, judge, executive) who need the bottom line fast, while the back matter serves the technical reviewer / opposing expert who must be able to reproduce and check every step. One document, both audiences, by ordering.

26.15 — Strip the three forbidden categories. A draft sentence such as "The defendant obviously downloaded these disgusting files on purpose to hide his guilt, and probably shared them too" contains all three things that must stay out of a forensic report: 1. Speculation / unsupported inference — "probably shared them too" (no evidence cited) and "to hide his guilt" (a mental-state claim, see FRE 704(b)). 2. Legal conclusion — "his guilt" is the jury's question, not the examiner's. 3. Emotive / characterizing language — "obviously," "disgusting."

Rewrite to what the evidence shows: "Forty-seven files matching the case hash set were recovered from the user profile jdoe at \Users\jdoe\Downloads\. File-system creation times fall between 2024-03-02 19:08 and 19:21 UTC. No evidence of further distribution was identified within the examined data." State the finding, name the limit, stop.

Chapter 27 — Expert Testimony

See ../part-4-legal-framework-and-reporting/chapter-27-expert-testimony/index.md.

27.1 — Fact witness vs. expert witness. A fact (lay) witness testifies to what they perceived and is governed by FRE 701; an expert witness may offer opinions based on specialized knowledge and is governed by FRE 702. (a) Fact-only sentence: "I attached the drive to a write-blocker and the imaging tool reported a matching SHA-256." Expert-only sentence: "The matching SHA-256 establishes the image is a bit-for-bit copy of the original." (b) You wear both hats in one case because you both did things (fact) and interpret them (expert); knowing which hat you wear at each moment keeps you inside what you're permitted to say. (c) The duty attached to the expert's privilege is objectivity / to assist the trier of fact, not the retaining side — and a competent cross-examiner spends the afternoon trying to show you forgot it (bias, overstatement).

27.18 — The conclusion-language spectrum. Place each phrase on establishes/demonstrates (strong, defensible when true) · consistent with/supports/indicates (defensible middle) · refuse (jury territory):

27.27 — Diagnose the transcript. (a) Q1 "you examined the original directly?" is the chain-of-custody / methodology trap (you should have worked a verified copy); the answer "I looked at the drive" concedes you may have touched the original — strong replacement: "No. I imaged the drive through a write-blocker, verified the image by SHA-256, and conducted all analysis on the verified working copy." Q2 is the tool-reliability / hashing attack; "probably fine" concedes uncertainty — strong replacement: "MD5 has known collision weaknesses, which is why I corroborated with SHA-256; for verifying this evidence the match is reliable." Q3 is the overstatement trap; "I believe he's guilty" is fatal. (c) The Q3 answer most damages overall credibility, because guilt is the jury's question and claiming it shows you don't know the limits of your role — once you overstate one thing, the jury reasonably doubts everything else you said. The cure for all three is the cardinal rule: state the finding, name the gap, stop.

Chapter 28 — Ethics

See ../part-4-legal-framework-and-reporting/chapter-28-ethics/index.md.

28.4 — Conflicts of interest and the contingency-fee rule. The standard for a conflict is whether you could reasonably be seen to have a competing interest — appearance, not proof of actual bias — because the appearance damages the evidence almost as effectively as the reality: a fact-finder who suspects your incentive discounts your findings regardless of their truth. The cardinal expert-witness rule is never accept a contingency fee (payment contingent on the outcome): such a fee literally pays you to reach a particular result, destroying the objectivity that FRE 702 demands, and courts widely treat it as grounds to exclude your testimony entirely. You are paid for your time and expertise, never for a conclusion.

28.7 — Scope discipline and plain view. Scope is harder in digital evidence because "there are no rooms on a 2-terabyte drive" — unlike a physical search where a warrant for the garage doesn't authorize the bedroom, a disk is one undifferentiated space, and a tool that indexes "everywhere" sees everything at once. The plain-view doctrine, imported uncritically into a whole-device search, threatens to convert a narrow warrant into a general search of the entire drive (anything the examiner "happens upon" becomes fair game). Courts grew wary of exactly this in the United States v. Carey and Comprehensive Drug Testing lines, guarding against the constitutional danger of the general warrant the Fourth Amendment exists to forbid — hence search protocols, filter teams, and scope-limited methodology.

28.18 — Mapping the codes.

The common thread: objectivity, integrity, competence, and confidentiality — serve the truth, not a side. You will be asked on the stand (Ch. 27) which code you adhere to, so being able to name it — and live it — is itself a credibility credential.

Chapter 29 — Encrypted Device Forensics

See ../part-5-advanced-topics/chapter-29-encrypted-device-forensics/index.md.

29.1 — Your password is not the key. The hierarchy: the secret you supply (passphrase/PIN) is run through a slow KDF to derive an intermediate key, which wraps (encrypts) the media/volume key (the FVEK/VMK in BitLocker terms) that actually encrypts the sectors. The media key is generated once at encryption time and never changes. That is why a user can change a BitLocker password on a 2 TB drive in under a second: changing the password only re-wraps the same media key with a new derived key — a few bytes of metadata rewritten — whereas re-encrypting 2 TB would mean decrypting and re-encrypting every sector. The lesson for the examiner: attack the wrapping (the passphrase, an escrow/recovery key, a TPM, or keys in RAM), not the sectors.

29.20 — The strongbox analogy and the foregone conclusion. Courts distinguish compelling the key to a strongbox (a physical act, generally compellable) from compelling the combination to a safe (the contents of your mind, protected by the Fifth Amendment privilege against self-incrimination). A memorized passphrase resembles the combination — it is testimonial, so compelling it is constitutionally fraught (a biometric/physical token leans toward the "key"). The "foregone conclusion" doctrine, from Fisher v. United States (1976), is the narrow exception: if the government already knows, with reasonable particularity, that the device contains specific evidence the suspect possesses and controls, the act of production adds nothing the state doesn't already know. The exact question a court asks: does the act of decrypting tell the government anything it does not already know with reasonable particularity (existence, possession, authenticity)? If not, decryption may be compelled.

Chapter 30 — Anti-Forensics

See ../part-5-advanced-topics/chapter-30-anti-forensics/index.md.

30.9 — NTFS's two timestamp sets ("the gift"). (a) The two attributes are $STANDARD_INFORMATION` (`$SI, type code 0x10) and $FILE_NAME` (`$FN, type code 0x30); Windows Explorer displays $SI`**. (b) The `$SI set is user-settable through the normal API** (e.g., SetFileTime), while the $FN` set is **kernel-maintained and not exposed to user mode**. (c) That asymmetry is "the gift": timestomping tools change the visible `$SI times but cannot easily touch the hidden $FN` times, so a **`$SI earlier than $FN`**, or sub-second-zeroed `$SI values against precise $FN values, reliably betrays manipulation — anti-forensics leaves a trace.

30.14 — Detecting a cleared log. (a) Windows writes Event ID 1102 to the Security log when it is cleared, recording the account that cleared it, the domain/SID, and the time. (b) When a non-Security log is cleared, Event ID 104 fires in the System log (naming the log and the user). (c) Beyond the self-announcing event, two structural tells on a machine you can prove ran for months: an anomalous record-number/sequence gap (the .evtx EventRecordID jumps or restarts) and a log whose earliest record is implausibly recent (a "months-old" workstation whose Security log only goes back two days). Absence is a finding.

30.18 — NTFS alternate data streams. (a) A stream is "alternate" when the MFT record holds an additional **named $DATA` attribute** (the default stream is unnamed); the named stream's contents don't appear in normal file size/listing. (b) Enumerate with `cmd.exe`: **`dir /r`**; with PowerShell: **`Get-Item -Stream *`** (or `Get-Content file -Stream name`). (c) The ubiquitous benign stream is **`Zone.Identifier`** (the Mark-of-the-Web), which is *useful* to an examiner because it records that a file came from the internet and often the source URL/zone. (d) The anomaly that distinguishes a hiding place from `Zone.Identifier`: a stream with an **unexpected name, executable content, or a size far larger than a small text marker** — e.g., a multi-megabyte `$DATA:payload on a .txt.

Chapter 31 — Cloud Forensics

See ../part-5-advanced-topics/chapter-31-cloud-forensics/index.md.

31.1 — The three reservoirs of cloud evidence.

Mistaking reservoir 3 for reservoir 2 is the most consequential new-examiner error: logging into a live account with found credentials changes state (last-access times, "seen" flags), may exceed your authority (CFAA/SCA exposure), and is not the same as lawfully compelling the provider's preserved copy — you can spoliate evidence and your own case in one click.

31.5 — The OneDrive artifact map. Under ...\AppData\Local\Microsoft\OneDrive\settings\Business1\ and ...\logs\Business1\:

<cid>.dat.previous is "a gift the documentation never advertises" because it preserves an earlier state of the file tree — letting you see files and folders that were present before the user's most recent sync/cleanup, even after they were removed from the current <cid>.dat.

Chapter 32 — Malware Forensics

See ../part-5-advanced-topics/chapter-32-malware-forensics/index.md.

32.5 — Trust magic bytes, not the extension. Extensions are attacker-controlled metadata; the file command reads the actual header so a .jpg that is really a PE is exposed. (a) Windows PE begins with 4D 5A = "MZ". (b) Linux ELF begins with 7F 45 4C 46 = \x7fELF. For the recovered kworkerd ELF: EI_CLASS = 2 → 64-bit (ELFCLASS64); EI_DATA = 1 → little-endian (ELFDATA2LSB); e_machine = 0x3E → x86-64 (AMD64); e_type = 3 → ET_DYN, a position-independent executable / shared object (typical of modern PIE binaries and some implants). Together: a 64-bit little-endian x86-64 PIE Linux executable — consistent with a Linux server implant, not a kernel worker thread despite the name.

32.23 — Map WEB-07 capabilities to MITRE ATT&CK.

Chapter 33 — Cryptocurrency Investigation

See ../part-5-advanced-topics/chapter-33-cryptocurrency-investigation/index.md.

33.4 — Analyze the Bitcoin transaction (work in satoshis). Inputs: 1.50000000 + 0.30000000 = 1.8 BTC = 180,000,000 sat. Outputs: 1.75000000 + 0.04990000 = 1.7999 BTC = 179,990,000 sat. (a) Miner fee = 180,000,000 − 179,990,000 = 10,000 sat. (b) Output #0 (1.75 BTC) is the payment; output #1 (0.04990000 BTC) is the change returning to the sender. The three change-detection signals: (1) address-type match — the change is a bc1q… native-segwit address like the inputs, while the payment is a legacy 1… address; (2) fresh address — the change address was "never seen before," typical of an auto-generated change output; (3) non-round "leftover" amount — 0.0499 BTC is a remainder, not a deliberate payment figure. (c) The common-input-ownership heuristic clusters the two inputs (bc1qk8p3v9m2x… and bc1qw3r7t5h8n…) as one entity, because spending both inputs in one transaction requires both private keys — normally one owner. (d) You reason in satoshis (integers) to avoid binary floating-point rounding error that BTC decimals introduce — a fee computed in floating point can come out as 0.00009999999 and mislead.

33.19 — Identify two carved 16-byte specimens. - A: ... 0000 0000 6231 0500 — bytes at offset 12 are 62 31 05 00 = 0x00053162, the Berkeley DB magic number at its standard offset. Specimen A is a wallet.dat (legacy Bitcoin Core BDB wallet). A strings scan returning mkey and ckey proves the wallet is encrypted (it stores a master key record and crypted private-key records), so the private keys are passphrase-protected; the hashcat mode that targets it is -m 11300 (Bitcoin/Litecoin wallet.dat). - B: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 = SQLite format 3\0 — a SQLite database, i.e., a modern descriptor-based Bitcoin Core wallet (post-wallet.dat), parsed as a database rather than a BDB file.

Chapter 34 — IoT, Vehicle, and Embedded Device Forensics

See ../part-5-advanced-topics/chapter-34-iot-vehicle-embedded-forensics/index.md. (Representative problems, consistent with the chapter's scope.)

34.A — What a vehicle's infotainment/telematics unit holds, and the dominant tool. A modern car's head unit and telematics module are, forensically, a phone that drives: paired-phone contacts and call logs, SMS/notification mirrors, navigation history and saved/recent destinations, GPS track points, Wi-Fi SSIDs and Bluetooth pairings, and event records (door open/close, ignition on/off, gear, sometimes speed). The dominant commercial tool is Berla iVe, which maps supported vehicles to extraction methods and decodes the proprietary stores. Recovery vs. forensics: the same track log that reunites a fleet manager with a lost route can place a suspect vehicle at a scene — image first, hash, work the copy.

34.B — Reaching the bytes on an embedded device: four access methods, least to most invasive. (1) Logical/UART or vendor API — a console or app interface; non-invasive but shallow. (2) JTAG — connect to the CPU's debug port via test access pads to read the flash through the processor; moderate, requires pinouts. (3) eMMC "in-system programming" (ISP) — tap the eMMC clock/command/data lines to read the flash directly without removing it; more invasive. (4) Chip-off — desolder the BGA NAND/eMMC and read it in an external programmer; most invasive and irreversible (heat can destroy the chip). The reflex is the same as drive recovery (theme: technology changes, principles don't): choose the least invasive method that gets the data, and document why. The recurring obstacle is proprietary, undocumented formats — you get the bytes, then you must reverse the structure.

34.C — The smart-speaker question: device vs. cloud. An Amazon Echo or Google Home stores little of lasting value on-device (a wake-word buffer, Wi-Fi config, tokens); the substantive evidence — voice-interaction transcripts and timestamps — lives in the provider's cloud, reachable only by legal process (a warrant/subpoena), which puts it in reservoir 2 of Ch. 31. The companion phone app is often the most productive local artifact. The lesson: for IoT, the device is a sensor; the case is frequently in the account.

Chapter 35 — AI-Assisted Forensics and Deepfake Detection

See ../part-5-advanced-topics/chapter-35-ai-assisted-forensics-and-deepfakes/index.md.

35.4 — The three rungs of the hashing ladder.

The discriminating case: a contraband image resized and re-encoded by a chat app no longer matches its catalogued SHA-256 (one changed bit changes the whole digest), and fuzzy hashing of compressed image bytes is unreliable too. The rung that still flags it is perceptual hashing, because it hashes the visual structure (downscaled luminance/DCT features), which survives resizing and re-compression — the transformations defeat byte-level hashes precisely because perceptual hashing ignores the bytes.

35.21 — The liar's dividend. Coined by Bobby Chesney and Danielle Citron (2019), the liar's dividend is the benefit a wrongdoer gains as deepfakes become plausible: they can dismiss authentic recordings as "probably fake" — it requires no fake at all, only the ambient possibility of one, to seed doubt. In a 2023 matter, a defense suggested that genuine recorded executive statements "might be deepfakes"; the court was unpersuaded absent evidence of manipulation, declining to let the mere suggestion override authentication. The answer to the liar's dividend is not a better detector but a discipline — provenance and the chain of authentication, anchored in Federal Rule of Evidence 901 (authenticating evidence): you prove what a recording is and where it came from, rather than trying to prove a negative about what it isn't.

Chapter 36 — The Forensic Toolkit

See ../part-6-tools-and-career/chapter-36-the-forensic-toolkit/index.md.

36.4 — The Sleuth Kit tools by file-system layer.

In fls output, a leading * marks a deleted entry — the file name and metadata address survive even though the file was unlinked, which is your first foothold for recovery.

Chapter 37 — Building a Forensic Lab

See ../part-6-tools-and-career/chapter-37-building-a-forensic-lab/index.md.

37.10 — The three-tier storage hierarchy.

The cardinal workflow rule that ties them together: the master image lives, hashed, on the evidence tier; you work only on copies on the scratch tier; and you re-verify the hash before every session. That is theme two — the original is sacred — given a floor plan.

Chapter 38 — The Capstone Investigation

See ../part-6-tools-and-career/chapter-38-the-capstone-investigation/index.md. (Representative problems for the capstone.)

38.A — The end-to-end order of operations. Assemble the whole case in the order the book taught it: (1) Receive the assignment — document scope and authority (Ch. 25). (2) Acquire — write-blocked forensic image, dual-hash (MD5 + SHA-256), open the chain of custody (Ch. 14). (3) Verify — confirm the image hash before analysis. (4) Recover — deleted files, carve unallocated (Ch. 6–7). (5) Analyze artifacts — registry, browser, email, documents, photos+EXIF (Ch. 16–20). (6) Build the super-timeline and reconcile contradictions (Ch. 21). (7) Detect anti-forensics (Ch. 30). (8) Report (Ch. 26) and prepare to testify (Ch. 27). Re-verify the hash at every handoff.

38.B — Reconcile a timeline contradiction. Suppose a key file's $SI` (Explorer-visible) modified time reads **2019-01-01 00:00:00** but its `$FN time reads 2024-03-02 19:14:06, while an LNK file, a browser download record, and a 4624 logon all cluster at 2024-03-02 ~19:08–19:15. The model conclusion: the $SI`/`$FN mismatch indicates timestomping of the user-writable $SI` set ([Ch. 30](../part-5-advanced-topics/chapter-30-anti-forensics/index.md)); the **independent corroborating records** ($FN, LNK, browser, event log) establish the **true activity window of 2024-03-02 evening**. You report: *"File-system and corroborating artifacts indicate the file was created on 2024-03-02 ~19:14 UTC; the displayed 2019 timestamp is inconsistent with the kernel-maintained$FN` time and the surrounding artifacts, consistent with deliberate timestamp alteration." Faking one date is easy; faking all* of them consistently is not — which is why the timeline, not any single stamp, carries the finding. This is anchor case #2.

Chapter 39 — Certifications and Professional Development

See ../part-6-tools-and-career/chapter-39-certifications/index.md. The authoritative roadmap is Appendix I — Certification Roadmap.

39.7 — The GIAC / SANS family.

The GIAC exam format is proctored but open-book, which is exactly why building your own indexed notes is the highest-leverage study task — under time pressure you win or lose on how fast you can find an answer in your index, not on raw recall. These renew on a 4-year cycle (~36 CPE) and the cost (course + exam) is high enough that they cluster among examiners whose employers pay.

39.20 — Age the portfolio as of 2026-06-28.

The rule the tracker exists to enforce: every credential you claim must be currently valid. It is a courtroom-credibility rule, not housekeeping — a lapsed-but-listed cert on your CV is sworn evidence that is false, an impeachment opening that taints your entire testimony (Ch. 27). The honest forms are "maintain it" or "EnCE, 2021–2024" stated as history.

Chapter 40 — The Forensics and Recovery Career

See ../part-6-tools-and-career/chapter-40-the-career/index.md.

40.5 — The four entry doors.

The single thing every door shares: none of them starts you at zero — each brings a transferable strength, and the gap is learnable. That is what should reassure the thirty-eight-year-old patrol officer or the forty-five-year-old second-career graduate: the field is entered laterally far more often than it is entered young, and the method (understand → image → analyze → document → report) is the same wherever you came from. You did not start too late; you started from somewhere.

Using these answers well. If your solution matched the finding but missed the limit, study the limit — in this work the disclosed limitation is what makes the finding defensible. If a calculation disagreed, redo it in the smallest unit (satoshis, bytes, seconds-since-epoch) before assuming the book is wrong. And remember the rule that runs through every chapter above: state what the evidence shows, name what it cannot, and stop.