Gelöschte Dateien wiederherstellen: Metadatenwiederherstellung im Vergleich zu Carving

Das Löschen einer Datei entfernt nur selten ihren Inhalt: Das Dateisystem markiert die Metadaten und Cluster als frei, und die Bytes bleiben erhalten, bis der Speicherplatz erneut verwendet wird oder das Gerät sie verwirft. Diese Lektion vergleicht Metadatenwiederherstellung und File Carving: was die jeweilige Methode wiederherstellt, welche Grenzen sie hat und wie Sie das Ergebnis validieren und dokumentieren. Prüfungsfragen verlangen häufig die genaue Eingabe für die Hashberechnung, die Datensatznummer oder den Byte-Offset einer solchen Wiederherstellung.

Zwei Arten der Wiederherstellung

Metadatenwiederherstellung funktioniert, solange das Dateisystem die gelöschte Datei noch beschreibt. Die Struktur, die den Namen, die Größe und den Speicherort der Datei enthielt, ist als unbenutzt markiert, wurde aber noch nicht überschrieben. Daher kann ein Werkzeug den alten Verweisen zu den alten Clustern folgen.

• NTFS. Beim Löschen wird das Belegt-Flag im MFT-Datensatzheader (das 2-Byte-Flags-Feld bei Offset 0x16) zurückgesetzt: Aus 0x0001 wird bei einer Datei 0x0000, aus 0x0003 wird bei einem Verzeichnis 0x0002. Das Bit des Datensatzes in der eigenen Bitmap der MFT und die Cluster-Bits der Datei in $Bitmap werden zurückgesetzt, und der Eintrag wird aus dem Index des übergeordneten Verzeichnisses entfernt. Der Datensatz selbst bleibt mit seinen Attributen $STANDARD_INFORMATION, $FILE_NAME und $DATA normalerweise intakt, bis er erneut verwendet wird. Eine residente Datei (Daten innerhalb des Datensatzes) wird allein aus dem Datensatz wiederhergestellt.
• FAT. Das erste Byte des 32-Byte-Verzeichniseintrags wird auf 0xE5 gesetzt, und die Clusterkette der Datei in der FAT wird mit Nullen überschrieben. Der Rest des Namens, die Zeitstempel, der Startcluster und die Dateigröße bleiben erhalten. Daher kann ein Werkzeug die Datei wiederherstellen, indem es eine zusammenhängende Speicherung annimmt und ceil(Größe / Clustergröße) Cluster ab dem Startcluster liest. Bei exFAT wird das Belegt-Bit jedes Eintragstyps zurückgesetzt (aus 0x85 wird 0x05, aus 0xC0 wird 0x40). Lektion 1.5 behandelt beide Strukturen.
• ext4. Die Wiederherstellung über Metadaten ist deutlich schwieriger. Wenn ext4 eine Datei löscht, überschreibt es in der Regel die Extent-Einträge im Inode mit Nullen und setzt dessen Größe auf null. Der Inode verzeichnet somit nicht mehr, wo die Daten lagen. Der Name kann im Verzeichnisblock erhalten bleiben, und ältere Kopien des Inodes können im Journal erhalten bleiben (Lektion 1.6), doch häufig ist Carving die einzige Möglichkeit.

File Carving benötigt keine Dateisystemmetadaten. Der Prüfer durchsucht Rohbytes, üblicherweise nicht zugeordneten Speicherplatz oder ein vollständiges Image, nach der Struktur bekannter Dateitypen: einer Headersignatur, einem Footer oder anderen Markern. Es funktioniert auch bei neu formatierten Volumes, beschädigten Dateisystemen und Speicherabbildern.

Was die jeweilige Methode erhält

Beim Carving gehen Dateisystemmetadaten verloren, nicht jedoch Metadaten innerhalb des Inhalts: Eine mittels Carving wiederhergestellte JPEG-Datei kann EXIF-Tags wie DateTimeOriginal behalten, eine DOCX-Datei ihre docProps/core.xml. Geben Sie diese im Bericht als eingebettete Anwendungsmetadaten an, nicht als Dateisystemzeitstempel.

Was die Wiederherstellung begrenzt

