Appendix J — Practice Images and Lab Setup

Purpose. A build-it-this-weekend guide to a hands-on practice environment: where to download legitimate practice disk, memory, and network images (NIST CFReDS, Digital Corpora's M57-Patents and Lone Wolf, DFRWS, the Honeynet Project, Magnet and Belkasoft CTFs, and more), how to stand up Linux and Windows analysis VMs with the free tool stack this book uses, how to handle the data safely and legally, and exactly which images map onto each chapter's exercises and onto the progressive Forensic Case File project.

You cannot learn this craft by reading. Every technique in this book — imaging, hashing, carving, MFT analysis, timelining, Volatility, plaso, registry parsing — becomes real only when you run it against bytes you are allowed to touch. This appendix exists so you never have an excuse not to. Everything here is free and legal to practice on. Chapter 37 — Building a Forensic Lab covers the professional lab (write-blockers, evidence vaults, ISO 17025); this appendix covers the learning lab on hardware you already own.

J.1 How to use this appendix

Find your goal, jump to the section, download the image, build the VM, and start. The fastest path to your first finding is J.21 Quick start: your first hour — skip there if you just want momentum, then come back to set things up properly.

Why this matters. A keyboard, a free hypervisor, and the public images below reproduce the evidence side of nearly everything a six-figure lab does. What you cannot reproduce at home is the chain of custody for real evidence, the write-blocked acquisition of physical originals, and the courtroom — which is exactly why this book pairs every practice image with the discipline (hashing, working copies, contemporaneous notes) that makes the difference between "I found it" and "I can prove I found it and it is unaltered."

URLs drift; project names don't. Sites reorganize. Every resource below is named so you can find it with a search even if a link rots. Always download over HTTPS and verify the published hash (J.17) before you trust a single byte.

J.2 The practice-data landscape

The whole field at a glance. "Size" is approximate; "Answers?" notes whether a published solution/answer key exists (a huge help when you are learning solo).

Tool Tip — bookmark two aggregators. When this appendix ages, the AboutDFIR "Ultimate Test Image Page" (disk/memory/mobile) and NETRESEC's "Publicly available PCAP files" page (network) are the two living indexes the community keeps current. Start there to find anything not listed above.

J.3 NIST CFReDS

The Computer Forensic Reference Data Sets project, run by NIST, publishes documented "evidence" built specifically so an examiner can practice and so tools can be validated against a known ground truth. Two sets earn their keep first.

The Hacking Case (the classic first exam)

The single most-used teaching image in the field. The scenario: in 2004 a Dell CPi laptop is recovered and suspected to belong to a hacker ("Mr. Evil," Greg Schardt). You receive a raw dd image (SCHARDT.001, on the order of a few GB) of a Windows XP system and a list of roughly 30 investigative questions (network configuration and the wardriving angle, installed tools, email, recovered deleted files, web activity). NIST does not publish an official answer key, but well-known community walkthroughs exist.

Limitation. The Hacking Case is Windows XP with a FAT/NTFS layout from 2004 — perfect for learning fundamentals, dated for modern artifacts (no SRUM, no modern AmCache, no BitLocker, partition often starts at sector 63, not 2048). Use it to learn the process; use Lone Wolf or a Magnet/Belkasoft image to see modern Windows.

The Data Leakage Case

A richly documented insider-threat scenario: a suspect exfiltrates confidential data through multiple channels (USB, cloud upload, email, printing). It ships as an E01 with an extensive answer guide, which makes it the best CFReDS set for self-grading your artifact analysis — and a near-perfect rehearsal for this book's anchor #2 (the employee who covered their tracks). Maps to Ch.16, Ch.18, Ch.19, Ch.30.

CFReDS also hosts mobile (Android) images, memory images, and small file-system test sets (deleted-file recovery, string-search, carving) that pair cleanly with Ch.4, Ch.6, and Ch.7.

J.4 Digital Corpora

Simson Garfinkel's digitalcorpora.org is the deepest well of realistic, freely redistributable scenarios. Three things to grab.

M57-Patents (the multi-source masterpiece)

A small startup, M57.biz, run by a handful of employees, simulated across roughly three weeks of operation in 2009. Each business day produced a disk image of every employee's PC, a RAM capture, and a network packet capture. Woven through the data: a confidential-document exfiltration, a planted-contraband subplot, and ordinary office noise to hide it in. Because it spans multiple machines + memory + network over time, M57-Patents is the only public set that lets you practice the skill that actually wins real cases: correlating evidence across sources and across days.

There is also M57-Jean — a single-machine subset (the CFO accidentally leaks an employee spreadsheet). It is small, fast, and the ideal first end-to-end case before you commit to the full M57-Patents set.

Lone Wolf (the modern single-machine case)

A 2018 scenario: one Windows 10 laptop belonging to a (fictional) individual planning a mass-casualty attack. You get a disk E01 and a memory image, built to be worked like a live case. It is the best public stand-in for a modern Windows exam — current registry, browsers, cloud-sync artifacts, and a real timeline to reconstruct.

Ethics Note. The Lone Wolf and M57 scenarios contain simulated sensitive themes (planned violence; planted contraband as a benign stand-in). They contain no real illegal material — these corpora are built precisely so you can train without it. Treat them with full professional discipline anyway: it is exactly the reflex you want automatic before you ever touch a real case. See Chapter 28 — Ethics.

govdocs1 and NPS images

govdocs1 is a corpus of roughly one million real, freely-redistributable files (PDF, DOC, XLS, JPG, HTML, PPT…) harvested from .gov domains, organized into 1,000 folders (000–999) of ~1,000 files each. It is the standard test set for file carving, file-type identification, EXIF/metadata, and bulk_extractor. You do not need all of it — pull a few folders (a few GB) to start. The NPS test images (e.g., camera/SD-card and USB images) are small, purpose-built sets for partition recovery and carving. Maps to Ch.7, Ch.20.

J.5 DFRWS Forensic Challenges

Since 2005 the Digital Forensic Research Workshop has posted an annual challenge with a dataset and (afterward) the winning write-ups — effectively a free, graduate-level problem set. The standouts:

Try This. The DFRWS 2006/2007 carving challenges are deliberately hard — fragmented and out-of-order files designed to defeat naive header-to-footer carvers. Run foremost and scalpel against them, see what breaks, then read the winning write-up to learn why. That gap between "I ran the tool" and "I understand the data" is the whole point of Chapter 7.

J.6 The Honeynet Project

honeynet.org publishes "Forensic Challenges" (and the archived "Scan of the Month" series): real captured attacks — network traces of intrusions, images of compromised honeypots, captured malware, and log puzzles — each with community solutions. It is the best free source for network forensics (Ch.23) and malware forensics (Ch.32) practice on adversarial data rather than sanitized lab data.

Recovery vs. Forensics. Most sources in this appendix are framed for the 🔍 forensic examiner. The Honeynet sets are framed for the 🛡️ incident responder: the question shifts from "what can I prove about the past" to "what is the attacker doing, and how do I stop it." Same artifacts, different clock — and a reminder that this book teaches both lenses on the same evidence.

J.7 Magnet and Belkasoft

Two commercial vendors give the community generous free practice data — and free or trial tools to work it with.

• Magnet Forensics runs recurring CTFs (the Magnet Weekly CTF, Virtual Summit CTFs) and releases the images publicly afterward, frequently covering modern Windows, mobile, and cloud artifacts. Magnet also ships genuinely useful free utilities: MAGNET RAM Capture (memory acquisition), Encrypted Disk Detector, and Web Page Saver. AXIOM itself is available as a time-limited trial. Community write-ups for each CTF are easy to find.
• Belkasoft publishes free test images (iOS, Android, and Windows) on a dedicated page, plus regular CTFs. Belkasoft Evidence Center X (BEC X) has a free trial. The Belkasoft images are small and well-suited to a fast artifact drill when you do not want to download tens of GB.

Both pair best with Ch.15, Ch.16, Ch.24, and Ch.36 — The Forensic Toolkit.

J.8 Memory images

Memory forensics (Chapter 22) needs RAM captures, and there are excellent free ones.

The fastest way to get a modern memory image is to capture one from your own analysis VM — then you know exactly what is in it:

# Windows guest: capture RAM with a free acquisition tool (run as Administrator)
# MAGNET RAM Capture (GUI) — or winpmem on the CLI:
winpmem_mini_x64_rc2.exe physmem.raw
Get-FileHash -Algorithm SHA256 .\physmem.raw   # hash the capture immediately

# Linux guest: capture RAM with Microsoft AVML (static binary, no kernel module needed)
sudo ./avml memory.lime
sha256sum memory.lime

Tool Tip — Volatility 2 vs 3 on samples. The classic samples (Cridex, Zeus, Stuxnet — Windows XP/7) are most reliable under Volatility 2 with an explicit --profile= (e.g., --profile=WinXPSP2x86). Volatility 3 needs no profile (it uses symbol tables) and is the right choice for modern Windows 10/11 captures. Install both (J.14); reach for the one that matches the sample's era.

J.9 Network captures (PCAP)

Safe Handling. Malware PCAP archives are commonly zipped with the password infected specifically so they cannot auto-extract or be scanned/blocked in transit. The PCAP itself is inert capture data, but it often references live malicious URLs/IPs — analyze it on an isolated VM (J.16) and never click through to the hosts it names.

Work these with tcpdump, tshark/Wireshark, NetworkMiner (free; superb for file/credential extraction), and Zeek — all covered in Chapter 23.

J.10 Mobile images

Mobile is the hardest data to obtain legally because real extractions require physical devices and licensed tools. Use purpose-built public images:

Parse them with the free ALEAPP (Android) and iLEAPP (iOS) tools and the methods in Chapter 24 — Mobile Device Forensics. For the recovery angle (deleted SQLite rows, carving), see Chapter 11 — Mobile Device Recovery.

J.11 Roll-your-own practice images

Sometimes the best image is one where you planted the evidence yourself, because you know the ground truth exactly. This is the cheapest, fastest way to drill Chapter 4, Chapter 6, and Chapter 7.

A deleted-file recovery image, start to finish (Linux)

# 1) Create a 256 MB raw image with one FAT32 partition starting at 1 MiB (sector 2048)
dd if=/dev/zero of=practice.dd bs=1M count=256
LOOP=$(sudo losetup -Pf --show practice.dd)        # -P creates partition nodes (loopNp1)
sudo parted -s "$LOOP" mklabel msdos mkpart primary fat32 1MiB 100%
sudo mkfs.vfat "${LOOP}p1"

# 2) Mount, write a "secret," then DELETE it (deletion removes the pointer, not the data)
sudo mount "${LOOP}p1" /mnt/practice
echo "TOP SECRET: the meeting is at noon" | sudo tee /mnt/practice/secret.txt
sudo sync && sudo rm /mnt/practice/secret.txt
sudo umount /mnt/practice
sudo losetup -d "$LOOP"

# 3) Now recover it from the raw image, working ONLY on the file (the original is sacred)
mmls practice.dd                                   # confirm the partition start sector (2048)
fls -r -d -o 2048 practice.dd                      # -d = show DELETED entries; note the inode
icat -o 2048 practice.dd <inode> > recovered.txt   # carve it back by inode
tsk_recover -o 2048 practice.dd ./recovered/       # or bulk-recover everything deleted

The byte offset of any partition is start-sector × 512: here 2048 × 512 = 1048576 (1 MiB), which is why every Sleuth Kit command takes -o 2048. That single equation — sector × sector-size = byte offset — is the spine of Chapter 2.

Other images you can build in minutes

• RAID practice (Ch.10): create three small image files, assemble them with mdadm --create --level=5 --raid-devices=3 … over loop devices, write data, "fail" a member, and rebuild. You will understand stripe order and parity by doing it.
• Encrypted-container practice (Ch.29): make a small VeraCrypt container with a known password, then practice detecting it (entropy, headers), mounting it with the key, and reasoning about what is and is not recoverable without the password.
• Carving practice (Ch.7): cat a handful of JPGs/PDFs into a blank image with gaps of zeros between them, wipe the file system, and carve them back with foremost/photorec. Compare recovered files to the originals by hash.

J.12 The lab: host requirements

You can practice everything in this book on one reasonably modern computer. Bigger just means less waiting.

Limitation — Apple Silicon. On an M-series Mac you can run ARM Linux guests well (UTM/VMware Fusion), but x86 Windows guests run only under slow emulation. If your target is Windows forensics and you are on Apple Silicon, plan on a separate x86 box, a cloud VM, or running the EZ Tools and Autopsy on a borrowed Windows host.

J.13 Hypervisor choice

Whichever you choose, the two non-negotiable habits are snapshots (clean baseline before every exercise) and isolated networking (J.16).

J.14 The Linux analysis VM

Linux is the recovery/forensic workhorse — the Sleuth Kit, carvers, plaso, and Volatility all feel most at home here. You have two routes.

Route 1: a prebuilt DFIR distribution (fastest)

Download the VM/ISO, verify its hash, import it, snapshot, and you are ready.

Route 2: build your own on Ubuntu (you learn more)

Start from a clean Ubuntu 22.04/24.04 VM, then install the stack this book uses:

sudo apt update && sudo apt -y upgrade

# --- The Sleuth Kit: fls, icat, mmls, fsstat, blkls, istat, tsk_recover, img_stat ---
sudo apt -y install sleuthkit

# --- Imaging + evidence-container handling ---
sudo apt -y install dc3dd dcfldd gddrescue ewf-tools afflib-tools
#   gddrescue -> 'ddrescue';  ewf-tools -> ewfacquire/ewfmount/ewfverify (E01)

# --- Recovery & carving ---
sudo apt -y install foremost scalpel testdisk
#   'testdisk' also installs 'photorec'

# --- Metadata, strings, hashing ---
sudo apt -y install libimage-exiftool-perl binutils hashdeep
#   libimage-exiftool-perl -> 'exiftool';  binutils -> 'strings';  hashdeep -> md5deep/hashdeep

# --- Network forensics ---
sudo apt -y install wireshark tshark tcpdump

# --- Carving/triage extras + YARA + bulk_extractor (if packaged) ---
sudo apt -y install yara bulk-extractor

# --- Python tooling base ---
sudo apt -y install python3-pip git

Verify the core tools came through:

fls -V            # The Sleuth Kit X.Y.Z
ewfverify -V      # libewf version
exiftool -ver     # exiftool version

Sleuth Kit and Autopsy on Linux — read this carefully

apt install sleuthkit gives you the command-line TSK (fls, icat, mmls, fsstat, tsk_recover, …) — everything Chapter 6 and Appendix H need. The GUI is the catch:

• sudo apt install autopsy installs the legacy Autopsy 2.x — an old Perl/HTML front-end to TSK. It works, but it is not the modern product.
• The modern Autopsy 4.x (the Java desktop application) is officially built for Windows. On Linux you install it by downloading the ZIP from the Sleuth Kit/Autopsy site, installing a matching TSK build and OpenJDK 17, then running the bundled unix_setup.sh and ./autopsy. It is community-supported on Linux, not the primary platform.

Recommendation. Do CLI work (TSK, carving, Volatility, plaso) on Linux; run Autopsy 4 on your Windows VM (J.15), where it is best supported. This is also how most working examiners split the two.

Volatility (install both versions)

# Volatility 3 (Python 3, no profiles, modern Windows/Linux/macOS) — recommended
python3 -m pip install --user volatility3
vol -f memory.raw windows.info               # 'vol' entry point after pip install
vol -f memory.raw windows.pslist
#   or from source:
git clone https://github.com/volatilityfoundation/volatility3
python3 volatility3/vol.py -f memory.raw windows.pslist

# Volatility 2 (Python 2.7, profile-based) — for the CLASSIC samples (Cridex, Zeus…)
git clone https://github.com/volatilityfoundation/volatility
python2 volatility/vol.py -f cridex.vmem --profile=WinXPSP2x86 pslist

Tool Tip. Python 2 is end-of-life and missing from current distros. If Volatility 2 will not run, drop it in a Python-2 container or pin a venv — or just analyze the classic samples by accepting that some plugins differ. For anything you capture yourself from a modern OS, Volatility 3 is the answer.

plaso (super-timelines)

python3 -m pip install --user plaso          # provides log2timeline.py + psort.py
log2timeline.py timeline.plaso image.dd      # build the storage file
psort.py -o l2tcsv -w timeline.csv timeline.plaso   # render to CSV for Timeline Explorer

Pair this with Chapter 21 — Timeline Analysis. RegRipper is not reliably in apt; clone it (keydet89/RegRipper3.0) when you reach Chapter 16.

J.15 The Windows analysis VM

Many forensic crown jewels are Windows-only. Build a clean Windows 10/11 VM (use a legitimate evaluation/Insider image), snapshot it, and install — only from official sources, hashes verified:

Tool Tip — WSL2 gives you both worlds. Enable WSL2 on the Windows VM and apt install the Linux stack from J.14 right alongside the Windows tools. You can fls/icat in WSL and open the same image in Autopsy and EZ Tools without leaving the box. For many learners, one well-built Windows + WSL2 VM is the entire lab.

Verify a tool downloaded intact before you run it:

Get-FileHash -Algorithm SHA256 .\AccessData_FTK_Imager.exe
# compare the output against the vendor's published SHA-256

J.16 Networking and isolation

Default to disconnected. Connect only deliberately, and never put an analysis VM on your real LAN.

War Story. Examiners have re-infected their own corporate networks by analyzing a malware sample on a bridged VM "just to download one tool." The beacon found the LAN in seconds. Snapshot a clean state, set the network to not attached, do your analysis, and revert the snapshot afterward. For live malware traffic, build a separate internal-only network with REMnux running a simulated internet (e.g., INetSim) so the sample talks to you, not the world. See Chapter 32 and Chapter 37.

J.17 Safe handling and the law

These rules apply to practice data too — partly to protect your host, mostly because rehearsing the discipline is the point.

The safe-handling checklist

• ☐ Download over HTTPS; verify the published hash before trusting the file.
• ☐ Keep the master copy read-only (chmod 444, or a read-only volume); work on a copy.
• ☐ Hash the working copy and confirm it equals the master before and after analysis.
• ☐ Snapshot the VM clean before each exercise; revert after anything untrusted.
• ☐ Analyze on a disconnected VM; isolate anything that might be live malware (J.16).
• ☐ Keep practice data on a separate volume from real work — never mix practice and real evidence.
• ☐ Record what you did in a contemporaneous note (J.18).

Verify a download's hash

# If the site ships a checksum file:
sha256sum -c SCHARDT.001.sha256
# Otherwise compute and eyeball it against the published value:
sha256sum SCHARDT.001

Get-FileHash -Algorithm SHA256 .\SCHARDT.001    # compare to the published SHA-256

# Cross-platform, memory-safe hashing of a large image (chunked)
import hashlib, sys

def sha256(path, block=1 << 20):              # 1 MiB chunks
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(block), b""):
            h.update(chunk)
    return h.hexdigest()

