SkyFire RecoveryForensic & Professional

Built for government. Built for court.

Recovery was designed from the start for law enforcement, federal investigators, legal proceedings, medical records, and aerospace incident review — not retrofitted for forensic use after the fact. Every decision in the architecture reflects that.

Write-blocking — hard abort, not a warning

This is the first and most important point.

The acquisition engine opens source media strictly read-only. If read-only access cannot be confirmed, the engine returns an error and aborts — it does not proceed with a warning.

Hardware write-blocker detection is separate: if a hardware blocker is not detected, the session logs a warning and continues with software-enforced read-only. The source is never writable under any code path.

ACPO Principle 1

This satisfies ACPO Principle 1 at the architectural level — not as a policy statement, as enforced behavior.

Three-pass disk imaging

Verified from imager.rs source.

P1

Pass 1Forward sweep

Sector by sector, configurable retry count. Streaming SHA-256 computed inline during the write pass — the source is never re-read to compute its hash. Progress checkpointed every N sectors (configurable).

P2

Pass 2Reverse sweep

Every LBA that failed Pass 1 is retried in reverse order with additional retries. Reverse approach sometimes recovers sectors that forward reads miss on degraded media.

P3

Pass 3Sub-sector recovery

64-byte chunk reads on sectors still failing after Pass 2. Assembles partial reads — whatever bytes survive are preserved rather than lost.

Full resume capability

If acquisition is interrupted — power loss, disconnect — it resumes from the last confirmed LBA rather than restarting from scratch. The bad block map (JSON sidecar) survives crashes.

Output & hash verification

Output: .dd raw sector image. Source SHA-256 and image SHA-256 computed and compared. Hash mismatch with zero bad sectors triggers an explicit warning.

File carver — 40+ signatures, internal validation, confidence scoring

Verified from carver.rs source.

Not header-only matching. Each file type has internal structure validation — a JPEG is validated beyond its magic bytes, a ZIP requires both local file headers and central directory, a PDF requires both %PDF- and %%EOF. False positive rate is minimized by this secondary validation layer.

40+ file type signatures including

JPEGPNGGIF 87aGIF 89aBMPTIFF LETIFF BEWebPMP4/MOVAVIMKVWAVMP3OGGFLACPDFZIP/Office7-ZipRARGZIP/TGZSQLiteELF binaryPE executableMach-O 32-bit LEMach-O 64-bit LEMach-O 32-bit BEMach-O Fat binaryApple plist (binary)Apple plist (XML)Email (MIME)ext2/3/4 filesystem images

Reconstruction confidence scoring

Each carved fragment receives: header confirmed, footer confirmed, internal structure valid, entropy score, read error count and retry count, continuity score (0–1), byte offset, LBA range, acquisition source, and SHA-256 of the fragment. Overlapping fragments are deduplicated by confidence. Gap-crossing carving with synthetic region tracking.

0.97Perfect — header, footer, structure all confirmed
0.82Footer + internal valid, some read errors
0.68Internal structure valid only
0.55Footer confirmed only
0.30Header confirmed only

Chain of custody

Verified from AuditLogger.swift, Manifest.swift, KeyManager.swift, Verifier.swift, CHAIN_OF_CUSTODY.md.

Every Recovery session produces an output bundle.

Output bundle structure

output/

extracted/recovered files

carved/signature-carved files

manifest.jsonSHA-256 hash of every file

manifest.sigEd25519 signature over manifest.json

public.keyverification key (included in bundle)

audit.loghash-chained tamper-evident audit trail

Hash-chained audit log

Each entry hashes the previous entry's hash combined with the current entry. Tampering with any entry breaks every subsequent entry in the chain. The verifier detects breaks automatically.

Ed25519 manifest signature

The signing key is stored in the macOS Keychain. The public key is included in the output bundle so any party can verify independently — no access to Recovery required.

skyfire-verify /path/to/output

CLI tool. Exits 0 if authentic. Non-zero with specific failure reason if not. Usable in automated forensic workflows and scripted verification pipelines.

On-device AI report generation — no data egress

Verified from ForensicReportGenerator.swift.

Recovery uses Apple's Foundation Models framework (on-device, macOS Golden Gate+) to assist with generating plain-language forensic report summaries. No data leaves the machine. The AI runs locally on Apple Silicon.

This satisfies the data handling requirements of government, law enforcement, and medical contexts where sending case data to external servers is prohibited.

The chain-of-custody narrative is always deterministic — AI is never used for evidence facts. AI assists only with the human-readable summary layer. On pre-macOS Golden Gate systems, a deterministic template fallback is used automatically.

Filesystem support

Six native parsers — Rust, compiled to static library.

APFS

B-tree traversal, snapshot support

HFS+

Catalog B-tree, extents overflow

NTFS

MFT record parsing, $MFT bitmap

exFAT

Directory entry chains, FAT table

FAT12/16/32

ext4

Inode table, extent tree, journal

Case management

SQLite case database — local, never remote.

Case

Contains evidence items

Evidence

Source path, image path, SHA-256, acquisition timestamp, operator

chain_of_custody[]

Per-evidence custody events

Findings

File name, recovered path, confidence score, whether it was carved, SHA-256

Structure: Case → Evidence[] → chain_of_custody[] → Findings[]

Operator documentation

Six documents included with Recovery.

Chain of Custody guide

Forensic Process guide

Operator SOP

Pre/during/post-run procedures

Verification Guide

Explicitly states what is and is not verified

Error Matrix

Each error mapped to forensic impact, immediate action, escalation path

If/Then Decision Guide

On the Verification Guide. It explicitly states what is NOT verified — completeness, TSA timestamp binding. This honesty is intentional. A court will ask, and the answer should be in the documentation.

Standards alignment

Alignment means the architecture satisfies the requirements these standards define. Formal certification is a separate process.

ACPO

ACPO Good Practice Guide for Digital Evidence

Principle 1: write-blocking enforced at the architecture level, not as policy. Principle 2: hash-chained, signed audit trail. Principle 3: competence documentation included.

NIST SP 800-86

Guide to Integrating Forensic Techniques into Incident Response

Forensic image acquired before any examination. All steps documented. Evidence integrity verified with SHA-256 at acquisition and at report time.

ISO/IEC 27037

Digital evidence identification, collection, acquisition, preservation

Acquisition engine is non-destructive by architecture. Chain of custody bundle satisfies identification, collection, acquisition, and preservation requirements.

Who uses the forensic mode

Any context where the integrity of recovered data must be demonstrable, not just asserted.

Law enforcement and federal investigators

Corporate HR and legal — employee misconduct, fraud investigation

Medical records and HIPAA incident response

Aerospace incident review

Legal discovery

Private investigation

Ready to go deeper?

See how the acquisition engine, carver, and chain-of-custody system work together, or compare with personal recovery.