Erneute Verwendung und Überschreiben. Beide Methoden scheitern, wenn Speicherplatz erneut verwendet wird, allerdings auf unterschiedliche Weise. Bei der Metadatenwiederherstellung kann der Datensatz erhalten bleiben, während seine Cluster inzwischen zu einer anderen Datei gehören. Das Werkzeug extrahiert dann den neuen Inhalt unter dem alten Namen. Beim Carving kann ein Header erhalten bleiben, während spätere Cluster überschrieben wurden. Dadurch entsteht eine Datei, die korrekt beginnt und dann in nicht zugehörige Daten übergeht. Sobald ein MFT-Datensatz erneut verwendet wird, sind seine Metadaten verloren, obwohl die Cluster möglicherweise noch mittels Carving wiederhergestellt werden können.

TRIM auf SSDs. Wenn eine Datei auf einer SSD gelöscht wird, die dies unterstützt, sendet das Betriebssystem einen TRIM-Befehl (UNMAP bei SCSI, Deallocate bei NVMe). Je nach Betriebssystem und dessen Einstellungen geschieht dies sofort oder bei einem späteren geplanten Durchlauf. Damit wird dem Laufwerk mitgeteilt, welche logischen Blöcke keine Daten mehr enthalten. Das Laufwerk löscht diese Seiten während der Garbage Collection, und viele SSDs liefern für getrimmte Blöcke sofort Nullen zurück, noch bevor sie physisch gelöscht werden. Ein danach erstelltes Image zeigt in der Regel Nullen, sodass keine der beiden Methoden die Daten wiederherstellen kann. Beim Formatieren einer SSD kann das gesamte Volume getrimmt werden.

USB-Flash-Laufwerke. Die meisten USB-Flash-Laufwerke und viele USB-Bridges unterstützen TRIM über USB-Massenspeicher nicht. Daher bleiben gelöschte Daten auf einem typischen USB-Stick im Allgemeinen erhalten, bis sie überschrieben werden. Dies hängt vom Gerät und der Bridge ab: Einige Gehäuse und UASP-Bridges reichen UNMAP-Befehle durch. Gehen Sie von keiner der beiden Möglichkeiten ungeprüft aus; Nullen an Stellen, an denen gelöschte Daten liegen sollten, sind mit TRIM oder sicherem Löschen vereinbar und sollten entsprechend im Bericht beschrieben werden.

Signaturen, Footer und Struktur

Header/Footer-Carving kopiert von einem Header bis zum nächsten passenden Footer oder bis zu einer maximalen Größe. Es ist schnell, geht aber schematisch vor. Eine JPEG-Datei mit einem EXIF-Vorschaubild enthält ein zweites Paar FF D8 FF … FF D9. Daher kann das erste FF D9 das Ende des Vorschaubilds statt des Fotos markieren. Eine mit inkrementellen Aktualisierungen bearbeitete PDF-Datei enthält mehrere %%EOF-Marker, und der letzte beendet die Datei.

Strukturbasiertes Carving analysiert das Format. Ein JPEG-Carver durchläuft die Markersegmente, die jeweils eine 2-Byte-Längenangabe haben, bis zu den Bilddaten und sucht dann nach FF D9. Ein ZIP-Carver liest den Datensatz zum Ende des zentralen Verzeichnisses, dessen 2-Byte-Kommentarlänge bei Offset 20 das genaue Dateiende angibt, und prüft, ob die Einträge im zentralen Verzeichnis auf gültige lokale Header zurückverweisen. Bei Office-Open-XML-Dateien kennzeichnen [Content_Types].xml und Ordner wie word/ oder xl/ den Dokumenttyp.

Da nicht residente Dateien an einer Clustergrenze beginnen, prüfen Carver häufig nur an Sektor- oder Clusteranfängen auf Header. Dies ist schneller und verringert die Zahl der Fehlertreffer.

Fragmentierung und Validierung

Einfaches Carving setzt eine zusammenhängende Speicherung voraus. Eine fragmentierte Datei wird als ihr erstes Fragment, gefolgt von den unmittelbar anschließenden Daten auf dem Datenträger, wiederhergestellt; eine JPEG-Datei wird typischerweise im oberen Bereich korrekt dekodiert und erscheint weiter unten grau oder verstümmelt. Jede mittels Carving wiederhergestellte Datei muss daher validiert werden: Öffnen oder parsen Sie sie, prüfen Sie die Konsistenz ihrer internen Struktur (zentrales ZIP-Verzeichnis, PDF-Querverweistabelle, CRCs der PNG-Chunks), und vergleichen Sie ihren Hashwert mit bekannten Dateien, sofern verfügbar, etwa mit einer Hashliste relevanter Dateien oder einem als einwandfrei bekannten Referenzbestand zum Ausschluss von Systemdateien. Eine unvollständige Datei stimmt selbst dann nicht mit einem Referenzhash überein, wenn sie erkennbar ist; weisen Sie sie im Bericht als unvollständig aus.

