← Back to Blog

Why I'm Building Sprite

The Problem

I've been working in digital forensics for a while now, and there's something about how the industry works that's been bugging me.

If you're at a big agency, you've probably got budget for the major tools. Cellebrite, Magnet, EnCase, whatever. It's expensive, but it's a line item and someone approves it. If you're at a small practice or you're an independent examiner, you're in a weird spot. The same tools cost the same money (or more!), but you're not processing the same volume, and you're definitely not working with the same margins. You end up paying for a massive suite of features you'll never touch, or you're managing a patchwork of open-source tools yourself, dealing with setup, dependencies, and trying to get outputs into a consistent format.

Neither option is great.

This isn't how software works anymore in most fields. If I need to spin up cloud infrastructure, I pay for what I use. If I need a specific capability, I can usually find something modular that does that one thing well. But forensic tooling is still sold like enterprise software from 2005: big bundles, seat licenses, and formats that don't talk to each other.

What I'm Building

Sprite is an attempt to fix some of this. It's a platform (API, SDK, marketplace) that lets you run forensic plugins on demand, pay per use, and keep everything in your own cloud environment. You're not sending evidence anywhere. Processing happens in your AWS or Azure account, you maintain control, and the output is in CASE format so your evidence is not locked away or obscured inside some proprietary db or file.

I've already adapted the iLEAPP parsers to work with it for iOS, wrote our own completely serverless E01 verifier in Go, a serverless raw disk image search courtesy of Bulk_Extractor (with a Sprite wrapper) — and even a simple frontend. The idea is that other developers can build and sell plugins through the marketplace too, so there's actually an ecosystem, and because there's an SDK the barriers for development are much lower. As a plugin developer you wouldn't need to understand how or where to store that information, you just concentrate on the forensic side. No frontend development, or backend storage creation or defaulting to reporting via csv.

Why I Think This Matters

Partly it's the cost thing. Small practices shouldn't have to choose between expensive monoliths and managing everything themselves.

It's also about what happens when evidence data is portable and tools are interoperable. If your data is trapped in a proprietary format, switching is painful, so you don't. CASE changes that, so that you can pick and choose your own frontends, or build your own.

Anyway I'm aiming to have a beta ready soon. If any of this sounds interesting, there's a signup at sprite.wesdx.com. And if you think I'm missing something or getting something wrong, I'd genuinely like to know.