Appendix C — Tool Reference

Purpose. A keyboard-side catalog of the data-recovery and digital-forensics toolbox — every major tool by category, platform, license/cost tier, and one-line purpose, with a pointer to the chapter that teaches it in depth. Chapter 36 — The Forensic Toolkit supplies the judgment (how to choose, validate, and verify); this appendix is the index you scan when you need to remember which instrument does what. Tools are listed by what they accomplish, never by brand loyalty — technology changes, principles don't.

This appendix is descriptive, not an endorsement. Inclusion does not imply a tool is validated for your task or court; that determination is yours (see Chapter 25 — The Legal Framework on Daubert/Frye, and the validation note at the end). Full command syntax for the CLI tools lives in Appendix H — Command-Line Reference; download URLs and citations live in the Bibliography; definitions are in the Glossary.

How to read this appendix

Every table uses the same four legends. Skim them once; they make the catalog dense and fast.

Category (what stage of the pipeline the tool serves):

Platform: Win / Lin / mac native · X = cross-platform · (CLI) command line · (GUI) graphical · (PS) PowerShell · +HW requires dedicated hardware · web browser/server.

License / Cost (approximate list price — confirm current pricing with the vendor; tiers move):

Deep dive: the chapter that owns the tool's full treatment. Relative-path links to each chapter are given in the intro line of every section and consolidated in the cross-reference map at the end.

Recovery vs. Forensics. Many tools below serve both disciplines; the difference is the ceremony around the tool, not the parse. A 💾 recovery technician runs PhotoRec or R-Studio to get a client's files back fast. A 🔍 forensic examiner may run the same parse but wraps it in a write-blocker, before/after hashes, a chain of custody, and dual-tool verification so the result survives court. One toolbox, two standards of proof. The category tag tells you what a tool does; only the case tells you how much ceremony it needs.

1. Imaging and acquisition (IMG)

The front of the pipeline: make a verified bit-for-bit copy so you never work on the original (the original is sacred). Full options in Appendix H; deep treatment in Chapter 14 — Forensic Acquisition; failing-media imaging in Chapter 8 — Hard Drive Recovery.

Write-blocking is part of acquisition but is mostly a hardware category — it is owned by Chapter 5 — The Forensic Process and Chapter 14:

Tool Tip. ewfacquire writes the E01 format that everything reads, so acquiring to E01 keeps your options open across every later tool. For a quick check that an image is sound, ewfverify image.E01 recomputes and compares the stored acquisition hash; for raw images, hashdeep (below) does the same job.

2. Hashing and integrity (HASH)

Proof an image and its recovered files are unaltered. Conceptually owned by Chapter 14 — Forensic Acquisition; fuzzy hashing recurs in Chapter 20 and Chapter 32.

3. File-system analysis and all-in-one platforms (FS)

The middle of the pipeline: parse partitions, file systems, and deleted entries — or run a full case from one environment. The open-source engine and the commercial suites both live here; running one of each is how you get dual-tool verification. Owned by Chapter 4 — File Systems, Chapter 6 — Logical Recovery, and surveyed in Chapter 36.

Limitation. No recovery tool, at any price, recovers data that has been physically overwritten, securely wiped, or zeroed by an SSD's deterministic TRIM (Chapter 9 — SSD and Flash Recovery). When icat returns zeros and the carver finds nothing, the answer is not "buy a better tool" — it is that deleted ≠ destroyed reached its limit and the data is gone. A more expensive license does not change physics.

6. Windows artifacts (WINART)

Parse the registry, execution evidence, shortcuts, and event logs that make Windows the most artifact-rich platform. Owned by Chapter 16 — Windows Forensics and Chapter 21 — Timeline Analysis; triage collection by Chapter 15 — Live Response and Triage.

Eric Zimmerman suite roster — one artifact, one parser, CSV out (load the CSV into Timeline Explorer to filter, tag, and pin exhibits):

Tool Tip. Registry Explorer replays transaction logs (.LOG1/.LOG2) that a careless extraction or a lesser tool ignores — a hive copied without its logs shows a stale view. "Which registry tool, and did you give it the logs?" is a fair cross-examination question; feeding the parser the complete hive set is the answer.

