Frequently Asked Questions

OpenForensic v2.1.0 supports Windows 10 / 11 (64-bit), Linux (Ubuntu 20.04+, Debian, Arch, Fedora), and macOS 11 Big Sur or newer (including Apple Silicon via Rosetta 2 / native ARM builds). All three platforms receive the same feature set, though the RAM capture tools differ: WinPmem on Windows, LiME on Linux, and raw disk nodes on macOS.

Forensic disk imaging requires reading raw physical block devices (e.g., \\.\PhysicalDrive0 on Windows, /dev/sda on Linux) which are kernel-protected resources. Additionally, live RAM acquisition temporarily loads kernel-level drivers (WinPmem, LiME) that require ring-0 access. Without administrator / root privileges, these operations are blocked by the OS.

OpenForensic uses mise for reproducible toolchain management. Steps:

git clone https://github.com/rootwithkhandal/OpenForensic.git
cd OpenForensic
npm install           # Install Node.js dependencies for Tauri
mise run check        # Verify Rust toolchain & cargo check
npm run tauri dev     # Launch in development mode
npm run tauri build   # Compile optimized release binary

The compiled binary lands at src-tauri/target/release/openforensic.exe (Windows) or ./target/release/openforensic (Linux/macOS).

CPU: 4+ cores recommended for parallel SHA-512 hashing and YARA rule compilation.
RAM: 4 GB minimum; 8 GB+ recommended when analyzing multi-gigabyte RAM dumps with the native Rust Volatility engine.
Storage: NVMe / SSD destination recommended to avoid write bottlenecks during multi-algorithm hashing of large drives.

OpenForensic supports three output formats:

• Raw (.dd / .img) — Flat sector-by-sector copy. Stream hash == container hash. Simple and universally compatible.
• E01 (.e01) — EnCase Evidence File. Compressed segments with embedded metadata. Industry standard for court submissions.
• AFF (.aff) — Advanced Forensic Format. Segment-based with compression, metadata, and embedded stream hashes.

Write-blocking is enforced at the OS kernel boundary:

• Windows: Devices opened via CreateFileW requesting strictly GENERIC_READ with shared read access — the OS prevents any write flag from being set.
• Linux: Devices opened with O_RDONLY | O_DIRECT to bypass page caches. The BLKROSET ioctl is queried to verify read-only enforcement on block devices.
• macOS: Reads directly from raw disk nodes (/dev/rdiskX) for unbuffered, read-only hardware speed.

This is entirely normal and expected. AFF and E01 containers include more than raw data:

1. Metadata Inclusion: Case number, examiner name, timestamps, bad sector logs, and the stream hashes themselves are written into the file, changing its binary content.
2. Data Compression: Sectors are compressed with zstd or gzip — compressed bytes differ from raw bytes.
3. Container Structure: Segment headers, footers, and internal index tables add structural overhead.

Evidence integrity is verified via the acquisition stream hash embedded inside the container (verified by Autopsy, EnCase, etc. on decompression). The container hash only verifies the file wasn't corrupted during storage or transfer.

Yes. OpenForensic integrates a pure-Rust YARA-X engine that performs real-time pattern matching against custom .yar rulesets simultaneously while streaming disk data — with zero degradation to acquisition throughput. Attach your YARA ruleset in the Disk Imaging tab before starting. YARA hits are logged to the case's openforensic.db with byte offsets and sector numbers.

OpenForensic computes all four algorithms simultaneously in a single streaming read pass — no second-read disk I/O overhead:

• SHA-256 — NIST-approved primary cryptographic proof for court-ready evidence verification
• SHA-512 — NIST-approved extended proof with 512-bit digest
• MD5 — Legacy compatibility for NIST NSRL and VirusTotal cross-referencing
• SHA-1 — Legacy compatibility for historical case databases and CFTT verification suites

A plain hash (e.g., SHA-256 of the image file) proves the file was not corrupted, but does not prove who created it or when it was sealed. A Keyed Integrity Manifest goes further:

• Binds the hash to an investigator identity using HMAC-SHA256 with a 256-bit secret key
• Includes full case metadata (Case ID, examiner name, agency, timestamps, device geometry)
• Generates a tamper-evident .manifest / .sig file — even a single changed byte breaks the HMAC seal
• Enables court-admissible chain-of-custody without heavyweight OpenPGP dependencies

Capture Mode (default on launch): Strictly read-only acquisition — disk cloning, physical memory acquisition, cryptographic hashing, and general utilities. No external network connections or data mutations.

Analysis Mode (opt-in, requires confirmation): Unlocks post-acquisition investigative suites — Triage SQL Workbench, Native Rust Volatility RAM analysis, Timeline Generator, AbuseIPDB/VirusTotal IOC enrichment, and Splunk HEC/Wazuh SIEM streaming.

The boundary is enforced by Rust runtime guards (require_analysis_mode), dual static capability allowlists (capabilities/default.json and capabilities/analysis.json), and audit-logged in the SQLite audit_logs table.

1. Look at the top navigation bar — the badge shows 🟢 Capture Mode.
2. Click "Switch to Analysis Mode".
3. Confirm the dialog: "Switching to Analysis Mode unlocks deep analysis features, threat intelligence API enrichment, and live SIEM streaming. This disables further read-only evidence safeguards for this session."
4. The badge updates to 🔴 Analysis Mode Active and all previously locked tabs unlock immediately.

