Mike Anderson

Posted on Jul 11

Digital Forensics: A Beginner-Friendly Field Workflow for Evidence Preservation, Acquisition, Analysis, Recovery, and Secure Erasure

#digitalforensics #cybersecurity #incidentresponse #mobile

Digital forensics fails most often before analysis begins.

An investigator connects a suspect drive directly to Windows and lets it auto-mount. A responder powers off an encrypted laptop and loses the decryption keys held in RAM. A phone is placed in an untested Faraday bag, drains its battery while searching for service, and shuts down. A recovery utility is installed onto the same disk that contains the deleted files. A game console is booted and connected to the internet, changing logs and creating the possibility of remote deletion.

The mistake is usually not “using the wrong tool.”

The mistake is using a tool before deciding what evidence must be preserved.

This guide is written for readers who are new to digital forensics but want to build expert habits. It explains:

what you are trying to preserve,
why the order of actions matters,
which tools fit each situation,
how to collect evidence without destroying it,
how to verify your work,
how to avoid weak or overstated conclusions.

Authorization requirement: Use these procedures only on devices you own or are explicitly authorized to examine. For criminal, HR, regulatory, or litigation matters, obtain legal approval and follow the applicable evidence-handling policy before collection.

1. The forensic mindset: know the objective before touching the device

Before choosing a tool, answer one question:

Am I trying to preserve evidence, recover data, investigate an incident, or securely erase a device?

Those are different missions.

Objective	What matters most	What you must not do
Evidence preservation	Integrity, repeatability, chain of custody	Do not browse, repair, clean, or “quickly check” the original device
Incident response	Preserve volatile evidence and reduce business risk	Do not power off an unlocked encrypted system without considering RAM and live state
Data recovery	Recover usable files	Do not install recovery tools onto the same media you are recovering from
Malware investigation	Preserve executable artifacts, memory, logs, persistence, network context	Do not run malware samples on your normal workstation
Device disposal	Prevent future recovery	Do not confuse sanitization with forensics; erasure destroys evidence

The practical rule:

Preserve first. Acquire second. Analyze third. Conclude last.

Forensic beginners often jump straight into Autopsy, FTK Imager, PhotoRec, or a mobile extraction tool. That is backwards. The first decision is the device state. A powered-off laptop, powered-on encrypted laptop, unlocked phone, failing HDD, and game console require different workflows.

2. The master workflow: the path every case should follow

Use this workflow as your map for the entire article.

Authorization
  ↓
Identify device state
  ↓
Preserve volatile evidence if the device is live
  ↓
Prevent avoidable changes
  ↓
Acquire evidence using the least destructive method
  ↓
Hash and verify the acquisition
  ↓
Analyze a working copy, not the original
  ↓
Validate key findings with another method or artifact
  ↓
Report facts, tool output, interpretation, and limitations separately
  ↓
Retain or dispose according to policy

Every tool in this guide fits somewhere in that flow.

3. First-response decision matrix: what to do first

This is the section to follow when the device is in front of you.

Situation	Primary risk	First action	Main tools	Why
Computer is powered off	Booting changes evidence and may trigger encryption, updates, or deletion	Do not power on; photograph; remove storage if authorized; image through write blocker	Camera, evidence labels, hardware write blocker, `ewfacquire`, FTK Imager, Guymager, `dc3dd`	Offline imaging preserves persistent storage with minimal change
Computer is powered on and unlocked	Shutdown loses RAM, encryption keys, sessions, running malware, network state	Photograph screen; isolate network; capture RAM; collect volatile artifacts; then image disk	WinPmem, AVML, Belkasoft RAM Capturer, Magnet RAM Capture, KAPE, Velociraptor, `netstat`, `tasklist`, `lsof`, `ss`	Live state may contain evidence unavailable after shutdown
Computer is powered on but locked	Interaction may alter state; shutdown may lose encryption keys	Keep powered; prevent sleep; document lock state; seek legal/owner approval for next action	Camera, power supply, Faraday/network isolation where applicable, RAM tools if authorized and technically possible	Locked-but-running systems may still contain keys and live sessions
BitLocker/FileVault/LUKS laptop is powered on and unlocked	Power loss can make disk unreadable without recovery key	Keep awake and powered; capture RAM; collect recovery keys if available; consider live logical acquisition	WinPmem/AVML, KAPE, Velociraptor, enterprise key escrow, forensic imaging tools	Encryption changes the evidence strategy; live access may be more valuable than dead-box imaging
HDD is clicking, slow, or unstable	Repeated reads can worsen damage	Stop normal access; use controlled recovery imaging	GNU `ddrescue`, HDDSuperClone/OpenSuperClone, professional lab if severe	Recovery imaging prioritizes readable sectors and avoids wasting retries early
SSD contains deleted files	TRIM and garbage collection may make deleted content unrecoverable	Stop use immediately; power down if no volatile evidence is needed; image as soon as possible	Write blocker, FTK Imager, Guymager, `ewfacquire`, Autopsy, TSK, PhotoRec	Continued use and idle time can reduce recovery chances
Phone is unlocked	Lock/reboot can reduce extraction options; network can change or wipe data	Keep powered; prevent lock; isolate network with tested method; document state	Faraday enclosure with power, Cellebrite UFED, Magnet AXIOM, iLEAPP, ALEAPP, MVT	Unlocked-after-first-boot state may expose more data than locked state
Phone is locked	Excessive attempts can lock, wipe, or alter state	Do not guess passcodes; preserve power and radio state; document condition	Faraday enclosure, mobile forensic platform, legal/MDM/cloud account records	Many modern phones protect data strongly after reboot or lock
Game console is powered on	Booting, updating, syncing, or launching games changes evidence	Photograph screen; isolate network; do not update or browse; preserve external storage separately	Camera, write blocker for external media, router logs, account/cloud records, forensic imaging tools for removable media	Console internal storage may be encrypted or paired to the device; ecosystem evidence matters
Device is being disposed	Privacy, not evidence preservation	Confirm no investigation hold; sanitize using media-appropriate method	`blkdiscard`, `hdparm`, `nvme-cli`, vendor tools, Apple/Android reset, physical destruction	Sanitization intentionally destroys recoverability