7. macOS and Linux artifacts (NIXART)

The non-Windows side: plists, unified logs, FSEvents, and Apple's pattern-of-life databases. Owned by Chapter 17 — macOS and Linux Forensics; the super-timeline by Chapter 21.

8. Browser, email, and internet (WEB)

Reconstruct web activity and mailboxes. Owned by Chapter 18 — Browser and Internet Forensics and Chapter 19 — Email, Chat, and Social Media Forensics.

9. Metadata (META)

Read the data about the data — EXIF, GPS, camera, authorship, timestamps. Owned by Chapter 20 — Photo, Video, and Document Forensics.

Tool Tip. exiftool -a -G1 -s file.jpg dumps all tags grouped by family — the fastest way to surface GPS coordinates, the capturing device, and original-vs-modified timestamps that anchor the photo-evidence thread of anchor case #4. Read metadata; never write it on evidence.

10. Memory forensics (MEM)

The volatile machine: running processes, network connections, injected code, and encryption keys the disk never holds. Owned by Chapter 22 — Memory Forensics.

11. Network forensics (NET)

The wire: capture, dissect, and reconstruct traffic. Owned by Chapter 23 — Network Forensics.

12. Mobile forensics (MOB)

The most personal evidence source, and the category where commercial tooling is least optional — locked bootloaders, default encryption, secure enclaves, and weekly app-format churn require funded research. Owned by Chapter 24 — Mobile Device Forensics; recovery angle in Chapter 11 — Mobile Device Recovery.

Legal Note. Cloud acquisition turns on authority, not technique — a token or credential does not grant lawful access by itself. Account data may sit across jurisdictions, implicating the Stored Communications Act, the CLOUD Act, and MLAT process; get the legal basis right before you collect. Doctrine is owned by Chapter 25 — The Legal Framework and tabulated in Appendix E — Legal Frameworks Reference.

14. Malware analysis and reverse engineering (MAL)

Post-incident analysis of malicious code — defensive understanding, not weaponization (Chapter 32 — Malware Forensics).

15. Encryption and password recovery (CRYPT)

Attack protected files and full-disk encryption — within lawful authority. Owned by Chapter 29 — Encrypted Device Forensics.

Limitation. Strong, correctly implemented encryption with a high-entropy passphrase and no recoverable key is, for practical purposes, unbreakable — and that is a feature of the math, not a gap in the tool. The realistic paths are the key (in a memory image, escrow, TPM, or recovery key), not brute force against the cipher. "The volume is encrypted and the key is unavailable; the data is inaccessible" is a valid, professional finding (know your limitations).

16. Cryptocurrency investigation (COIN)

Follow the money across public ledgers and attribute addresses. Owned by Chapter 33 — Cryptocurrency Investigation.

18. Live response and endpoint DFIR (TRIAGE)

Collect and analyze at speed and scale — across one machine or a fleet — respecting the order of volatility. Owned by Chapter 15 — Live Response and Triage Forensics.

19. Forensic OS distributions (DISTRO)

Preconfigured Linux images that bundle most of the open-source bench into a ready lab. Owned by Chapter 37 — Building a Forensic Lab.

20. Validation and reference data (VALID)

You do not trust a tool because it is popular or expensive — you trust it because it has been validated against known data, and you verify load-bearing findings with a second tool. These are the references that make that defensible; the discipline is owned by Chapter 36 and practice images are catalogued in Appendix J — Practice Images and Lab Setup.

Ethics Note. The Project VIC / CAID hash sets exist to identify known illegal material by hash, without a human re-viewing the content — both to make the review tractable and, deliberately, to limit how much an examiner must look at. That is a designed-in mitigation of the secondary trauma this work carries. Configure these hash sets first in any case where contraband may be in scope. Mandatory reporting (18 U.S.C. §2258A), scope discipline, and examiner well-being are owned by Chapter 28 — Ethics. The human cost is real.

Evidence and image formats at a glance

The container, not just the tool, determines what your next tool can read. Keep this next to the keyboard:

Quick-invocation cheat sheet

A minimal, copy-near-it starter for the CLI workhorses. Illustrative — never run against original evidence; work on verified copies. Full flags and many more tools are in Appendix H — Command-Line Reference.

# ── ACQUIRE (behind a write-blocker) ──────────────────────────────────────────
ewfacquire -t /ev/case01/disk -c best -d sha256 /dev/sdX      # → E01, compressed+hashed
dcfldd if=/dev/sdX of=/ev/case01/disk.dd hash=sha256 hashlog=disk.hashes bs=4M
ddrescue -d -r3 /dev/sdX failing.img failing.map             # failing media (resumable)

# ── VERIFY INTEGRITY ──────────────────────────────────────────────────────────
ewfverify disk.E01                                           # recompute vs. stored hash
hashdeep -r -c sha256 ./recovered > recovered.hashes         # recursive, auditable
hashdeep -a -k baseline.hashes -r ./recovered               # audit a tree vs. known set

# ── FILE SYSTEM (The Sleuth Kit) — mmls offset is in 512-byte SECTORS ─────────
mmls disk.E01                                               # find partition start sectors
fls   -o 1024000 -r -p disk.E01                             # list files incl. deleted (*)
istat -o 1024000 disk.E01 5830                              # one entry: metadata + MACB
icat  -o 1024000 disk.E01 5830-128-3 > out/recovered.xlsx   # recover a file BY inode
tsk_recover -e -o 1024000 disk.E01 ./export                 # bulk export (alloc+unalloc)
blkls -o 1024000 disk.E01 > unalloc.bin                     # extract unallocated for carving

# ── CARVE (metadata is gone) ──────────────────────────────────────────────────
photorec unalloc.bin                                        # interactive signature carving
scalpel  -o carve_out unalloc.bin                           # config-driven carver
bulk_extractor -o bx_out disk.E01                           # features: email/url/ccn/gps/aes_keys

# ── METADATA · NETWORK · MEMORY ───────────────────────────────────────────────
exiftool -a -G1 -s photo.jpg                               # all tags, grouped (GPS/camera/times)
tshark -r cap.pcapng -Y 'http.request.method=="POST"' \
       -T fields -e ip.dst -e http.host -e http.request.uri  # extract HTTP POSTs
vol -f mem.raw windows.pslist                              # Volatility 3: processes

The Windows-side one-liner every examiner runs reflexively — confirm two tools recovered byte-identical content:

# Same artifact recovered by two independent tools must hash-match (working copies only).
$a = (Get-FileHash -Algorithm SHA256 .\autopsy_out\recovered.xlsx).Hash
$b = (Get-FileHash -Algorithm SHA256 .\xways_out\recovered.xlsx).Hash
if ($a -eq $b) { "AGREE  $a" } else { "CONFLICT  A=$a  B=$b  -- investigate" }

Template: tool and version log

Record every tool and its exact version in your case notes — version numbers are part of the chain of custody because results can differ across versions. Drop this block into the methodology section of your report (Chapter 26 — The Forensic Report); the chain-of-custody and report forms are in Appendix F.

TOOL & VERSION LOG                                  (attach to case notes / CoC)
Case: ____________________   Examiner: ____________________   Date: ___________
Evidence item / image: __________________________   Acq. SHA-256: ____________
┌─────────────────────────┬───────────┬───────────────┬──────────────────────────┐
│ Tool                    │ Version   │ Validated?    │ Used for (artifact/finding)│
├─────────────────────────┼───────────┼───────────────┼──────────────────────────┤
│ FTK Imager              │ 4.7.x     │ CFTT + self   │ Acquisition → disk01.E01  │
│ The Sleuth Kit          │ 4.12.1    │ CFReDS + self │ Deleted-file recovery     │
│ X-Ways Forensics        │ 21.x      │ self          │ Dual-tool verify (hash ✓) │
│ Registry Explorer       │ x.x       │ self          │ USBSTOR first/last connect│
│ Volatility 3            │ 2.x       │ self          │ Memory: pslist / netscan  │
│ ____________________    │ ________  │ _____________ │ _________________________ │
└─────────────────────────┴───────────┴───────────────┴──────────────────────────┘
Dual-tool confirmations (finding → tool A / tool B → matching SHA-256):
  1) ____________________________________________________________________________
  2) ____________________________________________________________________________