if __name__ == "__main__":
    print(sha256(sys.argv[1]), sys.argv[1])

Mount images read-only (Linux)

# Raw image, partition starting at sector 2048:
sudo mount -o ro,loop,offset=$((2048*512)),noexec,nosuid,nodev image.dd /mnt/evidence

# E01: expose it as a raw device first, then loop-mount read-only:
sudo ewfmount image.E01 /mnt/ewf
sudo mount -o ro,loop,offset=$((2048*512)) /mnt/ewf/ewf1 /mnt/evidence

On Windows, mount with FTK Imager or Arsenal Image Mounter in read-only mode. Either way, the image you analyze must remain provably identical to the one you downloaded — the same principle (the original is sacred) that makes real evidence admissible.

Ethics & Legal Note. The public corpora here are built to contain no real illegal material — they use benign stand-ins precisely so you can train safely. But train the reflex anyway: if, on any real device, you ever encounter material that even might be child sexual abuse material (CSAM), stop, do not copy or further view it, document, and report under your jurisdiction's mandatory-reporting law (in the U.S., 18 U.S.C. § 2258A). This is non-negotiable and is covered in Chapter 25 — The Legal Framework, Chapter 28 — Ethics, and Appendix E. Practice data is also licensed for education — read each source's terms; do not re-host or use it for anything but learning.