4. Tool map: which tool to use, why, and when

Tools should not be chosen by popularity. Choose them by the evidence question.

Tool / Tool type	Use it for	Why it is useful	Do not use it when
Hardware write blocker	Offline acquisition of drives and removable media	Prevents writes from forensic workstation to source media	Live acquisition, mobile phones, or storage that requires device-level access
FTK Imager	Creating forensic images, previewing images, exporting files	Widely used, easy for beginners, supports E01 and raw imaging	It is not a complete investigation platform by itself
Guymager	Linux-based forensic imaging	Simple imaging workflow with hashing and logs	Not ideal for complex live response
`ewfacquire` / libewf	E01 forensic image creation on Linux	Produces segmented, metadata-rich forensic image format	Beginners must record command output carefully
`dc3dd`	Raw imaging with hashing	Forensic-focused `dd` variant with logging/hash support	Damaged drives where `ddrescue` is safer
GNU `ddrescue`	Failing or unstable disks	Resumes imaging and tracks unreadable sectors with a mapfile	Healthy disks where normal E01 imaging is preferred
Autopsy	Disk image triage and artifact analysis	Beginner-friendly interface over The Sleuth Kit	Do not treat every parsed artifact as automatically true
The Sleuth Kit (`mmls`, `fls`, `icat`, `tsk_recover`)	Manual filesystem inspection and validation	Lets you verify tool output at partition, inode/MFT, and file level	Not a replacement for full case management
PhotoRec	File carving from unallocated or damaged filesystems	Recovers content by file signatures when metadata is missing	When filename, path, and timestamps are critical and metadata still exists
KAPE	Windows triage collection	Fast targeted collection of Windows artifacts	Not a substitute for full disk imaging when formal evidence preservation is required
Velociraptor	Endpoint-scale triage and incident response	Collects artifacts remotely and repeatably across many systems	Highly sensitive cases where local physical acquisition is required first
WinPmem / Magnet RAM Capture / Belkasoft RAM Capturer	Windows memory acquisition	Captures volatile memory for later analysis	When policy forbids live modification or the system is unstable
AVML	Linux memory acquisition	Practical Linux memory capture tool	Unsupported kernels or systems where loading collection tooling is not acceptable
Volatility 3	Memory analysis	Processes, network artifacts, injected code, DLLs/modules, command lines	It requires correct symbols/layers and careful interpretation
iLEAPP / ALEAPP	iOS and Android logical artifact parsing	Good for backups, app artifacts, and beginner learning	Not a bypass for locked encrypted phones
MVT	Mobile compromise indicator checks	Useful for targeted spyware/IOC-based review of iOS/Android backups	Not a general-purpose full mobile forensic suite
Cellebrite UFED / Physical Analyzer	Mobile acquisition and analysis	Broad commercial mobile support and extraction workflows	Requires licensing, training, legal authority, and validation
Magnet AXIOM	Computer/mobile/cloud artifact analysis	Strong artifact correlation and reporting	Commercial cost and black-box parsing require validation of critical findings
EnCase / X-Ways / FTK	Enterprise forensic examination	Mature evidence handling, indexing, reporting, and review workflows	Overkill for small learning labs; still requires examiner knowledge
`hdparm`, `nvme-cli`, vendor SSD tools	Drive sanitization	Issues drive-level erase/sanitize commands	Never use on evidence; destructive by design

5. Build the forensic workstation before the case

A forensic workstation is not a normal analyst laptop. It is an evidence-processing instrument.

Minimum workstation controls

Dedicated forensic laptop/workstation or isolated forensic VM
Auto-mount disabled
Hardware write blockers for interfaces you expect to handle: SATA, IDE, SAS, USB, NVMe, SD/microSD
Encrypted evidence storage
Separate evidence-master and working-copy storage
Accurate system time synchronized to an approved source
Case-specific command/session logging
Known-good forensic tools with recorded versions and hashes
No consumer cloud sync on case folders
No automatic indexing, thumbnail generation, or antivirus cleaning of evidence files
Malware-isolated VM or lab system for suspicious executables

Why this matters

If your workstation auto-mounts a USB drive, creates thumbnails, writes indexing databases, or quarantines files, you may contaminate evidence before analysis begins. The workstation must be predictable.

Case folder structure

CASE-2026-0042/
├── admin/
│   ├── authority.pdf
│   ├── chain-of-custody.csv
│   └── evidence-register.csv
├── acquisition/
│   ├── logs/
│   ├── photos/
│   └── manifests/
├── evidence-master/
│   ├── E-01-disk01.E01
│   ├── E-01-disk01.E02
│   └── E-01-disk01.sha256
├── working-copy/
├── exports/
├── reports/
└── notes/

Start a command-line acquisition log

On Linux:

export CASE="CASE-2026-0042"

mkdir -p "$CASE"/{admin,acquisition/{logs,photos,manifests},evidence-master,working-copy,exports,reports,notes}

script -a "$CASE/acquisition/logs/operator-session.log"

date --iso-8601=seconds
timedatectl
uname -a

Record tool versions:

{
  ewfacquire -V
  ewfverify -V
  dc3dd --version | head -n 1
  ddrescue --version | head -n 1
  mmls -V
  fls -V
  icat -V
  python3 --version
} | tee "$CASE/acquisition/manifests/tool-versions.txt"

Record tool hashes where practical:

sha256sum "$(command -v ewfacquire)" \
          "$(command -v ewfverify)" \
          "$(command -v dc3dd)" \
          "$(command -v ddrescue)" \
          "$(command -v mmls)" \
          "$(command -v fls)" \
          "$(command -v icat)" \
  | tee "$CASE/acquisition/manifests/tool-hashes.sha256"

