Filo-Go Performance Update: Why I Replaced Binwalk with a Go-Based Forensics Engine

Supun Hewagamage — Tue, 09 Jun 2026 06:03:46 +0000

I recently rebuilt and benchmarked Filo-Go, a Go-native forensic analysis toolkit designed to replace tools like Binwalk, file, strings, and parts of ExifTool workflows.

This update is not about features.

It’s about performance.

Why Performance Matters in Forensics

Digital forensics workloads are fundamentally different from general file utilities:

Large firmware images (100MB–multiple GB)
Batch analysis of thousands of artifacts
Repeated scanning, carving, and entropy operations
Time-sensitive malware triage

In practice, slow tooling becomes a bottleneck in investigations.

Benchmark Setup

Benchmarks were run on:

CPU: Intel Xeon Platinum 8488C
OS: Linux AMD64
Workload: Synthetic + real forensic samples
Comparison tools: Binwalk, standard Unix utilities

All tests were executed cold to avoid caching effects where possible.

Results

Core Operations

Operation	Filo-Go	Baseline Tool	Speedup
File Analysis (1MB)	1.07 ms	644 ms (binwalk)	~600×
Entropy Analysis (1MB)	595 µs	632 ms (binwalk)	~1,061×
File Carving (10MB)	14.6 ms	2.22 s (binwalk)	~153×
Hash Computation (1MB)	885 µs	5.47 ms (sha256sum)	~6×
String Extraction (1MB)	633 ns	9.54 ms (strings)	~15,000×

What Actually Causes This Performance Gap

These results are not magic. They come from a few structural decisions:

1. Single-Binary Architecture

No Python/Perl runtime overhead, no interpreter dispatch.

2. Go Concurrency Model

Parallelized scanning and analysis pipelines where applicable.

3. Zero External Dependencies

No libmagic, no shelling out to system tools.

4. Memory-Streamed Processing

Avoiding full file materialization where possible.

5. Purpose-Built Pipelines

Each module is designed specifically for forensic workloads, not general-purpose file handling.

Important Caveats

These benchmarks are not universal truth.

They depend on:

File size distribution
Filesystem behavior
Tool configuration
Hardware characteristics

Also:

Binwalk is feature-rich and highly mature
Some features are not comparable 1:1
Real-world workflows include overhead beyond raw execution time

This is a systems comparison, not a feature comparison.

Why This Matters

The goal of Filo-Go is not to “replace everything faster”.

It is to reduce friction in forensic workflows:

fewer tool switches
faster triage cycles
consistent output formats
single CLI surface
scriptable analysis pipelines

Performance is only one part of that equation.

What’s Next

Current focus areas:

expanding firmware coverage
improving analysis accuracy for executables
refining plugin execution model
adding richer structured outputs
further optimizing carving and entropy pipelines

Future benchmarks will include:

real malware datasets
multi-gigabyte firmware images
concurrent batch workloads

Closing

Filo-Go is still early, but the current results validate the design direction.

Not because it is “faster than everything” — but because it shows that consolidating forensic tooling into a single Go-native system is viable without sacrificing performance.

Repository: filo-go

Building filo-go: Reimagining Digital Forensics in Go

Supun Hewagamage — Tue, 09 Jun 2026 04:48:30 +0000

As a cybersecurity student, I spend a lot of time working with tools like Binwalk, ExifTool, file, strings, and YARA.

They're powerful, but the workflow is fragmented.

Analyzing a suspicious file often means bouncing between multiple tools, different output formats, and various dependencies.

So I started building Filo-Go.

What is Filo-Go?

Filo-Go (Forensic Intelligence & Learning Operator) is a Go-based digital forensics and file intelligence toolkit.

The goal is simple:

Provide a single, fast, cross-platform binary for common forensic analysis tasks.

Current capabilities include:

File identification and analysis
Entropy visualization
Metadata extraction
String extraction
Firmware analysis
Executable analysis (PE, ELF, Mach-O)
YARA scanning
PCAP analysis
SQLite inspection
Plugin support
MCP integration for AI-assisted workflows

Why Go?

I wanted something that is:

Fast
Easy to distribute
Cross-platform
Dependency-light

Go checked every box.

Why Am I Building It?

Partly because I need it.

Partly because I want to better understand how forensic tools work internally.

And partly because building systems like this is one of the best ways to learn software engineering, cybersecurity, reverse engineering, and digital forensics.

What's Next?

I'll be sharing architecture decisions, implementation details, performance benchmarks, and lessons learned as the project evolves.

Repository: filo-go

Feedback, ideas, and contributions are welcome.

DEV Community: Supun Hewagamage