Help & Documentation

Disk Imaging

OpenForensic's Disk Imaging module performs forensically sound, bit-for-bit sector-by-sector and logical file acquisition. The engine enforces read-only access at the OS kernel boundary.

Supported Output Formats

Step-by-Step: Acquire a Disk Image

Understanding Container vs. Stream Hashes

When acquiring to AFF or E01 format, the Post-Acquisition (container) hash will NOT match the stream hash. This is normal — AFF/E01 files include metadata, compressed data, and internal structures that change the file's binary composition.

Integrity of evidence is verified via the acquisition stream hash embedded inside the container. Analysis tools like Autopsy re-compute this hash on decompressed data to confirm integrity.

Live Acquisition

The Live Acquisition module enables zero-downtime evidence collection from a running system. It uses Volume Shadow Copy Service (VSS) on Windows to freeze filesystem state, capturing OS-locked artifacts without rebooting.

RAM Capture Process

Why is My RAM Dump Larger Than Installed RAM?

A system with 16 GB RAM may produce a 16.5–17 GB dump. This is expected behavior caused by Memory-Mapped I/O (MMIO): PCIe devices, ACPI tables, and GPU VRAM are mapped into the CPU's physical address space, pushing the highest physical address past the 16 GB boundary. WinPmem pads these hardware holes with zeros to preserve accurate file offsets for memory analysis tools.

System Triage

The System Triage module provides instantaneous extraction of volatile system state from a running or acquired system. Results are stored in an SQLite database for querying.

What Gets Collected

• Running processes and their command-line arguments
• Active and listening network connections (TCP/UDP)
• Loaded kernel modules and drivers
• Chrome and Edge browser history databases
• Windows Event Logs (EVTX) and syslog event records

Triage SQL Workbench

Once in Analysis Mode, the SQL Workbench allows you to execute queries directly against the acquired triage_results.db:

-- Find all processes with network connections
SELECT p.name, p.pid, n.remote_addr, n.remote_port
FROM processes p
JOIN network_connections n ON p.pid = n.pid
WHERE n.state = 'ESTABLISHED';

-- Recent browser history
SELECT url, title, visit_time FROM browser_history
ORDER BY visit_time DESC LIMIT 50;

RAM Analysis — Native Rust Volatility Engine

OpenForensic includes a proprietary native Rust memory forensics engine in the volatility/ workspace. It replaces Python-based Volatility 3 with a standalone, in-process analyzer featuring zero external dependencies, in-process real-time streaming, and Rust memory safety guarantees.

Supported Analysis Profiles

Running RAM Analysis

Case Management & Unified Case Architecture

OpenForensic implements a native Unified Forensic Case Folder Architecture, ensuring every disk image, triage database, timeline, and report for a single case resides in one standardized, central directory.

Case Directory Structure

📁 <CaseRoot>/<CaseNumber>/
├── 📁 Cache/         # Temporary indexing, YARA artifacts, scratch space
├── 📁 Export/        # Disk images (.dd, .e01), carved files, timeline CSVs
├── 📁 Log/           # Acquisition logs, audit trails, hash records
├── 📁 ModuleOutput/  # Triage SQLite DBs, Volatility outputs, RAM analysis
├── 📁 Reports/       # HTML, JSON, PDF forensic reports
├── 📄 <CaseName>.ofc # JSON case container manifest (v2.1.0)
└── 🗄️ openforensic.db # Portable per-case SQLite database

Creating a New Case

Capture Mode vs. Analysis Mode

OpenForensic enforces a strict defense-in-depth boundary between data acquisition and post-acquisition analysis to protect chain-of-custody and prevent evidence modification during active field collections.

Default: Capture Mode 🟢

On launch, the application operates in read-only Capture Mode. Only non-invasive physical/logical acquisition, cryptographic hashing, and general utilities are active. External network connections are blocked.

Switching to Analysis Mode 🔴

Analysis Mode Features Unlocked

• ⚡ Triage SQL Workbench
• 🧠 Native Rust Volatility RAM Analysis
• ⏱️ Timeline Generator (NTFS MFT, Ext4 journals)
• 🛡️ AbuseIPDB & VirusTotal IOC enrichment
• 🛡️ Splunk HEC & Wazuh SIEM streaming
• 🔑 RAM Master-Key extraction (BitLocker VMK, LUKS)

Cryptographic Hash Verification

OpenForensic performs simultaneous multi-algorithm streaming hash verification at three stages of the acquisition lifecycle to ensure bit-for-bit evidence integrity.

The Three Hashing Stages

Why AFF/E01 Container Hashes Differ from Stream Hashes

This is normal and expected. AFF and E01 containers include compressed data, embedded case metadata, internal segment headers, and the stream hash itself — all of which change the file's binary composition vs. a flat raw copy.

• To verify evidence integrity: Use the acquisition stream hash embedded inside the container. Analysis tools (Autopsy, EnCase) verify this automatically.
• To verify file integrity: Use the container hash to confirm the file wasn't corrupted during storage or network transfer.

CLI Reference

OpenForensic includes a native command-line interface for headless forensic automation — ideal for AWS EC2 cloud triage, remote SSH investigations, or SOAR pipeline integration.

Common Commands

# List detected physical block devices
openforensic --cli list-devices

# E01 acquisition with zstd compression and SHA-256/SHA-512 hashing
openforensic --cli acquire \
  --source \\.\PhysicalDrive0 \
  --dest D:\evidence\disk.e01 \
  --format e01 \
  --compression zstd \
  --hashes md5,sha256,sha512

# Rapid live triage with Splunk HEC SIEM streaming (Analysis Mode)
openforensic --cli --mode analysis triage \
  --dest C:\triage_output \
  --siem-export \
  --siem-type splunk_hec \
  --siem-endpoint https://splunk.example.com:8088 \
  --siem-token <HEC_TOKEN>

# RAM analysis with AbuseIPDB enrichment (Analysis Mode)
openforensic --cli --mode analysis ram \
  --dump memory.raw \
  --profile windows.pslist.PsList \
  --ioc-enrich

# Generate and sign an integrity manifest
openforensic --cli acquire \
  --source /dev/sda \
  --dest /mnt/evidence/drive.raw \
  --format raw \
  --hashes md5,sha1,sha256,sha512 \
  --sign-manifest \
  --key /keys/openforensic_hmac.key

# Verify a manifest
openforensic --cli verify-manifest \
  --manifest /mnt/evidence/drive.raw.sig \
  --pubkey /keys/openforensic_hmac.pub

Keyed Cryptographic Integrity Manifests

OpenForensic generates HMAC-SHA256 keyed integrity manifests that mathematically bind evidence containers to the investigating examiner — producing tamper-evident signatures for court admissibility without requiring heavy OpenPGP tooling.

What a Manifest Contains

• Case ID, Evidence Tag, Examiner Name, Agency Name, and acquisition timestamps
• Source device path, serial number, sector size, and total byte count
• Cryptographic hashes (MD5, SHA-1, SHA-256, SHA-512) of the acquired image
• HMAC-SHA256 integrity seal generated with the investigator's 256-bit secret key

Generating a Keypair

Verifying a Manifest