6. Chain of custody: what to record before tools run

Every item needs a unique evidence ID. Do not identify evidence only as “John’s laptop” or “the USB drive.”

Record:

Case ID
Evidence ID
Collector name and role
Date, time, and timezone
Device make, model, serial number, asset tag
Physical condition and tamper-evident seal number
Power state and screen state
Connected cables, peripherals, and removable media
Network state
Storage type and interface
Encryption indicators
Acquisition tool and version
Write blocker make, model, firmware, and serial number
Destination evidence filename
Acquisition start and end time
Read errors or anomalies
SHA-256 hash of the acquired image
Every custody transfer

Example manifest:

Case ID: CASE-2026-0042
Evidence ID: E-01
Description: 1 TB Samsung SATA SSD removed from Dell Latitude 7440
Device serial: S6XXXXXXXXXX
Source condition: Powered off; no visible damage
Write blocker: Tableau T35u, serial TB-00481
Acquisition tool: ewfacquire 20240506
Image format: E01
Image filename: E-01-disk01.E01
Acquisition start: 2026-07-11T09:14:22+07:00
Acquisition end: 2026-07-11T10:03:11+07:00
Read errors: 0
SHA-256: <recorded value>
Operator: <name>

PART A — COMPUTER FORENSICS

7. Scenario: powered-off computer

What we are doing

We are preserving persistent storage without booting the operating system.

Why we are doing it

Powering on a stopped computer can:

change filesystem timestamps,
start scheduled tasks,
connect to networks,
trigger updates,
run cleanup scripts,
alter browser/session state,
lock or change full-disk encryption state,
issue TRIM/deallocation commands on SSDs.

Tools to use

Task	Preferred tool	Why
Scene documentation	Camera/phone camera with timestamp discipline	Captures original state before handling
Prevent writes	Hardware write blocker	Enforces read-only acquisition at hardware/protocol level
Create E01 image	FTK Imager, Guymager, `ewfacquire`	E01 supports metadata, compression, segmentation, and verification
Create raw image	`dc3dd`	Simple byte-for-byte acquisition with hashes
Verify image	`ewfverify`, `sha256sum`	Confirms acquisition integrity
Analyze image	Autopsy, The Sleuth Kit, X-Ways, Magnet AXIOM	Work from a verified image, not the source

Action flow

Photograph → Label → Remove drive if authorized → Attach write blocker → Image → Verify → Seal original → Analyze working copy

Example: E01 acquisition with `ewfacquire`

Identify disks first:

lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINTS

Confirm the suspect source. In this example, assume the source is /dev/sdb.

Create the image:

sudo ewfacquire /dev/sdb \
  -u \
  -t "$CASE/evidence-master/E-01-disk01" \
  -S 2G \
  -C "$CASE" \
  -D "1 TB Samsung SATA SSD removed from Dell Latitude 7440" \
  -E "E-01" \
  -e "Examiner Name" \
  -N "Acquired through hardware write blocker; source powered off"

Verify the E01 image:

ewfverify "$CASE/evidence-master/E-01-disk01.E01" \
  | tee "$CASE/acquisition/logs/E-01-ewfverify.log"

Hash the acquired image files:

sha256sum "$CASE"/evidence-master/E-01-disk01.E* \
  | tee "$CASE/evidence-master/E-01-disk01.sha256"

Evidence to keep

Scene photos
Evidence register
Chain-of-custody record
Write blocker details
Acquisition log
Tool versions
Hash output
Verification output
Notes about anomalies or read errors

8. Scenario: powered-on computer

What we are doing

We are collecting volatile evidence before it disappears.

Why we are doing it

A powered-on computer may contain:

full-disk encryption keys,
logged-in user sessions,
access tokens,
command history not written to disk,
mounted encrypted containers,
running malware,
injected code,
active network connections,
clipboard contents,
unsaved documents,
cloud-synced files currently available in decrypted form.

Shutdown can destroy that evidence.

Tools to use

Task	Windows tools	Linux/macOS tools	Why
Screen and state documentation	Camera	Camera	Proves original visible state
Network isolation	Pull Ethernet at switch/device, disable Wi-Fi using least interaction	Same	Prevents remote wipe, sync, exfiltration, or command-and-control
RAM capture	WinPmem, Magnet RAM Capture, Belkasoft RAM Capturer	AVML for Linux; specialist tools for macOS	Captures volatile memory
Volatile triage	KAPE, Velociraptor, native commands	`ps`, `ss`, `lsof`, `who`, `last`, shell history collection	Captures fast-changing state
Disk/logical acquisition	FTK Imager live acquisition, KAPE, Velociraptor, enterprise EDR	`rsync`/forensic collection scripts where authorized	Useful when encrypted volume is mounted
Memory analysis	Volatility 3	Volatility 3	Analyzes RAM capture offline

Action flow

Photograph → Prevent sleep → Isolate network → Capture RAM → Collect volatile state → Collect mounted/decrypted data if needed → Controlled shutdown or continued containment → Full disk image

Windows volatile commands

Run commands from trusted removable media where possible and redirect output to external evidence storage.

date /t > E:\CASE-2026-0042\acquisition\logs\live-windows.txt
time /t >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
hostname >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
whoami /all >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
ipconfig /all >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
netstat -ano >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
tasklist /v >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt
wmic logicaldisk get caption,description,filesystem,size,freespace >> E:\CASE-2026-0042\acquisition\logs\live-windows.txt

Windows RAM capture with WinPmem

Example:

winpmem_mini_x64_rc2.exe E:\CASE-2026-0042\evidence-master\E-02-memory.raw

Hash the capture:

certutil -hashfile E:\CASE-2026-0042\evidence-master\E-02-memory.raw SHA256 > E:\CASE-2026-0042\evidence-master\E-02-memory.sha256

