Dateien retten nach Typ/Datei-Header-Signatursuche
Datenrettungsfunktion im Extras-Menü und auch eine Strategie zum Auffinden ehemals existierender Dateien als Teil der Befehls "Datei-Überblick erweitern". Erkennt Dateien an bestimmten Header-Signaturen, also an einer für den jeweiligen Dateityp charakteristischen Bytewert-Folge. Wird auch als "File Carving" bezeichnet. Aufgrund dieses Ansatzes ist File Carving nicht vom Vorhandensein von funktionierenden Dateisystemstrukturen abhängig.
Dateien retten nach Typ: Wenn anhand einer Signaturdefinition gefunden, werden die Dateien in einem von Ihnen angegebenen Ausgabeordner auf einem Ihrer eigenen Laufwerke gespeichert. Optional werden Dateien jedes Typs in einem separaten Unterordner abgelegt (...\JPEG, ...\HTML, usw.). Die vermuteten Inhalte der Dateien werden tatsächlich kopiert.
Datei-Header-Signatursuche: Die gefundenen Dateien werden nirgendwo gespeichert, sondern lediglich in einem virtuelle Verzeichnis des Datei-Überblicks aufgelistet. Nur ein Verweis auf jede Datei wird gespeichert (künstlich erzeugter Name, vermutete Größe, Start-Offset, ...). Der Datei-Inhalt wird ad hoc vom ursprünglichen Datenträger/Image gelesen, wenn er zum Einesehen/Kopieren der Datei benötigt wird. Optional können Sie die Dateien mehrerer Durchläufe von Datei-Header-Signatur-Suchen in separaten Unterverzeichnissen ausgeben, so daß sie leichter voneinander unterschieden werden können, wenn hilfreich.
Beachten Sie, daß das Ausgliedern von Dateien aus Sektoren anhand von Datei-Header-Signaturen (File Carving) generell annimmt, daß die folgenden zugehörigen Cluster physisch zusammenhängend sind, also im Fall von ursprünglich fragmentiert gespeicherten Clusterketten inkonsistente Dateien ausgibt. Folgende Ausnahme ist definiert: Wenn die Datei-Header-Signatur-Suche in einem unterstützten Dateisystem (außer Ext2/Ext3) den Anfang einer Datei im freien Speicher findet, an einer Cluster-Grenze, wird standardmäßig angenommen, daß die Daten um etwaige folgende im Dateisystem als belegt markierte Cluster herum gespeichert sind. Das rekonstruiert Dateien korrekt, die zeitlich nach anderen Dateien gespeichert wurden und um diese herum, und die dann gelöscht wurden, solange die dabei freigegebenen Cluster nicht anschließend nochmal wieder neu verwendet überschrieben wurden. Um das Ausgliedern von Daten in diesem Sinne rein aus dem freiem Speicher (unter Meidung von allozierten Clustern) zu verhindern, d. h. immer zusammenhängende Cluster anzunehmen, können Sie die Option "Dateien in freien Clustern allokationsavers ausgliedern" abwählen.
Die Option "Ext2/Ext3-Block-Logik anwenden" veranlaßt diese Wiederherstellungsmethode ebenfalls, von der Standardannahme nicht-fragmentierter Speicherung abzuweichen: Statt dessen folgt sie dem typischen Ext-Block-Muster, in dem beispielsweise der 13. Block ab dem Header der Datei als indirekter Block betrachtet wird, der selbst auf die folgenden Datenblöcke verweist. Diese Option zeigt keine Wirkung, wenn sie auf Partitionen angewendet wird, von denen WinHex weiß, daß sie ein anderes Dateisystem als Ext2 oder Ext3 haben oder wenn ein Header gefunden wird, der nicht an einer Block-Grenze ausgerichtet ist.
Eine Log-Datei namens "File Recovery by Type.log", die über die gewählten Parameter und die Datenrettungsergebnisse Auskunft gibt, wird zu Prüfzwecken ebenfalls in den Ausgabeordner geschrieben.
Sie können den gesamten Dateityp-Baum in diesem Dialogfenster per Schalter aufklappen oder einklappen. Das ist nützlich, weil Sie bei aufgeklapptem Baum komfortablerweise durch Eintippen der ersten paar Buchstaben einer Dateityp-Beschreibung automatisch zum ersten dazu passenden Eintrag im Baum springen können.
Da auf ein ggf. vorhandenes Dateisystem (funktional oder nicht) nicht zurückgegriffen wird, sind dieser Methode die Original-Dateigrößen nicht bekannt, und die Original-Dateinamen auch nicht. Das ist der Grund, warum die resultierenden Dateien zumeist nach folgendem Muster benannt werden: Prefix#####.ext. "Prefix" ist ein von Ihnen angegebenes optionales Präfix. "#####" ist eine laufende Nummer pro Asservat. "ext" ist die Dateinamenserweiterung, die laut Dateityp-Definition zu diesem Dateitype gehört. Das Präfix für den Ausgabedateinamen darf optional einen Platzhalter "%d" enthalten, der durch den Datenträgernamen ersetzt wird. Dies ist nützlich, wenn Sie "Dateien retten nach Typ" auf mehrere Datenträger auf einmal anwenden und später leicht erkennen können möchten, welche Datei von welchem Datenträger stammt.
Mit Specialist-Lizenzen oder höher gilt bei aktiver Option "aussagekräftige Benennung": Exif-JPEG-Dateien werden optional automatisch nach dem Digitalkamera-Modell benannt, das sie erzeugt hat, sowie nach ihrem internen Zeitstempel, sofern verfügbar. Viele Windows-Registry-Hive-Dateien erhalten ihren ursprünglichen Namen, ebenso einige JPEG-Dateien, für die Photoshop einen Namen in den internen Metadaten hinterlegt hat. Bei JPEG-Dateien ohne bekannten Namen und ohne Exif-Metadaten, die jedoch von einer bekannten Code-Bibliothek erzeugt wurden, wird in Klammern eine Zusatzinformation an den Namen angehängt (s. Generator-Signatur). Thumbs.db-Dateien werden immer thumbs.db genannt, index.dat immer index.dat. Das o. g. Präfix wird nicht zusammen mit Originaldateinamen verwendet.
Es kommen intern diverse Algorithmen zur Anwendung, die versuchen, Dateien vieler verschiedener Typen (u. a. JPEG, GIF, PNG, BMP, TIFF, Nikon NEF, Canon CR2 raw, PSD, CDR, AVI, WAV, MOV, MPEG, MP3, MP4, 3GP, M4V, M4A, ASF, WMV, WMA, ZIP, GZIP, RAR, 7Z, TAR, MS Word, MS Excel, MS PowerPoint, RTF, PDF, HTML, XML, XSD, DTD, PST, DBX, AOL PFC, Windows Registry, Prefetch, index.dat, SPL, EVTX, EML) in ihrer ursprünglichen, korrekten Größe wiederherzustellen, indem es deren Datenstrukturen untersucht. Das betrifft die Einträge in der Dateityp-Definitionsdatei, mit einem "~" in der Footer-Spalte. Die Einträge sollten nicht verändert werden, sonst funktioniert die Größen- und Typerkennung für diese Dateitypen u. U. nicht. Alternativ kann auch eine Footer-Signatur helfen, das Ende einer Datei zu finden. Dateien, für die kein interner Algorithmus existiert oder für die ein verfügbarer interner Algorithmus die ursprüngliche Größe nicht ermittelt und für die auch kein Footer gefunden wird, werden mit der in der Dateityp-Definitionsdatei angegebenen Normalgröße wiederhergestellt. Seien Sie eher großzügig beim Angeben einer solchen Normalgröße, da zu groß wiederhergestellte Dateien durchaus noch von ihren zugehörigen Anwendungsprogrammen geöffnet werden können, frühzeitig abgeschnittene unvollständige Dateien aber nicht. Der Versuch, die Originalgröße von Dateien bestimmter Typen herauszufinden durch Suche nach einem etwaigen definierten Footer wird begrenzt durch ein Größenerkennungslimit, das optional ebenfalls in der Definitionsdatei hinterlegt werden kann, hinter der Normalgröße und einem Schrägstrich. Ein solches Limit ist erforderlich, um zu verhindern, daß der Footer einer Datei in der gesamten Partition gesucht wird, was bei einer sehr großen Partition ziemlich zeitraubend wäre. Außerdem wird es immer unwahrscheinlicher, den richtigen Footer zu finden, je weiter entfernt vom Header man sucht, und selbst wenn er sehr weit entfernt gefunden wird, ist eine solche Datei wahrscheinlich fragmentiert oder teilweise überschrieben o. ä. Die Normalgröße wird, wenn nicht angegeben, als 1 MB angenommen. Die Maximalgröße, wenn nicht angegeben, beträgt das 64-fache der Normalgröße.
Datei-Header sind i. d. R. am Anfang eines Clusters zu finden, denn dort platzieren Dateisysteme i. d. R. Dateianfänge. Es ist allerdings gründlicher (und nicht langsamer), nach Dateiheadern auch an Sektor-Grenzen suchen zu lassen, um auch Dateien von einer früheren Partition mit einem anderen Cluster-Layout finden zu können, so daß dies das Standardverhalten ist. Wenn der Algorithmus auf einen physischen Datenträger oder eine einfache Datei angewandt wird, wo keine Cluster definiert sind, muß WinHex ohnehin an Sektorgrenzen suchen. Es gibt noch eine weitere Möglichkeit, die vollständige Suche auf Byte-Ebene. Diese ist erforderlich, wenn Sie versuchen, Dateien zu finden, die nicht verläßlich an irgendwelchen Sektorgrenzen ausgerichtet sind (z. B. Dateien in Backup-Dateien oder in Tape-Images oder sonstige in andere Dateien eingebettete Dateien) sowie für Datensätze/Einträge/Micro-Formate/Hauptspeicher-Artefakte usw. usf., d. h. nicht vollständige konventionelle Dateien. Damit kann allerdings eine erhöhte Zahl von fälschlicherweise erkannten Datei-Headern einhergehen, also Bytewertfolgen, die zufällig auf einem Datenträger vorkommen, aber dort nicht den Anfang einer Datei anzeigen. Individuelle Flags in der Dateityp-Definitionsdatei können je nach Dateityp für eine passende Behandlung sorgen, also Suche an Cluster-, Sektor- oder Byte-Grenzen.
That the start sectors of files that are already known to the volume snapshot are always excluded from file carving is optional. Of course, X-Ways Forensics generally still tries to prevent duplicates, but if the file header signature definition or the internal file size detection is strong enough to suggest that a known deleted file was overwritten with a new file, then that new file will be carved although it shares the same start sector with the known file.
If you intentionally abort the file header signature search or if the file header signature search causes X-Ways Forensics to crash, next time when you start a file header signature search in the same evidence object, you will find an option to resume it right where it was interrupted, or where it was when the volume snapshot was last saved before the crash occurred (depends on the auto-save interval of the case).
Sie können den Erfassungsbereich der Datenrettung wenn gewünscht auf einen ggf. ausgewählten Block einschränken und/oder auf belegten oder unbelegten Speicher (bei einem logischen Laufwerk oder einer Partition verfügbar). Um nur Dateien zu retten, die gelöscht worden sind, wählen Sie unbelegten Speicher. Dateien, die z. B. nur aufgrund von Dateisystemfehlern nicht mehr zugreifbar sind, können dagegen durchaus noch in als belegt gekennzeichneten Clustern gespeichert sein.
Die Auswirkungen von NTFS-Kompression auf Dateiinhalte können bei der Datei-Header-Signatursuche optional besonders berücksichtigt werden (nur mit forensischer Lizenz), in vielen Fällen erfolgreich. Wenn die Signatur einer NTFS-komprimierten Datei gefunden wird, wird die Datei als komprimiert gekennzeichnet, und es wird versucht, die Datei bei Bedarf automatisch zu dekomprimieren, mit einem ausgeklügelten Algorithmus, der sogar aus mehreren Kompressionseinheiten bestehende Dateien dekomprimieren kann.
Bei der Suche nach MPEG-Dateisignaturen an Sektorgrenzen stellt der interne Algorithmus sicher, daß keine überlappende MPEG-Fragmente und keine MPEG-Fragmente inmitten bekannter MPEG-Dateien ausgegeben werden. Die ist nützlich, weil die MPEG-Signatur nicht nur am Anfang von MPEG-Dateien steht, sondern wiederholt in ihrem gesamten Inhalt.