DFRTI Tools & Innovations

We build forensic tools for storage, mobile, cloud, memory and malware work. The aim is simple: more accurate evidence, found faster, with every step on record.

Why we build our own tools

Commercial suites like EnCase, X-Ways Forensics and Magnet AXIOM handle the common cases well. Investigators still meet data that no suite reads yet: a new chat app's database, a DVR from a little-known maker, a log format from an IoT hub. When that happens, someone has to write a parser and prove it gives the right answer.

That is the gap our tool work fills. Most of it starts in our research areas and in questions that come up during training.

What we work on

Parsers and decoders
Code that reads app databases, proprietary DVR containers, drone logs and other formats and turns them into readable evidence.
Automation
Scripts and workflows for repeat tasks such as hashing, triage, timeline building and report drafts, so examiners spend their time on analysis.
Verification frameworks
Test harnesses that run a tool against reference data and check its output, so you know when an update changes the result.
Dataset generation
Pipelines that produce disk images, phone extractions and memory dumps with known contents, for testing and teaching.

How a tool is checked before use

A forensic tool is only useful if its output can be trusted in court. Every tool goes through the same checks.

01
Known test data
We build a dataset where we know exactly what is there, down to deleted files and timestamps.
02
Read-only handling
We confirm the tool works on a copy and changes nothing in the source, by hashing before and after.
03
Compare results
Its output is checked against the known contents and against an established tool where one exists.
04
Record the limits
We write down what the tool cannot read or may get wrong, so an examiner knows when to double-check.
05
Retest on update
Each new version runs through the same tests before it replaces the old one.