Linux volatile commands

{
  date --iso-8601=seconds
  hostnamectl
  who -a
  w
  ip addr
  ip route
  ss -tunap
  ps auxww
  lsof -nP
  mount
  lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINTS
} | tee "$CASE/acquisition/logs/live-linux.txt"

Linux RAM capture with AVML

sudo ./avml "$CASE/evidence-master/E-02-memory.lime"
sha256sum "$CASE/evidence-master/E-02-memory.lime" \
  | tee "$CASE/evidence-master/E-02-memory.sha256"

Failure mode

Live response changes the system. That is unavoidable. Your goal is not “zero change.” Your goal is minimum necessary, documented change. Record every command, tool, time, and output path.

9. Scenario: powered-on encrypted laptop

What we are doing

We are preserving decrypted access while the system is still unlocked.

Why we are doing it

BitLocker, FileVault, and LUKS can make offline disk images unreadable without keys. If the laptop is currently unlocked, the mounted filesystem may expose evidence that will be unavailable after shutdown.

Tools to use

Task	Tool	Why
RAM capture	WinPmem, Magnet RAM Capture, Belkasoft RAM Capturer, AVML	May capture encryption keys, processes, sessions, tokens
Logical collection	KAPE, Velociraptor, FTK Imager live, Magnet AXIOM Cyber	Collects relevant artifacts from mounted decrypted volume
Recovery-key confirmation	AD/Azure AD/Intune/MDM/key escrow records	Enables later offline access
Full disk image after shutdown	Hardware write blocker + E01 imaging	Preserves persistent storage for repeatable analysis

Action flow

Keep powered → Prevent sleep → Photograph unlocked state → Capture RAM → Collect key artifacts/logical files → Confirm recovery-key availability → Decide shutdown strategy → Image disk

What to collect first

RAM
Recovery keys or escrow confirmation
Mounted encrypted containers
User profile artifacts
Browser session data
Cloud sync folders
Relevant application data
Running process and network state

What not to do

Do not close the lid.
Do not allow sleep.
Do not reboot “to be safe.”
Do not disconnect power if battery is low.
Do not browse through user data without scope.

10. Scenario: failing HDD or unstable storage

What we are doing

We are recovering as much readable data as possible while minimizing additional stress.

Why normal imaging can fail

A failing HDD may become worse with repeated reads. Standard imaging tools can get stuck retrying bad sectors while the drive continues degrading.

Tool to use: GNU `ddrescue`

ddrescue keeps a mapfile of what has been read, what failed, and what still needs retry. This allows controlled multi-pass imaging.

Action flow

Stop normal access → Document symptoms → Connect through write blocker if feasible → First fast pass → Second targeted retry pass → Hash recovered image → Analyze copy

First pass: recover readable sectors without retries

sudo ddrescue -f -n /dev/sdb \
  "$CASE/evidence-master/E-03-disk.raw" \
  "$CASE/acquisition/logs/E-03-ddrescue.map" \
  | tee "$CASE/acquisition/logs/E-03-ddrescue-pass1.log"

Second pass: limited retries

sudo ddrescue -f -d -r3 /dev/sdb \
  "$CASE/evidence-master/E-03-disk.raw" \
  "$CASE/acquisition/logs/E-03-ddrescue.map" \
  | tee "$CASE/acquisition/logs/E-03-ddrescue-pass2.log"

Hash the recovered image:

sha256sum "$CASE/evidence-master/E-03-disk.raw" \
  | tee "$CASE/evidence-master/E-03-disk.sha256"

When to stop and use a lab

Stop DIY attempts when:

the drive clicks repeatedly,
the drive disappears from the bus,
read errors increase rapidly,
the drive is physically damaged,
the evidence value is high,
the matter is legal/regulatory and you are not trained in damaged-media handling.

A professional lab may be safer than repeated field attempts.

11. Storage basics: SATA is not the opposite of SSD

A common beginner mistake is comparing “SATA versus SSD.”

That comparison is wrong.

SATA is an interface and command transport. A SATA device may be:

a rotational HDD,
a flash-based SSD,
an optical drive.

The forensic comparison that matters is:

rotational HDD using SATA, SAS, IDE, USB bridge, or another interface,
flash SSD using SATA, NVMe/PCIe, USB, soldered storage, or embedded storage.

Why this matters:

HDD deletion often leaves content in unallocated sectors until overwritten.
SSD deletion may trigger TRIM/deallocation and garbage collection.
SSD overwrite behavior is affected by flash translation layers and wear leveling.
Recovery depends on medium, firmware, filesystem, encryption, and device state, not only the connector.

12. Scenario: deleted files on HDD

What we are doing

We are trying to recover deleted file content and metadata from a forensic image.

Why recovery may work

On a rotational HDD, normal deletion usually removes or changes filesystem metadata that points to the file. Content may remain in unallocated clusters until overwritten.

Tools to use

Tool	Use it for	Why
Autopsy	Beginner-friendly deleted file review	Shows deleted entries, paths, timestamps, and file metadata when available
The Sleuth Kit	Manual validation	Confirms partition layout, filesystem metadata, inode/MFT records
PhotoRec	File carving	Recovers content when metadata is gone
X-Ways / Magnet / EnCase	Commercial review and reporting	Better at large cases and artifact correlation

Action flow

Verify image → Identify partitions → Recover metadata-based deleted files → Carve only when needed → Validate critical files → Report limitations

Identify partitions

mmls "$CASE/working-copy/E-01-disk.raw"

Example output may show an NTFS partition starting at sector 2048. Use that offset with TSK tools.

List deleted files with The Sleuth Kit

fls -r -d -o 2048 "$CASE/working-copy/E-01-disk.raw" \
  | tee "$CASE/exports/E-01-deleted-files.txt"

Recover a file by metadata address