J.18 Organizing your evidence

A consistent layout turns a pile of downloads into a defensible case file. Keep master images read-only and separate; keep per-case working folders for your analysis.

~/forensics/
├── images/                       # MASTER practice images — read-only (chmod 444)
│   ├── nist-hacking-case/
│   │   ├── SCHARDT.001
│   │   └── SCHARDT.001.sha256    # published hash, kept beside the image
│   ├── m57-patents/
│   ├── lone-wolf/
│   └── samples/                  # memory (.vmem/.raw/.lime) + network (.pcap)
├── cases/                        # YOUR analysis — one folder per case/exercise
│   └── 2026-001_hacking-case/
│       ├── 00_intake/            # assignment, authority, hash-on-receipt
│       ├── 01_acquisition/       # working copy + verification log
│       ├── 02_analysis/          # tool output, extracted artifacts
│       ├── 03_timeline/          # plaso storage + rendered CSV
│       ├── 04_exhibits/          # what will go in the report
│       ├── notes.md              # contemporaneous lab notebook
│       └── report.md             # your findings (see Appendix F)
└── tools/                        # cloned repos, EZ Tools, KAPE, etc.

A minimal lab-notebook / intake header to drop at the top of notes.md (the real chain-of-custody and report forms live in Appendix F):

CASE:        2026-001  Hacking Case (NIST CFReDS — practice)
EXAMINER:    <you>                       DATE OPENED: 2026-06-28
SOURCE:      SCHARDT.001  (raw/dd)        FROM: cfreds.nist.gov (dl 2026-06-27)
HASH (RECV): <sha256>  — matches published? [ ] yes
WORKING COPY: cases/2026-001/01_acquisition/SCHARDT-working.dd
HASH (COPY): <sha256>  — equals source?     [ ] yes
TOOLS+VER:   TSK 4.12, Autopsy 4.21, Volatility 3 2.x, plaso 2024.x
OBJECTIVE:   <what this session is trying to establish>
----------------------------------------------------------------------
TIME   ACTION                                  RESULT / OUTPUT REF / HASH
0900   sha256sum SCHARDT.001                   matches published  ✓
0905   cp -> working copy; re-hashed           equals source      ✓
0912   mmls working.dd                         1 NTFS part @ sector 63
0920   fls -r -o 63 working.dd > files.txt     342 entries (29 deleted)
...