Conflicts found and resolved (a conflict is information, not a nuisance): ________

Choosing from this catalog (pointer)

The catalog answers "which tool does X?" It does not answer "which tool should I use here?" — that is judgment, and it is owned by Chapter 36 — The Forensic Toolkit. The short version, for the keyboard:

1. Start from the evidence and the question, not the brand. Disk → §3/§4/§5; phone → §12; RAM → §10; packets → §11; account → §13.
2. Decide recovery vs. forensics. Recovery optimizes for getting bytes back; forensics adds write-blocking, hashing, chain of custody, and dual-tool verification for court.
3. Match the budget. A real career can start at $0 (Autopsy/TSK, Volatility, Wireshark, bulk_extractor, EZ tools, PhotoRec/TestDisk, ExifTool — all on a SIFT/CAINE workstation). Buy commercial for scale, support, currency, and — for mobile and cloud — capability you cannot get free.
4. Match the court. Prefer validated (CFTT/CFReDS), widely accepted, explainable tools; you must be able to defend on the stand what the tool did and why you trust it (Chapter 27 — Expert Testimony).
5. Verify load-bearing findings with a second, independent tool — ideally one open-source and one commercial, from different codebases. When two independent tools agree, the finding is robust; when they disagree, you have found something to run to ground before it reaches the report.

Legal Note. Under Daubert, your tool choice is evidence about testability, error rate, standards, and general acceptance. "I used The Sleuth Kit and confirmed with X-Ways; both are widely used, TSK's source is open, and CFTT has tested the relevant function" speaks directly to admissibility. "I used a tool I can't fully explain" invites exclusion. Choosing court-recognized, validated tools is building admissibility in from the first command — doctrine in Chapter 25; the certifications that signal tool competence in Appendix I — Certification Roadmap.

Cross-reference: deep dives by chapter

Where each category is taught in full (relative links):

• Storage & file systems — Ch. 2 (data storage) · Ch. 3 (storage tech/RAID) · Ch. 4 (file systems)
• Process, acquisition, hashing — Ch. 5 (forensic process) · Ch. 14 (acquisition)
• Recovery & carving — Ch. 6 (logical) · Ch. 7 (carving) · Ch. 8 (hard drive) · Ch. 9 (SSD/TRIM) · Ch. 10 (RAID) · Ch. 12 (ransomware)
• Triage & OS artifacts — Ch. 15 (live/triage) · Ch. 16 (Windows) · Ch. 17 (macOS/Linux)
• Internet, metadata, timeline — Ch. 18 (browser) · Ch. 19 (email/chat) · Ch. 20 (photo/video/doc) · Ch. 21 (timeline)
• Volatile, network, mobile — Ch. 22 (memory) · Ch. 23 (network) · Ch. 24 (mobile) · Ch. 11 (mobile recovery)
• Legal, reporting, ethics — Ch. 25 (legal) · Ch. 26 (report) · Ch. 27 (testimony) · Ch. 28 (ethics)
• Advanced — Ch. 29 (encryption) · Ch. 30 (anti-forensics) · Ch. 31 (cloud) · Ch. 32 (malware) · Ch. 33 (crypto) · Ch. 34 (IoT/vehicle) · Ch. 35 (AI/deepfakes)
• Toolkit, lab, career — Ch. 36 (toolkit/judgment) · Ch. 37 (lab) · Ch. 38 (capstone) · Ch. 39 (certifications)

Related appendices: A — File Signatures · B — Python Forensics Toolkit · D — Artifact Locations · E — Legal Frameworks · F — Chain of Custody & Report Templates · G — File-System Reference · H — Command-Line Reference · I — Certification Roadmap · J — Practice Images & Lab Setup · Glossary · Bibliography

One line to carry forward: the tool does not testify — you do; this catalog names the instruments, but your understanding and judgment are what the instruments serve.