If fls shows a metadata address, recover it:

icat -o 2048 "$CASE/working-copy/E-01-disk.raw" <MFT_OR_INODE_NUMBER> \
  > "$CASE/exports/recovered-file.bin"

Carve files when metadata is gone

photorec /log /d "$CASE/exports/photorec" "$CASE/working-copy/E-01-disk.raw"

Reporting limitation

A carved file often has no original filename, path, or reliable deletion time. Report it as recovered content from unallocated space, not as proof that a specific user deleted it.

13. Scenario: deleted files on SSD

What we are doing

We are preserving remaining evidence and setting realistic expectations.

Why SSD recovery is different

SSDs use flash translation layers, wear leveling, overprovisioning, garbage collection, and logical-to-physical remapping. When a file is deleted, the operating system may send a TRIM or deallocation command. The SSD controller may later erase the underlying pages.

Tools to use

Tool	Use it for	Why
Hardware write blocker	Prevent host writes	Reduces avoidable changes
E01/raw imaging tool	Capture current logical state	Preserves what is still accessible
Autopsy/TSK	Metadata and artifact review	Deleted references may still exist even when content is gone
PhotoRec	Content carving	May recover remnants if not deallocated/garbage collected
Application/browser/cloud artifacts	Corroboration	May prove existence or access even when file content is gone

Action flow

Stop use immediately → Do not boot → Image promptly → Analyze metadata and application artifacts → Attempt carving → Report uncertainty clearly

What to avoid

Do not boot the SSD “to check.”
Do not run recovery software on the original SSD.
Do not leave the SSD powered on unnecessarily.
Do not perform repeated write/overwrite attempts.
Do not promise recovery after TRIM.

Better evidence sources on SSD cases

When deleted content is gone, look for:

shortcut/LNK files,
Jump Lists,
browser downloads,
shellbags,
thumbnail cache,
recent documents,
cloud sync logs,
application databases,
email attachments,
backups,
EDR telemetry,
SIEM logs.

14. Analyze the image, not the source

What we are doing

We are turning acquired evidence into findings.

Why we do it this way

Analysis tools can create indexes, caches, extracted files, tags, and reports. Those operations belong on a working copy, not on the evidence master.

Action flow

Verify master hash → Create working copy → Analyze working copy → Export findings → Validate important findings → Preserve reports and logs

Prepare a working copy

cp "$CASE/evidence-master/E-01-disk01.E01" "$CASE/working-copy/"
sha256sum "$CASE/working-copy/E-01-disk01.E01" \
  | tee "$CASE/working-copy/E-01-workingcopy.sha256"

For raw images:

cp "$CASE/evidence-master/E-01-disk.raw" "$CASE/working-copy/"
sha256sum "$CASE/working-copy/E-01-disk.raw" \
  | tee "$CASE/working-copy/E-01-workingcopy.sha256"

Autopsy workflow

Use Autopsy when the reader needs a structured GUI workflow.

Recommended beginner flow:

Create a new case.
Add the disk image as a data source.
Set the correct timezone.
Enable modules relevant to the case:
- Recent Activity
- Web Artifacts
- File Type Identification
- Hash Lookup
- Keyword Search
- EXIF Parser
- Email Parser if relevant
Review results by artifact type, not only by filename.
Tag findings.
Export tagged files and reports.
Validate important findings with TSK or another tool.

Manual validation examples

List partitions:

mmls "$CASE/working-copy/E-01-disk.raw"

List files recursively:

fls -r -o 2048 "$CASE/working-copy/E-01-disk.raw" \
  | tee "$CASE/exports/E-01-file-list.txt"

Recover a file:

icat -o 2048 "$CASE/working-copy/E-01-disk.raw" <metadata_number> \
  > "$CASE/exports/recovered.bin"

Hash exported evidence:

sha256sum "$CASE/exports/recovered.bin" \
  | tee "$CASE/exports/recovered.bin.sha256"

15. Computer artifact priorities

Beginners need to know what to look for. Do not “look everywhere.” Start with artifacts that answer the investigation question.

Windows

Evidence question	Useful artifacts
Was a file opened?	LNK files, Jump Lists, RecentDocs, Office recent files
Was a file downloaded?	Browser history, download databases, Zone.Identifier alternate data streams
Was a USB device used?	SYSTEM hive USBSTOR, SetupAPI logs, MountedDevices
Was a program executed?	Prefetch, Amcache, Shimcache/AppCompatCache, SRUM, userassist
Was the system accessed remotely?	Event logs, RDP cache, TerminalServices logs, firewall logs
Was data staged or compressed?	Recent archives, shellbags, file timestamps, command history, PowerShell logs
Was malware persistent?	Run keys, services, scheduled tasks, WMI persistence, startup folders

Linux

Evidence question	Useful artifacts
Who logged in?	`/var/log/auth.log`, `/var/log/secure`, `lastlog`, `wtmp`, `btmp`
What commands were run?	Shell history, auditd logs, process accounting if enabled
What services started?	systemd journal, service files, cron jobs
Was persistence installed?	cron, systemd timers, SSH authorized_keys, profile scripts
What network activity occurred?	firewall logs, proxy logs, `journalctl`, application logs

macOS

Evidence question	Useful artifacts
Was a file opened?	Recent items, unified logs, application support databases
Was a program executed?	Unified logs, quarantine events, LaunchServices
Was persistence installed?	LaunchAgents, LaunchDaemons, login items, cron
Was external storage connected?	Unified logs, system profiler data, filesystem metadata
Was cloud sync involved?	iCloud Drive metadata, application databases, account state

PART B — MOBILE FORENSICS

16. Scenario: powered-on unlocked phone

What we are doing

We are preserving the unlocked state and preventing network changes while preparing for lawful extraction.

Why we are doing it