Pass the --mode analysis flag before your target subcommand:

openforensic --cli --mode analysis triage --dest /mnt/evidence/triage

openforensic --cli --mode analysis ram \
  --dump /mnt/evidence/memory.raw \
  --profile windows.pslist.PsList \
  --ioc-enrich

Yes. Every mode transition is cryptographically recorded in the audit_logs table of both the global cases.db and the portable per-case openforensic.db:

SELECT timestamp, event_type, details
FROM audit_logs
WHERE event_type = 'MODE_TRANSITION';

Example entries:

Timestamp	Event Type	Details
2026-07-09T07:15:00Z	APP_BOOT	Initialized in Capture Mode
2026-07-09T07:18:22Z	MODE_TRANSITION	Examiner 'ID-4402' switched to Analysis Mode
2026-07-09T07:19:05Z	SIEM_EXPORT_START	Triage exported to Splunk HEC (index: main_dfir)

No. OpenForensic includes a proprietary native Rust Volatility Engine (volatility/ workspace) that replaces Python-based Volatility 3 entirely. It operates as a pure native binary with zero Python interpreters, pip packages, or virtual environments required. This makes it ideal for:

• Field triage laptops without Python pre-installed
• Headless AWS EC2 / cloud servers without display managers
• Air-gapped forensic lab systems
• Automated SOAR pipelines requiring instant startup (no Python interpreter overhead)

This is expected and caused by Memory-Mapped I/O (MMIO). The CPU's physical address space is shared between your RAM and hardware devices (PCIe, GPU VRAM, ACPI tables, NICs). The OS shifts actual RAM addresses higher to accommodate these hardware reservations — pushing the highest physical address past your installed RAM boundary.

WinPmem reads from address 0x0 to the highest physical address, padding "holes" (MMIO ranges) with zeros to maintain accurate file offsets for memory analysis. Result: a 16 GB RAM system may produce a 16.5–17 GB raw dump.

If space matters: Modern memory formats like .aff4 or Windows Crash Dumps compress or omit zero-padded hardware holes. Raw (.raw) retains exact address mapping, which is why Volatility profiles depend on it.

The native Rust engine supports these profiles in v2.1.0:

Profile	OS	Capability
windows.pslist.PsList	Windows x64/x86	Enumerate processes via EPROCESS list
windows.netstat.NetStat	Windows x64/x86	Open TCP/UDP connections
windows.cmdline.CmdLine	Windows x64/x86	Process command-line arguments
windows.filescan.FileScan	Windows x64/x86	Open FILE_OBJECT handles
windows.malfind.Malfind	Windows x64/x86	Injected DLLs & hollowed processes
linux.pslist.PsList	Linux x64/ARM64	Kernel task_struct enumeration
mac.pslist.PsList	macOS x64/Apple Silicon	Darwin kernel process enumeration

OpenForensic supports two enterprise SIEM platforms in v2.1.0:

• Splunk HTTP Event Collector (HEC): Emits structured JSON events over HTTPS POST authenticated via HEC bearer tokens (Authorization: Splunk <token>). Automatically indexes running processes, network connections, browser visits, and OS event logs.
• Wazuh Agent Socket / Syslog: Formats forensic records into Wazuh JSON lines and streams them over TCP/UDP sockets (default port 1514) or appends to local log queues monitored by the active Wazuh agent.

SIEM integration requires Analysis Mode.

No. SIEM endpoints default to empty strings in all compiled binaries — ensuring internal lab URLs or hostnames are never accidentally shipped. In CLI mode, supplying --siem-endpoint is strictly validated and required whenever --siem-export is activated (enforced by clap's required_if_eq):

openforensic --cli --mode analysis triage \
  --siem-export \
  --siem-type splunk_hec \
  --siem-endpoint https://splunk.corp.example.com:8088 \
  --siem-token <HEC_TOKEN>

During memory analysis profiles (e.g., windows.netstat.NetStat or windows.malfind.Malfind), OpenForensic automatically:

• Extracts all unique remote IP addresses from network connections and queries AbuseIPDB reputation scores in real-time — flagging known C2 nodes and botnet infrastructure
• Computes cryptographic digests of suspicious memory sections or unlinked PE headers, querying VirusTotal detection matrices

Enable with --ioc-enrich in CLI mode or by checking the enrichment box in the RAM Analysis tab (Analysis Mode required). Your API keys are stored in the application configuration — never compiled into the binary.

Yes. OpenForensic's headless CLI mode (--cli) bypasses the Tauri GUI entirely, enabling full scriptable forensic automation on:

• AWS EC2 / cloud instances without display managers
• Remote SSH triage sessions
• SOAR pipeline automation
• Unattended overnight acquisition jobs

openforensic --cli list-devices
openforensic --cli acquire --source /dev/sda --dest /mnt/evidence/disk.e01 --format e01

Yes. The CLI supports automated signing and batch verification:

# Acquire and automatically sign the 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

# Batch verify all manifests in an archive directory
for sig in /archive/*.sig; do
  openforensic --cli verify-manifest \
    --manifest "$sig" \
    --pubkey /keys/openforensic_hmac.pub
done

The resulting .sig is a cleartext ASCII-armored file — easy to parse and archive in automated intake systems.