Published research images
Widely used public forensic corpora and teaching images with community-documented contents, so results can be checked against work published outside GhostKey.
Home/Validation
Prove the tool itself works
Bloodhound ships with an autonomous validation suite that tests its parsers against known reference datasets and produces a signed validation report, giving you documented, defensible proof of tool reliability before anyone asks for it.
Why it ships in the box
“How do you know the tool parsed it correctly?”
It is a fair question, and it gets asked under oath. The usual answer is a vendor assurance or an examiner’s own spot-check, carried out months after the work was done.
Our answer is a reproducible test run against datasets with known ground truth, executed by the same build of the software that processed your case, signed and dated.
RUN 2026.09.1 build a7f31c2 node gk-node-01
PASS ewf.reader.integrity hash match
PASS raw.reader.sector.map exact
PASS aff4.reader.stream exact
PASS ios.messages.sms 142/142
PASS ios.messages.attachments 61/61
PASS ios.locations.cache 88/88
PASS android.calllog.active 310/310
PASS android.calllog.deleted 64/64
PASS sqlite.wal.recovery 207/207
PASS exif.timestamp.tz normalised
PASS timeline.ordering stable
PASS hashset.nsrl.match no false pos
42 checks — 42 passed, 0 failed, 0 skipped
report validation-2026.09.1.pdf [SIGNED]
Reference datasets
Tested against evidence whose contents are already known
A validation run only means something if the correct answer is known in advance. Bloodhound validates against curated datasets with documented ground truth: every record, every timestamp, every deliberately deleted row.
GhostKey-constructed devices
Handsets and disks populated under controlled, logged conditions: messages sent at recorded times, records deleted at recorded points, media captured at recorded coordinates.
Your own reference data
Labs can register their own reference images and expected-result definitions, so the suite runs against the device populations and OS versions that lab sees in casework.
What the suite checks
What a run covers
| Check class | What it asserts | Failure means |
|---|---|---|
| Image reader integrity | Bytes read from E01, raw, AFF4 and virtual disks match the source exactly | The container layer is unreliable, so nothing above it can be trusted |
| Record extraction | Parsers return every expected record, and no records that do not exist | Evidence is being missed, or invented by a faulty parser |
| Deleted recovery | Known-deleted rows are recovered and correctly labelled as deleted | Recovered material could be presented as live data |
| Timestamp normalisation | Times convert correctly across timezones, epochs and DST boundaries | The timeline is wrong, and so is anything concluded from it |
| Timeline ordering | Event ordering is stable and deterministic across repeated runs | Two examiners could produce different chronologies from one image |
| Hash-set matching | Known material matches, known-good is suppressed, no false positives | Alerting is unreliable in both directions |
| Custody enforcement | Ledger entries are written, chained and signed for every covered action | The custody guarantee is not holding |
| Determinism | Identical input produces byte-identical parsed output across runs and hosts | Results are not reproducible by a third party |
VALIDATION REPORT — BLOODHOUND 2026.09.1
GhostKey Development Inc.
build a7f31c2 (reproducible)
executed 2026-09-15T04:00:11Z
host gk-node-01 (air-gapped)
datasets 7 reference sets, 14 images
checks 42 executed / 42 passed
coverage 41 parsers, 6 image readers
determinism 3 repeat runs, output identical
sha256 2b81f4dc…90ae7715
signature VALID (ed25519)
Attach to disclosure alongside case report.
The output
A signed validation report you can hand over
Each run produces a dated, signed PDF naming the build under test, the datasets used, and every check executed with its result. It is meant to be disclosed alongside the case report.
- Names the exact build that processed your evidence, down to the commit
- Lists every check, its expected result and its observed result
- Records determinism runs proving repeatability
- Signed and hash-anchored, so a third party can verify it offline
- Referenced automatically in the methodology section of case reports
Cadence
When the suite runs
ON BUILD
Every release
No build ships until the full suite passes on a clean, air-gapped host.
ON INSTALL
In your lab
Run it on your own hardware after deployment to establish a local baseline.
ON SCHEDULE
Periodic runs
Scheduled runs keep your documented reliability evidence current.
ON DEMAND
Before testimony
Re-run against the build used in a case and attach the fresh report to disclosure.
When a tool cannot demonstrate its own reliability, the examiner ends up carrying that burden personally, usually on the stand. We would rather the software carried it.
Validate it against your reference data
Evaluation licences include the validation suite and the reference datasets it runs against.