Chain of Custody (rehearsal). You will never produce a real chain of custody for a practice image — but writing the intake header and the timestamped action log every single time builds the habit so it is automatic when the evidence is real and a defense attorney is reading your notes line by line.

J.19 Mapping the book to practice images

Recommended practice data per chapter. (Chapters that are conceptual, hardware-bound, or legal — e.g., 1, 3, 8, 13, 25–28, 33, 39, 40 — are best practiced through their own exercises rather than an image.)

J.20 The progressive project spine

The Forensic Case File project runs across the book; you should carry one primary image through it from acquisition (Ch.5/Ch.14) to the capstone report (Ch.38). Pick by appetite:

Recommended path. Use the Hacking Case as a guided end-to-end rehearsal while you work Parts I–III, then adopt M57-Patents (or Lone Wolf if disk space or time is tight) as the spine of your Forensic Case File. M57's multiple machines, RAM, and packet captures are the only public data that let you practice the capstone's defining skill — building one coherent timeline and narrative from many independent sources — which is exactly what anchor #2 (the employee who covered their tracks) demands.

J.21 Quick start: your first hour

Two on-ramps. Do whichever gives you the bigger jolt of momentum — then go back and build the lab properly.

Track A — disk (Sleuth Kit on the Hacking Case), ~30 min

