Forensic File Carver
A C# forensic file-carving implementation that scans large binary sources as streams, shares signature prefixes in a byte trie, and applies format-aware boundary checks when a defensible end position can be determined.
This project isolates a file-carving approach I use when filesystem metadata is absent, damaged, or no longer sufficient for a trustworthy recovery decision. Rather than scanning the source independently for every signature, the scanner stores shared byte prefixes in a trie. Input is consumed in overlapping blocks so a signature split across two reads is still visible, while the source itself remains stream-based instead of being materialized in memory.
A header hit is deliberately treated as a candidate, not as proof of a recovered file. Where the format exposes defensible structure, the implementation derives boundaries from that structure: RIFF lengths, ZIP end-of-central-directory data, SQLite page information, TAR records, PCAP block lengths, or ISO-BMFF boxes are examples. Formats without a reliable generic end rule can remain detected-only. That conservative distinction is more useful in forensic work than producing a plausible-looking file from an unsupported boundary guess.
For another forensic transformation stage, see Forensic Telephony WAVE Decoder. The design rationale behind the scanner is discussed separately in A Data Carving Algorithm for Digital Forensics.
Source: GitHub Zenodo record: Zenodo DOI: DOI
The Place of File Carving in a Forensic Examination
A carver is more than a signature matcher; its output must be interpreted together with filesystem state, timeline evidence and acquisition history. Chain of Custody records how the examined medium was handled, while a Forensic Timeline helps place timestamps from different evidence sources into an event sequence.
On NTFS, file content is only one evidence source. The Master File Table carries filesystem metadata, the USN Journal records part of the change history, and an Alternate Data Stream can hold data separately from the primary file stream. Volume Shadow Copy can provide historical versions of files that were later modified or deleted.
Evidence outside the filesystem also matters. A Registry Hive preserves persistent system and user configuration, Memory Forensics targets volatile process, key or connection state, and Network Forensics can relate local artifacts to communication flows. Because these sources have different temporal and reliability boundaries, I do not treat carving output alone as conclusive evidence of an event.
