File Recovery Hero — exFAT Recovery-Labor v1, 31.08.2026

Ein künstliches 32-MiB-Image mit drei gelöschten, zusammenhängend erhaltenen
Dateien (JPG, MP4, WAV) und einer vollständig überschriebenen JPG-Gegenprobe.
Keine Kundendaten. Die Einträge wurden gezielt konstruiert, nicht durch einen
Kameralauf erzeugt. Kein repräsentativer Benchmark oder Erfolgsversprechen.

1. ZIP in einen neuen Ordner entpacken. Python 3.8 oder neuer verwenden.
2. Im entpackten Ordner: python3 verify.py
3. Nur frh-exfat-lab-v1.img als Quelle in einer Recovery-Software öffnen.
   Nicht auf einen Datenträger zurückschreiben. Das Image nicht reparieren.
4. Gerettete Dateien in einen separaten, leeren Ordner exportieren.
   reference/ enthält die Originale: niemals in den Exportordner kopieren!
5. python3 verify.py --recovered /pfad/zum/exportordner
   Unter Windows kann der Befehl python statt python3 heißen.

Das Skript liest nur; es installiert nichts, mountet nichts und sendet nichts.
Es prüft vollständige SHA-256-Gleichheit, unabhängig von geretteten Dateinamen.
Erwartet: drei vollständige Treffer; GONE.JPG ohne vollständigen Treffer.
Ein alter Dateiname allein ist keine erfolgreiche Wiederherstellung.

results.json: Herausgebertest des macOS-Quellcodes am angegebenen Git-Stand
über ein internes Testprogramm, kein Test der öffentlichen App-Oberfläche
und kein Windows-Test. JPG, MP4 und WAV sind bytegleich und vollständig
decodierbar. JPG trägt dennoch .UNVERIFIED wegen eines internen Lesezugriffs
am Dateiende. Diese Warnung wird nicht verschwiegen oder als Fehlerfreiheit
gewertet. GONE.JPG wird erkannt, aber nicht exportiert.

build-fixture.py dokumentiert die Erzeugung. Neubau nur auf macOS mit hdiutil
und FFmpeg: python3 build-fixture.py --out neuer-ordner --ffmpeg /pfad/ffmpeg
Erzeugt nur neue Dateien. Ein Neubau reproduziert den Fall, nicht zwingend
dieselben Image-Bytes bei anderen macOS-/FFmpeg-Versionen.

Prüfbericht und dauerhaft adressierbare Quelle:
https://file-recovery-hero.com/recovery-labor/