Werkzeuge als Beispiele

• Metadatenwiederherstellung: The Sleuth Kit fls -d -r -p listet gelöschte Einträge mit ihren vollständigen Pfaden auf; icat extrahiert den Inhalt einer Datei anhand der Metadatenadresse; blkstat zeigt an, ob ein Cluster zugeordnet ist; ifind -d ermittelt, welchem Metadateneintrag ein Cluster gehört. Autopsy stellt dieselben Funktionen über eine Oberfläche bereit.
• Carving: PhotoRec (für viele Formate strukturbewusst), Foremost und Scalpel (konfigurierbare Header/Footer-Carver) schreiben jeweils eine Protokoll- oder Berichtsdatei, in der die Fundstelle jeder Datei aufgeführt wird.
• Merkmalsextraktion: bulk_extractor durchsucht Rohbytes nach Merkmalen wie E-Mail-Adressen, URLs und Domainnamen und zeichnet deren jeweiligen Byte-Offset auf.

Wenn Sie Carving auf die Ausgabe von blkls anwenden (nur nicht zugeordnete Cluster), beziehen sich die Offsets auf diesen Datenstrom; ordnen Sie dessen Blockadressen mit blkcalc -u wieder dem Volume zu, bevor Sie sie im Bericht angeben.

Durchgerechnetes Beispiel 1: Wiederherstellung über die MFT

fls -d -r -p -o 2048 disk.E01 listet auf einem Image eines NTFS-Volumes (Volume beginnt bei Sektor 2.048, Clustergröße 4 KiB) eine gelöschte Datei als MFT-Datensatz 41 auf. Das Flags-Feld des Datensatzes enthält 00 00. Sein nicht residentes $DATA-Attribut zeigt eine tatsächliche Größe von 14.862 Bytes, eine zugeordnete Größe von 16.384 Bytes und die Run-Liste 31 04 A0 3F 01 00.

1. Dekodieren Sie den Run. Header 0x31: Das untere Nibble (1) ist die Größe des Längenfelds und das obere Nibble (3) die Größe des Offset-Felds. Länge 0x04 = 4 Cluster. Offset A0 3F 01 in Little-Endian-Reihenfolge = 0x013FA0 = 81.824. Die Daten belegten die Cluster 81.824 bis 81.827; das abschließende 00 beendet die Liste.
2. Berechnen Sie die Offsets. Volume-Offset: 81.824 × 4.096 = 335.151.104. Image-Offset: 335.151.104 + 2.048 × 512 = 335.151.104 + 1.048.576 = 336.199.680. Der Run umfasst 4 × 4.096 = 16.384 Bytes, davon sind 14.862 Dateidaten und 1.522 Slack.
3. Prüfen Sie $Bitmap. Jeder Cluster hat ein Bit, beginnend mit dem niederwertigsten Bit. 81.824 / 8 = 10.228 Rest 0, daher entsprechen die Cluster 81.824 bis 81.827 den Bits 0 bis 3 von Byte 10.228. Wenn alle vier Bits 0 sind, sind die Cluster nicht zugeordnet. Ist eines davon 1, gehört der Cluster inzwischen zu einer anderen Datei: ifind -o 2048 -d 81824 usb.E01 benennt sie, und der Inhalt kann nicht Datensatz 41 zugeschrieben werden. Eine Bitmap mit zurückgesetzten Bits beweist nicht, dass die Cluster nie erneut verwendet und wieder freigegeben wurden. Validieren Sie daher den Inhalt.
4. Extrahieren, hashen und validieren Sie die Datei. icat -o 2048 usb.E01 41 > rec41.bin schreibt genau 14.862 Bytes (verwenden Sie nicht -s, da dies Slack hinzufügt). Berechnen Sie den Hashwert mit SHA-256. Wenn der Name auf .pdf endet, sollten die ersten Bytes bei Image-Offset 336.199.680 25 50 44 46 2D sein, die Datei sollte mit %%EOF enden und sich in einem PDF-Parser öffnen lassen.