Modern phones are strongly protected by hardware-backed encryption. After reboot or lock, available extraction methods may become more limited. Network connectivity can also trigger remote wipe, message deletion, sync changes, or app updates.

Tools to use

Task	Tool	Why
Preservation	Faraday enclosure with power feed, airplane mode only if policy permits and documented	Prevents remote access while avoiding battery drain
Documentation	Camera, evidence form	Records lock state, notifications, account visible state
iOS logical extraction	Finder/iTunes backup, Cellebrite, Magnet AXIOM, Oxygen Forensic Detective	Captures available logical data
Android logical extraction	Commercial mobile forensic tools, MDM export, app/cloud exports where authorized	Android extraction varies heavily by model, patch level, lock state
Artifact parsing	iLEAPP, ALEAPP	Parses iOS/Android backups and app artifacts
Compromise checks	MVT	Checks backups/filesystem dumps against known indicators

Action flow

Photograph → Keep powered → Prevent lock → Isolate radio with tested method → Document state → Perform authorized extraction → Hash exports → Parse artifacts → Validate findings

What to document

Device make/model
Serial/IMEI where visible and legally permitted
OS version if visible without excessive interaction
Lock state
Whether the device has rebooted recently
Whether biometric unlock appears enabled
Battery level
Network state
SIM/eSIM state
Visible accounts or notifications
Connected accessories
Time displayed on device

What not to do

Do not browse apps to “see what is there.”
Do not guess passcodes.
Do not allow the phone to die.
Do not rely on an untested Faraday bag.
Do not update the OS.
Do not connect it to a normal personal computer.

17. Scenario: powered-off or locked phone

What we are doing

We are preserving the device for specialist handling and alternative evidence collection.

Why we are doing it

A locked or powered-off phone may expose very limited data without passcode, lawful authority, MDM support, or specialized tooling. Excessive interaction can worsen the situation.

Tools to use

Task	Tool	Why
Preservation	Faraday enclosure, controlled charging, evidence seal	Maintains state and prevents remote commands
Specialist extraction	Cellebrite, GrayKey, Magnet, Oxygen, vendor-specific lawful workflows	Mobile access depends on model, OS version, lock state, and authority
Alternative evidence	Cloud account exports, MDM, carrier records, app provider records, endpoint/cloud logs	Often more accessible than locked local storage
Parsing	iLEAPP, ALEAPP, MVT	Parses backups and exports when available

Action flow

Photograph → Preserve power/state → Isolate network → Do not attempt passcodes → Identify ownership/authority → Seek specialist extraction or collect lawful cloud/MDM records

Important beginner lesson

Mobile forensics is not “plug phone into tool and recover everything.” Extraction capability depends on:

device model,
OS version,
security patch level,
lock state,
whether the device has rebooted,
passcode availability,
trust relationship with a computer,
MDM or cloud access,
legal authority.

18. Mobile artifact parsing with iLEAPP, ALEAPP, and MVT

iLEAPP and ALEAPP

Use these after you have a lawful backup, filesystem extraction, or logical export.

Typical use:

python3 ileapp.py -t fs -i /cases/CASE-2026-0042/mobile/ios_extraction \
  -o /cases/CASE-2026-0042/exports/ileapp

python3 aleapp.py -t fs -i /cases/CASE-2026-0042/mobile/android_extraction \
  -o /cases/CASE-2026-0042/exports/aleapp

MVT

Use MVT when the question is mobile compromise or spyware indicator checking.

Example for an iTunes-style backup:

mvt-ios check-backup \
  --output "$CASE/exports/mvt-ios" \
  "$CASE/mobile/ios-backup"

Why parsing tools are not enough

Parsing tools tell you what they found. They do not prove the full story by themselves. Corroborate important findings with:

raw database records,
timestamps and timezone handling,
account records,
cloud logs,
message metadata,
screenshots,
second-tool validation.

PART C — GAME CONSOLE FORENSICS

19. Scenario: powered-on game console

What we are doing

We are preserving console state and related ecosystem evidence without causing firmware updates, sync changes, or account activity changes.

Why this is different from normal computer forensics

Modern game consoles are closed ecosystems. Internal storage may be encrypted, paired to the device, or difficult to interpret outside the console. Evidence may be spread across:

console local storage,
external USB drives,
memory cards,
user profiles,
account/cloud records,
chat and party systems,
purchase records,
achievements/trophies,
screenshots and game captures,
router/firewall logs,
companion mobile apps,
linked email accounts.

Tools to use

Task	Tool	Why
Scene documentation	Camera/video	Captures visible account, game/app state, connected devices
Network preservation	Disconnect Ethernet at switch/router side where possible	Avoids navigating console menus
External media imaging	Hardware write blocker + FTK Imager/Guymager/ewfacquire	Preserves USB drives or memory cards
Account/cloud evidence	Platform export, legal request, enterprise/parental controls where authorized	May be more useful than raw internal disk
Router evidence	Router/firewall logs, DHCP leases, DNS logs	Corroborates network activity
Analysis	Autopsy/TSK for external media; commercial tools where supported	External media may use standard filesystems

Action flow

Photograph active state → Isolate network with minimal interaction → Do not update firmware → Document accounts/peripherals → Remove and image external media → Preserve router/cloud/account evidence → Plan specialist console handling

What not to do

Do not launch games.
Do not open messages.
Do not update firmware.
Do not connect to the internet.
Do not factory reset.
Do not assume the internal drive image will be readable outside the console.

Beginner lesson

For game consoles, the best evidence is often not a raw internal disk image. The stronger case may come from account records, external media, network logs, cloud captures, chat metadata, screenshots, and linked devices.

PART D — MEMORY FORENSICS

20. Scenario: RAM acquisition and analysis

What we are doing

We are capturing volatile memory and analyzing it offline.

Why RAM matters

RAM may contain:

running processes,
injected code,
network connections,
command-line arguments,
decrypted data,
encryption keys,
malware unpacked in memory,
credentials or tokens,
unsaved content.