# 1) Download SCHARDT.001 from CFReDS, then verify integrity before trusting it
sha256sum SCHARDT.001                       # compare to NIST's published hash

# 2) Find the partition (XP images often start at sector 63, NOT 2048 — always check)
mmls SCHARDT.001

# 3) List files, INCLUDING deleted, from that partition
fls -r -o 63 SCHARDT.001 | less             # use the Start sector mmls reported

# 4) Recover one deleted file by its inode
icat -o 63 SCHARDT.001 <inode> > recovered.bin
file recovered.bin                          # what did you get back?

Track B — memory (Volatility 3 on a modern sample), ~20 min

# Use a modern Windows memory image (a MemLabs lab, or capture your own VM's RAM)
vol -f memory.raw windows.info              # OS build, profile-free
vol -f memory.raw windows.pslist            # running processes
vol -f memory.raw windows.netscan           # network connections in RAM
vol -f memory.raw windows.malfind           # injected/suspicious memory regions
#  (for the classic XP samples like cridex.vmem, use Volatility 2 with --profile=WinXPSP2x86)

That is the whole craft in miniature: verify, then examine a copy, then recover and interpret what was supposedly gone. Everything else in this book is depth on those moves.

J.22 Troubleshooting

J.23 See also

• Appendix A — File Signatures Reference: the magic numbers your carvers key on.
• Appendix B — Python Forensics Toolkit: reusable scripts (hashing, carving, parsing) for the images here.
• Appendix C — Tool Reference: deeper notes on Autopsy/TSK, FTK, EnCase, Volatility, Wireshark, and the rest.
• Appendix D — Forensic Artifact Locations: where the evidence lives once you mount an image.
• Appendix E — Legal Frameworks Reference: authority, the private-search doctrine, and the CSAM reporting duty.
• Appendix F — Chain of Custody and Report Templates: the real forms behind the practice notebook above.
• Appendix H — Command-Line Reference: every flag for dd/fls/icat/vol/exiftool/tcpdump and friends.
• Appendix I — Certification Roadmap: many certs (GCFE, GCFA, CFCE) expect exactly this kind of hands-on practice.
• Chapter 36 — The Forensic Toolkit and Chapter 37 — Building a Forensic Lab: the tools and the room they live in.

The bottom line. Pick one image, build one VM, hash everything, work on the copy, and write down what you do. Do that ten times and the procedures in this book stop being something you read and become something you can do — which is the only thing a courtroom, a client, or a breach victim will ever actually care about.