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
Top comments (0)