Durchgerechnetes Beispiel 2: Carving einer JPEG-Datei

Ein Carver meldet einen JPEG-Header FF D8 FF E1 bei Image-Offset 419.430.400 (Sektor 819.200). Relativ zum Volume ergibt (419.430.400 − 1.048.576) / 4.096 = genau 102.144. Der Header liegt somit am Anfang von Cluster 102.144, wie es bei einem Dateianfang zu erwarten ist. Der strukturbasierte Carver überspringt das EXIF-Segment einschließlich des eingebetteten Vorschaubilds und findet den Bildendmarker FF D9 bei Offset 419.478.226. Die Dateilänge beträgt 419.478.226 + 2 − 419.430.400 = 47.828 Bytes. Die Ausgabedatei erhält einen generierten Namen, der typischerweise aus einer laufenden Nummer oder einer Sektornummer gebildet wird. Validieren Sie sie, indem Sie das gesamte Bild dekodieren, berechnen Sie ihren Hashwert und halten Sie fest, dass ihr ursprünglicher Name, ihr Pfad und ihre Dateisystemzeitstempel unbekannt sind.

Dokumentation der Wiederherstellung

Dokumentieren Sie für jede wiederhergestellte Datei: das Quellimage und dessen verifizierten Hashwert; den Partitionsoffset; die Methode (Metadatenwiederherstellung oder Carving) sowie das Werkzeug und dessen Version; bei der Metadatenwiederherstellung die MFT-Datensatznummer oder den Speicherort des Verzeichniseintrags und die Cluster-Runs; beim Carving den Start-Byte-Offset und die Länge; den SHA-256-Hashwert der wiederhergestellten Datei; die durchgeführte Validierung und ihr Ergebnis; sowie bei mittels Carving wiederhergestellten Dateien eine ausdrückliche Angabe, dass der ursprüngliche Name und die Zeitstempel unbekannt sind. Dies unterstützt die von ISO/IEC 27042 erwartete Wiederholbarkeit.

Ältere Kopien gelöschter Dateien können auch in Volumeschattenkopien und Dateisystem-Snapshots vorhanden sein; Lektion 1.7 behandelt APFS-Snapshots, und Volumeschattenkopien werden später im Kurs behandelt.

Prüfungsschwerpunkt: Rechnen Sie damit, aus einer Clusternummer einen Byte-Offset berechnen, einen kurzen Daten-Run dekodieren und entscheiden zu müssen, ob die Cluster einer gelöschten Datei erneut verwendet wurden. Kennen Sie die Signaturen und Endmarker in der Tabelle sowie die Eigenschaften, die bei der jeweiligen Methode erhalten bleiben. Sie sollten wissen, dass der SHA-256-Hashwert wiederhergestellter Inhalte nur über die logische Größe ohne Slack berechnet werden darf und wie Sie die MFT-Datensatznummer einer gelöschten Datei ermitteln.

Kernpunkte

• Die Metadatenwiederherstellung nutzt erhaltene Dateisystemdatensätze und erhält Name, Pfad, Zeitstempel und genaue Größe; Carving erhält nur den Inhalt und vergibt einen generierten Namen.
• Löschvorgänge unter NTFS und FAT lassen die Angaben zu den Speicherorten in der Regel intakt; ext4 überschreibt die Extents typischerweise mit Nullen, weshalb häufig Carving erforderlich ist.
• Bevor Sie wiederhergestellten Inhalten vertrauen, prüfen Sie die Zuordnungsbitmap und validieren Sie die Datei durch Parsen und Hashberechnung.
• TRIM auf SSDs führt häufig dazu, dass gelöschte Daten als Nullen zurückgelesen werden; USB-Flash-Laufwerke erhalten im Allgemeinen kein TRIM, abhängig von Gerät und Bridge.
• Header/Footer-Carving scheitert an fragmentierten Dateien und verschachtelten Signaturen; strukturbasiertes Carving ist zuverlässiger, erfordert aber dennoch eine Validierung.
• Dokumentieren Sie Offsets, Methode, Werkzeugversion, SHA-256 und bei mittels Carving wiederhergestellten Dateien, dass der ursprüngliche Name und die Zeitstempel unbekannt sind.