Tools to use

Task	Tool	Why
Windows RAM capture	WinPmem, Magnet RAM Capture, Belkasoft RAM Capturer	Captures physical memory for analysis
Linux RAM capture	AVML	Practical Linux memory acquisition
Memory analysis	Volatility 3	Open-source memory analysis framework
Malware triage	Volatility 3 plugins, YARA, strings	Finds suspicious processes, injected code, indicators

Action flow

Document system → Capture RAM → Hash memory image → Analyze with Volatility → Correlate with disk/log artifacts → Report limitations

Volatility 3 examples

Identify image information:

vol -f "$CASE/evidence-master/E-02-memory.raw" windows.info

List processes:

vol -f "$CASE/evidence-master/E-02-memory.raw" windows.pslist \
  | tee "$CASE/exports/memory-pslist.txt"

Show process tree:

vol -f "$CASE/evidence-master/E-02-memory.raw" windows.pstree \
  | tee "$CASE/exports/memory-pstree.txt"

List network connections:

vol -f "$CASE/evidence-master/E-02-memory.raw" windows.netscan \
  | tee "$CASE/exports/memory-netscan.txt"

Look for injected code indicators:

vol -f "$CASE/evidence-master/E-02-memory.raw" windows.malfind \
  | tee "$CASE/exports/memory-malfind.txt"

Failure modes

Memory analysis can be wrong or incomplete when:

the capture is partial,
the system crashed during acquisition,
the OS profile/symbols are unsupported,
malware uses anti-forensics,
the analyst treats suspicious output as proof without validation.

Corroborate memory findings with disk artifacts, EDR telemetry, SIEM logs, network logs, and timeline evidence.

PART E — REPORTING, VALIDATION, AND SANITIZATION

21. Validate before reporting

What we are doing

We are preventing tool output from becoming an unsupported conclusion.

Why this matters

Forensic tools parse artifacts. They do not know intent. A browser download artifact can show that a file was downloaded. It does not automatically prove who clicked the link or why.

Validation methods

Finding type	Validate with
Deleted file recovery	TSK metadata, file hash, carved content, filesystem timeline
Program execution	Prefetch + Amcache + event logs + EDR telemetry
USB usage	Registry USBSTOR + MountedDevices + SetupAPI logs
Web download	Browser history + download DB + file metadata + Zone.Identifier
Login activity	Authentication logs + endpoint logs + identity provider logs
Malware execution	Memory + disk artifact + EDR alert + network telemetry
Mobile message	App database + backup metadata + cloud/account record where available
Console activity	Console state + account records + router/cloud/platform logs

Confidence levels

Use clear language:

Confidence	Meaning
Confirmed	Multiple independent artifacts support the finding
Likely	Strong artifact support exists, but one important corroborating source is missing
Possible	One artifact suggests the finding, but alternate explanations remain
Inconclusive	Evidence is insufficient or conflicting

22. Report what you can prove

A forensic report should not read like a tool export.

Minimum report structure:

Authority and scope — who authorized the work, which devices/accounts were in scope, and what questions the examination was meant to answer.
Evidence inventory — evidence IDs, serial numbers, condition, acquisition method, hashes, and custody history.
Methodology — tools, versions, settings, validation steps, timezone handling, and known limitations.
Findings — each finding mapped to source artifacts, timestamps, and confidence level.
Corroboration — second-tool validation, independent artifact confirmation, or explanation when validation was not possible.
Limitations — encryption, unsupported artifacts, damaged media, missing logs, incomplete extraction, clock drift, or cloud data not collected.
Conclusion — concise answer to the investigation question without overstating intent or attribution.
Appendices — hashes, manifests, command logs, screenshots, exported artifacts, and chain-of-custody records.

Strong wording

The file invoice.xlsx was recovered from unallocated space in the NTFS volume image E-01-disk01.raw. The original filename and path were not recoverable from the carved output. The file content hash is <hash>. This supports prior existence of the file content on the imaged volume, but it does not by itself prove who created, opened, or deleted it.

Weak wording

The user deleted invoice.xlsx.

The second statement may be true, but it is not proven by carving alone.

23. Secure deletion and privacy-preserving disposal

What we are doing

We are destroying recoverability when evidence preservation is not the objective.

Why this must be separate from forensics

Sanitization is destructive. It should never be performed on evidence or on devices under legal hold, incident hold, HR hold, or regulatory retention.

Sanitization decision matrix

Media type	Preferred approach	Why
Rotational HDD	Full overwrite, ATA Secure Erase, or physical destruction depending sensitivity	Magnetic sectors can usually be overwritten predictably
SATA SSD	Vendor secure erase/sanitize or cryptographic erase where encryption was active	File-level overwrite is unreliable due to wear leveling
NVMe SSD	NVMe sanitize / format with secure erase option / cryptographic erase	NVMe has device-level sanitize commands
Modern encrypted laptop	Cryptographic erase plus reinstall/reset, if encryption was properly enabled before data storage	Destroying keys can make data unrecoverable quickly
iPhone/iPad	Erase All Content and Settings	Hardware-backed encryption keys are destroyed during reset
Android	Factory reset after confirming encryption was enabled; enterprise wipe where managed	Modern Android uses file-based encryption on supported devices
Game console	Remove accounts, factory reset, sanitize external media separately	Local and cloud/account data must both be considered
Highly sensitive or damaged media	Physical destruction by approved vendor	Ensures disposal when logical erase cannot be verified

Rotational HDD overwrite example

sudo shred -v -n 1 -z /dev/sdX

Use only when /dev/sdX is the disposal target, not evidence.

SATA SSD secure erase example

Check security state:

sudo hdparm -I /dev/sdX | grep -i security -A 20

Set a temporary password:

sudo hdparm --user-master u --security-set-pass Eins /dev/sdX

Run secure erase:

sudo hdparm --user-master u --security-erase Eins /dev/sdX

NVMe sanitize example

Check device:

sudo nvme id-ctrl /dev/nvme0

Run sanitize only after confirming target and policy:

sudo nvme sanitize /dev/nvme0 --sanact=1

Destructive command warning

Before running destructive commands:

confirm device path,
confirm evidence hold status,
confirm owner approval,
record serial number,
record command output,
verify completion,
retain sanitization certificate or log.

24. The end-to-end beginner workflow

Use this complete workflow when you do not know where to start.

Step 1 — Get authority

Ask:

Who authorized the work?
What devices/accounts are in scope?
Is this evidence preservation, incident response, recovery, or disposal?
Are there legal, HR, privacy, or regulatory constraints?

Output:

authority.pdf
scope-notes.txt
case-id.txt

Step 2 — Identify device state

Ask:

Is it powered on?
Is it unlocked?
Is it encrypted?
Is it connected to a network?
Is it damaged?
Is it a computer, phone, removable drive, or console?

Output:

scene-photos/
initial-device-state.txt

Step 3 — Choose the scenario workflow

Use the matrix:

Powered off computer → Section 7
Powered on computer → Section 8
Powered on encrypted laptop → Section 9
Failing disk → Section 10
Deleted files on HDD → Section 12
Deleted files on SSD → Section 13
Unlocked phone → Section 16
Locked phone → Section 17
Game console → Section 19
RAM analysis → Section 20
Secure disposal → Section 23

Step 4 — Acquire evidence

Minimum output:

evidence-master/
acquisition/logs/
acquisition/manifests/
hashes/

Step 5 — Verify evidence

Record:

SHA-256 hashes
tool verification output
read errors
operator notes

Step 6 — Analyze a working copy

Use:

Autopsy for beginner disk triage,
TSK for validation,
Volatility 3 for RAM,
iLEAPP/ALEAPP for mobile backups,
MVT for mobile compromise checks,
commercial tools where available and justified.

Step 7 — Validate findings

For every important finding, answer:

What artifact supports it?
What is the timestamp and timezone?
What tool parsed it?
Can another tool or raw artifact confirm it?
What are the limitations?
What alternate explanations exist?

Step 8 — Report carefully

Use facts before conclusions:

Observed fact → Tool output → Corroboration → Interpretation → Limitation

25. Common mistakes that destroy evidence

Avoid these mistakes:

Booting a powered-off suspect computer.
Plugging evidence media into a normal workstation.
Allowing Windows/macOS/Linux to auto-mount source media.
Running chkdsk, fsck, Disk Utility First Aid, or antivirus cleanup on original media.
Installing recovery software onto the same disk being recovered.
Pulling power from an unlocked encrypted laptop without considering RAM and live logical collection.
Letting an unlocked phone lock, die, or connect to the internet.
Updating a game console before preserving account and storage state.
Using PhotoRec output to claim user intent.
Treating a tool parser as ground truth.
Forgetting timezone handling.
Failing to hash evidence.
Mixing evidence preservation and secure erasure workflows.

26. Final operational principles

A reliable forensic practice is built on repeatable decisions:

Start with the device state.
Preserve volatile evidence before it disappears.
Do not analyze the original when a verified image can be created.
Use a hardware write blocker for offline media acquisition.
Treat SSD deleted-file recovery as uncertain after TRIM.
Treat encryption keys, unlocked sessions, and RAM as evidence.
Treat phones and game consoles as ecosystems, not only devices.
Record tool versions, command lines, hashes, timezones, and errors.
Validate critical findings independently.
Report only what the evidence supports.
Keep sanitization separate from evidence preservation.

The strongest forensic tool is not the most expensive product. It is a controlled process that lets another qualified examiner understand what you did, why you did it, what changed, what was preserved, and how your conclusion was reached.

1. The forensic mindset: know the objective before touching the device

2. The master workflow: the path every case should follow

3. First-response decision matrix: what to do first

4. Tool map: which tool to use, why, and when

5. Build the forensic workstation before the case

Minimum workstation controls

Why this matters

Case folder structure

Start a command-line acquisition log

6. Chain of custody: what to record before tools run

PART A — COMPUTER FORENSICS

7. Scenario: powered-off computer

What we are doing

Why we are doing it

Tools to use

Action flow

Example: E01 acquisition with ewfacquire

Evidence to keep

8. Scenario: powered-on computer

What we are doing

Why we are doing it

Tools to use

Action flow

Windows volatile commands

Windows RAM capture with WinPmem

Linux volatile commands

Linux RAM capture with AVML

Failure mode

9. Scenario: powered-on encrypted laptop

What we are doing

Why we are doing it

Tools to use

Action flow

What to collect first

What not to do

10. Scenario: failing HDD or unstable storage

What we are doing

Why normal imaging can fail

Tool to use: GNU ddrescue

Action flow

First pass: recover readable sectors without retries

Second pass: limited retries

When to stop and use a lab

11. Storage basics: SATA is not the opposite of SSD

12. Scenario: deleted files on HDD

What we are doing

Why recovery may work

Tools to use

Action flow

Identify partitions

List deleted files with The Sleuth Kit

Recover a file by metadata address

Carve files when metadata is gone

Reporting limitation

13. Scenario: deleted files on SSD

What we are doing

Why SSD recovery is different

Tools to use

Action flow

What to avoid

Better evidence sources on SSD cases

14. Analyze the image, not the source

What we are doing

Why we do it this way

Action flow

Prepare a working copy

Autopsy workflow

Manual validation examples

15. Computer artifact priorities

Windows

Linux

macOS

PART B — MOBILE FORENSICS

16. Scenario: powered-on unlocked phone

What we are doing

Why we are doing it

Tools to use

Action flow

What to document

What not to do

Example: E01 acquisition with `ewfacquire`

Tool to use: GNU `ddrescue`