Recovery lab · Free verification workshop
Recovered means the right bytes are back.
Test recovery software against known examples. Or check recovered files against a backup you still have, even when file names are lost. Take away findings that someone else can check.
For testers, learners & community helpers
What does recovery software actually return?
Open the test image in software that supports raw disk images. Compare its exports with the known originals and record the version and settings. Turn “it worked” into a finding others can verify.
Run your own experiment →For photographers & people with backups
Which recovered files match my backup?
Match multiple exports to their originals regardless of their names. Identify duplicate matches and missing contents. For two different files, inspect the first changed byte position.
Match against backups →Dealing with data loss right now? This lab checks files; it does not scan drives or recover data. Without an original or backup, it cannot establish completeness. First steps after data loss →
The short answer
Intact data, deleted entries and a negative control
Three files are deleted but their data is fully intact. A fourth file has been completely overwritten. Reference files and a verification script make both cases checkable. No customer data and no representative performance benchmark.
Verify files directly in your browser
Use the test dataset or your own files. No installation or upload: your browser only reads the selected files and calculates SHA-256.
Download the test package (ZIP)
Three exercises with checkable results
Local only · no transmission · no storage by this tool
Up to 64 MiB per file, 40 files and 256 MiB in total. For larger lab exports, use verify.py from the package. Select exported copies on a safe destination drive, never files directly from damaged media.
1. Test package and lab exports
Select the unchanged ZIP, extracted IMG or exported JPG, MP4 and WAV files. Matching works after renaming. Do not select the reference/ folder as your recovery result.
2. Compare your own files
Have an original, backup or known intact copy? Compare it with the recovered file. Without a reliable reference, this cannot establish completeness.
Match recovered files to their originals
Select available originals or backups, then your recovery exports. Matching finds identical contents even under new file names. Duplicate exports do not increase the result. Only the selected, non-empty original contents count.
No verification started yet.
Take away a reproducible record
Optional: record how you recovered the files. These details appear in your download and are not automatically verified. To compare software, document each run separately using the same source.
File names are replaced with file-1, file-2 … by default. Hashes and free text remain and can reveal information. Review before sharing. Nothing is published automatically.
Preview report before sharing
No verification started yet.
Everything for your own experiment
The package includes a 32 MiB image, four synthetic reference files, a manifest, our first measurement report (v1), and generation and verification scripts. Instructions are provided in German, English, French and Spanish. No account required.
ZIP: 240,206 bytes · SHA-256: 3614bb3b4a83dedbe0f8da371955c0d2b04ff7e054589379880232fba448a30f
Download the test package (ZIP)
Manifest and reference checksums (JSON)
Current measurement report v2 – 2026-09-15, version 0.7.4 (JSON)
What the image contains
Measured on 2026-09-15 using the source state of version 0.7.4 through an internal harness, against the unchanged v1 image. Three exported files exactly match their references and pass final verification without a warning; the source image stayed unchanged. GONE.JPG appears as an old directory entry but has no exportable content. Finding that entry does not constitute recovery.
| File | State in the image | SHA-256 after export | Final verification |
|---|---|---|---|
| PHOTO.JPG | Deleted, data intact | Exact match | Fully decoded |
| VIDEO.MP4 | Deleted, data intact | Exact match | Fully decoded |
| AUDIO.WAV | Deleted, data intact | Exact match | Fully decoded |
| GONE.JPG | Completely overwritten | Not exported | Not applicable |
In the first measurement on 2026-08-31, PHOTO.JPG was recovered byte for byte and decoded completely, but saved as PHOTO.UNVERIFIED.JPG: the read core rounded every access up to full 512-byte sectors and therefore reported an incomplete read at the end of the 6,078-byte file. The cause has been fixed since version 0.7.2 of 2026-09-02. The repeat on 2026-09-15 with the source state of 0.7.4 exports the file as PHOTO.JPG with the status “Fully checked”. Both reports remain available; the first is marked as superseded.
Repeat the verification
- 1
Extract the ZIP into a new folder. With Python 3.8 or later, run python3 verify.py inside it. On Windows the command may be python.
- 2
Open only frh-exfat-lab-v1.img as the source in recovery software. Do not repair the image or write it onto a physical drive.
- 3
Export recovered files into a separate, empty folder. Never place the supplied originals from reference/ inside the export folder; doing so would invalidate the comparison.
- 4
Run python3 verify.py --recovered /path/to/export-folder. Expect three complete hash matches and no complete match for GONE.JPG. The script only reads and makes no network requests.
Three exercises with checkable results
- 1
10 minutes: open the image in recovery software, export into an empty folder and select the exports above. Expect matches for PHOTO.JPG, VIDEO.MP4 and AUDIO.WAV, none for GONE.JPG. Record tool version and settings.
- 2
2 minutes: rename a copy of PHOTO.JPG. Its hash stays the same. File names and .UNVERIFIED suffixes alone say nothing about whether the bytes are complete.
- 3
5 minutes: deliberately check the supplied originals from reference/ separately. They match too; GONE.JPG triggers an additional warning. This shows why references must stay separate from exports.
How to interpret the results
| Finding | Meaning |
|---|---|
| Exact match | The selected file matches a reference. This proves neither a recovery operation nor the origin of the file. |
| No hash match | The bytes differ. Check the source, settings and contents; a difference alone does not tell you whether useful content remains. |
| Playable or preview visible | A preview often checks only a portion. For media, also verify the entire file with a suitable decoder. |
| No original available | Structure and decoder checks can find errors. They cannot prove equality with a lost original. |
Evidence and limits of this experiment
This is a publisher test, not an independent review. It tests the macOS recovery core, not the public app UI or Windows.
Files are contiguous. Fragmentation, damaged file systems, real camera media, encryption and physically damaged drives are outside this experiment. Four constructed cases cannot establish a general recovery rate.
build-fixture.py documents generation with macOS hdiutil and FFmpeg. A rebuild reproduces the scenario; image bytes can differ between tool versions. Use the published ZIP to repeat this exact experiment.
Git v2 (0.7.4): 41cfa871d765e511f7dca1a69b713be9efbf64a2 · Git v1: fe7ac77a7725e2d318a7246fb40494223c9c9972 · Image SHA-256: b67d5e35d49b1faa8cc48a12367328503429c28706b3bee7632d76e08dc83ae8
For editors and independent experiments
The test material is publicly accessible. Coverage can link directly to the dataset and methodology. No payment, mandatory link or prescribed test outcome is involved. Please document tool versions, settings and checksums when reporting your own measurements.