Week in Review: Synthetic Imaging, Hash Analysis, and Going Pure Go (Feb 18–22, 2026)
This week I built a new (to me) synthetic disk imaging mode, overhauled the hash analysis system with multi-database comparison and export, and eliminated CGO dependencies from the forensic image detection pipeline.
Synthetic Disk Imaging: create full-disk E01/AFF4/RAW images where encrypted partitions are replaced with decrypted data while keeping unallocated and multiple partitions in one image — readable without keys .
Hash analysis gains multi-database matching, per-job database selection, hash set export, tags, and a redesigned results UI.
Pure Go E01 metadata extraction replaces CGO/libewf in the image detection pipeline
AFF4 forensic containers get a full inline verification pipeline with per-stream hash comparison.
Forensic image mount/unmount system with tool integration.
Per-user Quick Add default profiles with three-tier configuration fallback.
Synthetic Disk Imaging
The most interesting capability this week that I’m still evaluating. Synthetic imaging creates a single forensic filetype (E01, AFF4, or RAW/DD) containing a full-disk image where encrypted partition content is transparently swapped with its decrypted counterpart. A forensic examiner receiving this image can open it in Autopsy, EnCase, X-Ways, or FTK and browse the filesystem directly — no encryption keys, no LUKS or Bitlocker tooling, no extra steps.
With LUKS for example, the GPT Starting LBA is shifted past the LUKS header so forensic tools find an ext4 or NTFS superblock exactly where they expect it. The encryption header is preserved as unallocated space, and a .synth.json sidecar captures the change records — the original unlocked volume vs the synthetic raw file systems are can be verified to be identical by hashing.
I built three new modules for this: an MBR/GPT partition table rewriter, a SyntheticStreamMux that routes sequential reads to the correct data source based on byte offset, and core orchestration handling for both partition-level and whole-disk LUKS encryption. I am still testing Bitlocker with this concept.
Hash Analysis System Overhaul
The File Hash Analyzer saw its biggest update yet. The comparison engine was rewritten from a single-winner model (stop at first database match) to a multi-match architecture that checks ALL reference databases independently and records one result per match. This means a file found in both an NSRL "known good" set and a custom "known bad" set now has both matches recorded and viewable separately.
Users can now select which hash list or database to compare against or leave comparison unselected to run in hash-only mode. After a job completes, results can be exported as a new reference hash list. I also added a tags system for organizing hash databases (full-stack: tag pills, filter bar, input widget) and a no-match CSV export for files not found in a specific database.
The parallel bloom filter engine got a progress reporting system — instead of the UI sitting at 0% during a 28-minute bloom filter build against the NSRL's 410 million hashes, users now see real-time progress with rate and ETA updates.
The results UI was redesigned with a dual-view architecture: a "Hashed Files" view (always available, shows every file that was hashed) and per-database comparison views with classification filtering and match statistics.
AFF4 Verification Pipeline
AFF4 forensic containers now have a inline verification pipeline. Previously, creating an AFF4 image with Verify=Yes did nothing — the verification system only handled E01. Now the system re-reads the entire container after writing, computes MD5/SHA1/SHA256/BLAKE3 for each stream independently, compares against acquisition hashes, stores detailed per-stream records, and displays the full hash comparison in the investigation UI.
Multi-stream metadata was also fixed — RDF turtle metadata now correctly lists all streams in combined containers (e.g., both disk/raw and volume/decrypted for BitLocker-encrypted drives) with per-stream hashes.
Pure Go E01 Metadata — Phase 1 Complete
I eliminated all CGO/libewf dependencies from the forensic image detection pipeline. The pure-Go E01 parser now handles metadata extraction, segment discovery, and disk size calculation without calling into C code. This was deployed to the running orchestrator service and verified with an E01 image — all metadata fields populated correctly.
Forensic Image Mounting & Tool Integration
I built a full mount/unmount subsystem for forensic images with tool integration. Tools will be able to parse EWF, AFF4 and .DD files as if they’re connected drives. Still a working in progress this next week.
Drive Hasher: 10x Throughput Fix
The forensic drive hasher had a fundamental I/O bottleneck hiding in its pipelined architecture. The 64 MB read buffers were being filled with only ~0.5 MB per pipeline cycle because os.File.Read() on Linux block devices returns only what the kernel readahead has ready. Switching to io.ReadFull — which loops until the full buffer is filled — reduced pipeline cycles by ~100x.
Profile System & Quick Add Defaults
I implemented a per-user Quick Add default profile system for tools — users can designate one configuration profile per tool as their personal Quick Add default, with a three-tier fallback: user profile → system profile → database defaults. The Profile Manager also gained full configuration support for Drive Formatter, Drive Imager, and Drive Wiper (previously only some tools had profile config in the web UI).
By the Numbers
25 non-merge commits across the week
98 files changed, ~17,800 lines inserted, ~1,900 lines deleted
1,709 lines of new code for synthetic imaging alone (3 new files)
1,723 lines across 16 files for the hash analysis redesign
3 new forensic image tool integration endpoints
A week heavy on new capabilities and infrastructure hardening. Synthetic imaging has been on the roadmap for a while as a curiosity, and seeing a fully decrypted disk image pop open in a standard forensic viewer without any key management was a satisfying milestone.
