jschicht/logfileparserParser für $LogFile auf NTFS
Features Dekodieren und Ausgeben von $LogFile-Datensätzen und Transaktionseinträgen. Dekodieren von NTFS-Attributänderungen. Optional Auflösen aller in $LogFile verfügbaren Datarun-Listeninformationen. Option: "Reconstruct data runs". Wiederherstellen von Transaktionen aus Slack-Space innerhalb von $LogFile. Wahlweise Rekonstruieren fehlender oder beschädigter Header von im Slack gefundenen Transaktionen. Option: "Rebuild header". Optional Verfeinern des Ergebnisses mit einem LSN-Fehlerstufenwert. Option: "LSN error level". Protokollierung in CSV und Import in eine SQLite-Datenbank mit mehreren Tabellen. Optionaler Import der CSV-Ausgabe von mft2csv in die Datenbank. Auswahl unter 6 verschiedenen Zeitstempelformaten. Auswahl der Zeitstempelgenauigkeit: None, MilliSec und NanoSec. Auswahl des Genauigkeitstrennzeichens bei Millisekunden. Auswahl des Genauigkeitstrennzeichens bei Nanosekunden. Auswahl der Regionsanpassung für Zeitstempel. Standard ist die Darstellung der Zeitstempel in UTC 0.0. Auswahl des Ausgabetrennzeichens. Option: "Set separator". Konfigurierbare UNICODE- oder ANSI-Ausgabe. Option "Unicode". Konfigurierbare MFT-Datensatzgröße (1024 oder 4096). Option "MFT record size". Optional Dekodieren einzelner Transaktionen oder Teiltransaktionen (Fragment). Option zum Rekonstruieren von RCRDs aus einzelnen oder mehreren Transaktionen (Fragmenten). Option zum Konfigurieren einer beschädigten $LogFile. Nützlich mit gecarvten RCRDs als Eingabe. Option zum Überspringen von Fixups (für beschädigte $LogFile, typischerweise aus dem Speicher gecarvt). Detaillierte ausführliche Ausgabe in debug.log. Konfigurierbare kommagetrennte Liste von LSNs, um ultra-ausführliche Informationen über bestimmte Transaktionen in debug.log auszulösen. Konfiguration für 32-Bit-Betriebssystem. Konfiguration für die Extraktion binärer Daten von residenten Datenaktualisierungen. Autogeneriertes SQL zum Import der Ausgabe in eine MySql-Datenbank. Option zum Überspringen aller SQLite3-Aktivitäten, um das gesamte Parsing zu beschleunigen. Optionaler Kommandozeilenmodus. Unterstützt Errorlevel, geeignet für Batch-Skripting.
Background NTFS ist als wiederherstellbares Dateisystem konzipiert. Dies wird durch die Protokollierung aller Transaktionen erreicht, die die Volume-Struktur verändern. Jede Änderung an einer Datei auf dem Volume erfordert also auch eine Protokollierung in der $LogFile, damit sie bei einem Systemausfall jederzeit rückgängig gemacht werden kann. Daher wird eine Vielzahl von Informationen in diese Datei geschrieben, und da sie zirkulär ist, überschreiben neue Transaktionen ältere Datensätze in der Datei. Somit ist begrenzt, wie viele historische Daten aus dieser Datei abgerufen werden können. Auch dies hängt vom Volume-Typ und der Größe der $LogFile ab. Auf dem Systemlaufwerk eines häufig genutzten Systems erhalten Sie wahrscheinlich nur wenige Stunden Historie, während eine externe/sekundäre Festplatte mit Backup-Dateien wahrscheinlich mehr historische Informationen enthält. Und eine 2-MB-Datei enthält weit weniger Historie als eine mit 256 MB. In welchem Größenbereich kann diese Datei also konfiguriert werden? Alles ab 256 KB und darüber. Die Größe auf 2 GB kann wie folgt konfiguriert werden: "chkdsk D: /L:2097152". Wie sich eine große Logfile-Größe auf die Leistung auswirkt, liegt außerhalb des Rahmens dieses Textes. Eine Einstellung unter 2048 ist normalerweise nicht möglich. Es ist jedoch möglich durch Patchen von untfs.dll: http://code.google.com/p/mft2csv/wiki/Tiny_NTFS
Intro Dieser Parser dekodiert und gibt viele Transaktionsinformationen aus der $LogFile auf NTFS aus. Es werden mehrere CSVs generiert sowie eine SQLite-Datenbank namens ntfs.db, die alle relevanten Informationen enthält. Die Ausgabe ist extrem detailliert und sehr niedrigschwellig, was bedeutet, dass einiges an NTFS-Wissen erforderlich ist, um sie zu verstehen. Die derzeit behandelten Redo-Transaktionstypen mit aussagekräftiger Ausgabedekodierung sind:
InitializeFileRecordSegment CreateAttribute DeleteAttribute UpdateResidentValue UpdateNonResidentValue UpdateMappingPairs SetNewAttributeSizes AddindexEntryRoot DeleteindexEntryRoot AddIndexEntryAllocation DeleteIndexEntryAllocation WriteEndOfIndexBuffer SetIndexEntryVcnRoot SetIndexEntryVcnAllocation UpdateFileNameRoot UpdateFileNameAllocation SetBitsInNonresidentBitMap ClearBitsInNonresidentBitMap OpenNonresidentAttribute OpenAttributeTableDump AttributeNamesDump DirtyPageTableDump TransactionTableDump UpdateRecordDataRoot UpdateRecordDataAllocation CompensationlogRecord
Die Liste der derzeit unterstützten Attribute: $STANDARD_INFORMATION $ATTRIBUTE_LIST $FILE_NAME $OBJECT_ID $SECURITY_DESCRIPTOR $VOLUME_NAME $VOLUME_INFORMATION $DATA $INDEX_ROOT $INDEX_ALLOCATION $REPARSE_POINT $EA_INFORMATION $EA $LOGGED_UTILITY_STREAM
Im Grunde werden also alle Attribute unterstützt.
Erklärung der verschiedenen generierten Ausgaben:
LogFile.csv: Die vom Parser generierte Haupt-CSV.
LogFile_DataRuns.csv Die Eingabeinformationen, die zur Rekonstruktion von Dataruns benötigt werden
LogFile_DataRunsResolved.csv Die endgültige Ausgabe der rekonstruierten Dataruns
LogFile_INDX_I30.csv Alle ausgegebenen und dekodierten Index-Datensätze (IndexRoot/IndexAllocation)
LogFileJoined.csv Wie LogFile.csv, jedoch mit Dateinameninformationen, die aus dem $UsnJrnl oder der CSV von mft2csv eingefügt wurden.
MFTRecords.bin Dummy-$MFT, die basierend auf gefundenen MFT-Datensätzen in InitializeFileRecordSegment-Transaktionen neu erstellt wurde. Kann mft2csv auf dieser anwenden (denken Sie daran, "broken MFT" und "Fixups" korrekt zu konfigurieren).
LogFile_lfUsnJrnl.csv Datensätze für das $UsnJrnl, die innerhalb der $LogFile dekodiert wurden
LogFile_UndoWipe_INDX_I30.csv Alle Undo-Operationen zum Löschen von Verzeichnisindizes (INDX).
LogFile_AllTransactionHeaders.csv Alle Header der dekodierten Transaktionen.
LogFile_BitsInNonresidentBitMap.csv Alle dekodierten SetBitsInNonresidentBitMap-Operationen.
LogFile_DirtyPageTable32bit.csv und LogFile_DirtyPageTable64bit.csv Alle Einträge in jeder dekodierten DirtyPageTableDump-Operation für sowohl 32-Bit- als auch 64-Bit-Betriebssysteme.
LogFile_Mft_ObjectId_Entries.csv Dekodierte $ObjectId-Attribute.
LogFile_ObjIdO.csv Alle Dekodierungen aus der Systemdatei $ObjId:$O.
LogFile_OpenAttributeTable.csv Alle Einträge in jeder dekodierten OpenAttributeTableDump-Operation.
LogFile_QuotaO.csv Alle Dekodierungen aus der Systemdatei $Quota:$O.
LogFile_QuotaQ.csv Alle Dekodierungen aus der Systemdatei $Quota:$Q.
LogFile_RCRD.csv Alle Header der dekodierten RCRD-Datensätze.
LogFile_ReparseR.csv Alle Dekodierungen aus der Systemdatei $Reparse:$R.
LogFile_SecureSDH.csv Alle Dekodierungen aus der Systemdatei $Secure:$SDH.
LogFile_SecureSII.csv Alle Dekodierungen aus der Systemdatei $Secure:$SII.
LogFile_SecurityDescriptors.csv Dekodierte Sicherheitsdeskriptoren. Quelle kann $SECURITY_DESCRIPTOR oder $Secure:$SDS sein.
LogFile_SlackAttributeNamesDump.csv Alle Einträge aus dekodierten AttributeNamesDump-Transaktionen, die im Slack-Space gefunden wurden.
LogFile_SlackOpenAttributeTable.csv Alle Einträge aus dekodierten OpenAttributeTableDump-Transaktionen, die im Slack-Space gefunden wurden.
LogFile_TransactionTable.csv Dekodierte TransactionTableDump-Transaktionen.
LogFile_Filenames.csv Alle aufgelösten Dateinamen mit MftRef, MftRefSeqNo und Lsn.
LogFile_TxfData.csv Dekodierte Daten aus $DATA:$TXF_DATA in $LOGGED_UTILITY_STREAM.
LogFile_UpdateFileName_I30.csv Alle Dekodierungen von UpdateFileNameRoot und UpdateFileNameAllocation für sowohl Redo- als auch Undo-Operationen.
LogFile_CompensationlogRecord.csv Alle Dekodierungen von CompensationlogRecord. Nicht relevant für nt5.x.
Ntfs.db Eine SQLite-Datenbankdatei mit Tabellen, die nahezu den obigen CSVs entsprechen. Die Datenbank enthält 5 Tabellen: DataRuns IndexEntries LogFile LogFileTmp (temporäre Tabelle, die beim Neuerstellen von Dataruns verwendet wird). UsnJrnl
Timestamps Standardmäßig werden sie in UTC 0.00 und mit Nanosekunden-Genauigkeit dargestellt. Das Standardformat ist YYYY-MM-DD HH:MM:SS:MSMSMS:NSNSNSNS. Diese können konfiguriert werden. Die verschiedenen Zeitstempel beziehen sich auf: CTime bedeutet File Create Time. ATime bedeutet File Modified Time. MTime bedeutet MFT Entry modified Time. RTime bedeutet File Last Access Time.
Rekonstruktion von Dataruns.
Viele Operationen auf dem Dateisystem lösen eine Transaktion in die $LogFile aus. Diejenigen, die sich auf das $DATA-Attribut beziehen, also den Inhalt einer Datei, sind bisher identifiziert als;
InitializeFileRecordSegment CreateAttribute UpdateMappingPairs SetNewAttributeSizes
Sie alle hinterlassen unterschiedliche Informationen in der $LogFile. Modifikationen an residenten Daten verhalten sich anders und können nicht einfach so rekonstruiert werden, zumindest auf NTFS-Volumes, die von modernen Windows-Versionen stammen.
InitializeFileRecordSegment tritt auf, wenn eine neue Datei erstellt wird. Somit hat sie das $FILE_NAME-Attribut sowie den ursprünglichen Inhalt des $DATA-Attributs, einschließlich Dataruns. Da die $LogFile zirkulär ist und ältere Ereignisse durch neuere überschrieben werden, besteht die Herausforderung bei der $LogFile darin, Informationen weit genug in der Zeit zurück zu erhalten. Wenn jedoch InitializeFileRecordSegment vorhanden ist, sollten wir in der Lage sein, alles zu rekonstruieren, da alle danach geschriebenen Datensätze ebenfalls verfügbar sind. Wir haben auch Informationen über den Offset zur Datarun-Liste. Dies ist ein relativer Offset, der vom Anfang des $DATA-Attributs berechnet wird. Dies ist eine wichtige Information, um zu berechnen, wo in der Datarun-Liste UpdateMappingPairs seine Modifikation vorgenommen hat.
CreateAttribute ist das ursprüngliche Attribut, als es zum ersten Mal erstellt wurde (falls nicht als Teil von InitializeFileRecordSegment geschrieben). Auch hiermit sollten wir in der Lage sein, Dataruns zu rekonstruieren, da uns alle Transaktionen zur Verfügung stehen. Diese liefert jedoch nicht von sich aus den Dateinamen. Auch hier haben wir den Offset zur Datarun-Liste verfügbar, was äußerst nützlich ist, um UpdateMappingPairs aufzulösen.
UpdateMappingPairs ist eine Transaktion, wenn Modifikationen an den $DATA/Dataruns durchgeführt werden (Dateiinhalt hat sich geändert). Die in dieser Transaktion gefundenen Informationen sind nicht vollständig und enthalten nur die neuen Werte, die zur bestehenden Datarun-Liste hinzugefügt wurden. Sie enthält auch einen relativen Offset, der uns sagt, wo in der Datarun-Liste die Änderungen geschrieben wurden. Dieser Offset wird in Kombination mit dem Offset zu Datarun verwendet, wie er in InitializeFileRecordSegment und CreateAttribute gefunden wird.
SetNewAttributeSizes ist eine Transaktion, die Informationen über alle größenbezogenen Modifikationen am $DATA-Attribut enthält. Dies ist eng mit UpdateMappingPairs verbunden, das nur Datarun-Änderungen enthält.
Mit den oben genannten 4 verschiedenen Redo-Operationen kann für eine gegebene Referenznummer (eindeutige Datei) ein Teil der Dateisystemänderungshistorie der Datei rekonstruiert werden. Aufgrund der Zirkularität haben wir nur einen Teil der Historie, den jüngsten. Das Ausmaß der Historie, die wir abrufen können, hängt stark davon ab, um welche Art von Volume es sich beim Ziel handelt. Wenn es sich um ein Systemvolume handelt, ist eine Woche Historie wahrscheinlich mehr, als Sie erwarten können, während ein Wechseldatenträger oder eine externe oder sekundäre Festplatte weit mehr Historie enthält. Somit können wir möglicherweise die vollständige Historie einer gelöschten Datei rekonstruieren (deren $MFT-Datensatz überschrieben wurde) und wiederum die Datarun-Liste neu erstellen, um eine Wiederherstellung durchzuführen. In anderen Fällen können wir möglicherweise nicht die vollständige Historie rekonstruieren, sodass nur eine partielle Datarun-Liste rekonstruiert werden kann. Die endgültige CSV-Datei mit den angepassten Dataruns, LogFile_DatarunsModified.csv, wird die Dataruns anders dargestellt haben.
Erklärung: Diejenigen, die mit einem "!" beginnen, zeigen an, dass die vollständige Datarun-Liste neu erstellt wurde. Diejenigen, die mit einem "?" beginnen, zeigen eine partielle Wiederherstellung an, wobei die Anzahl der "**" die fehlenden Bytes der ursprünglichen Datarun-Liste darstellt.
Um die Wiederherstellung einer Datei basierend auf einem Datarun zu vereinfachen, kann man das beigefügte PoC namens ExtractFromDataRuns verwenden. Es ist ziemlich selbsterklärend. Füllen Sie einfach die vollständige Datarun-Liste, die reale Größe und die Init-Größe sowie einen Namen für die Ausgabedatei ein. Wählen Sie optional die Verarbeitung von Image-Dateien (Festplatte oder Partition). Aktivieren Sie auch das Kontrollkästchen, wenn ein komprimiertes/Sparse-Flag erkannt wurde. Die Eingabe einer teilweise rekonstruierten Datarun-Liste wird nicht funktionieren! Bitte beachten Sie, dass alternative Datenströme durch das Vorhandensein eines Datanamens und auch durch abweichende OffsetInMft-Werte für eine gegebene Fileref unterschieden werden können.
Das separate Download-Paket "SampleTinyNtfsVolume.zip" enthält ein Partition-Image mit einem kleinen NTFS-Volume zum Testen. Auf dem Volume befinden sich 2 gelöschte nicht-residente Dateien, deren MFT-Datensatz beide durch neue Dateien überschrieben wurde. Jede anständige Wiederherstellungssoftware, die auf Signatursuche basiert, sollte in der Lage sein, die JPG-Datei (Tulips.jpg) wiederherzustellen, da sie zusammenhängend ist. Sie werden jedoch höchstwahrscheinlich nicht ihren Dateinamen oder irgendetwas anderes über die Datei identifizieren. Die zweite Datei wird wahrscheinlich mit Standardwerkzeugen nicht wiederherstellbar sein, da sie fragmentiert (komprimiert) ist und durch das Überschreiben ihres MFT-Datensatzes die Auflösung der Datei ohne die Datarun-Liste unmöglich ist. Mit dem PoC können wir den Dateinamen (suspicious.zip) identifizieren und ihn in perfekter Form extrahieren (keine Sorge, er enthält nur eines der mit Windows gelieferten Beispielbilder). Lesen Sie die Datei readme.DataRunsResolved.txt für Details zum Beispiel-Image und zur Interpretation der Ausgabe und Wiederherstellung der Dateien.
Was wir damit erreicht haben, ist die Wiederherstellung fragmentierter Dateien, deren MFT-Datensatz überschrieben wurde. Da wir eine partielle/vollständige Datarun-Historie rekonstruiert haben, können wir mit Sicherheit (zumindest wenn die vollständige Historie rekonstruiert wurde) feststellen, ob Dateislack-Daten zur gegebenen Datei gehört haben oder nicht.
Limitation. Die Datarun-Rekonstruktion ist mit UNICODE fehlerhaft (ANSI ist in Ordnung). Der Import der Mft2Csv-Ausgabe ist fehlerhaft, wenn die CSV UNICODE ist (ANSI ist in Ordnung). Partielle Aktualisierungen von IndexRecords (IndexRoot/IndexAllocation) sind sehr schwer zu interpretieren, da wir wahrscheinlich keine Kenntnis des ursprünglichen Index haben. Vollständige Datensätze sind jedoch in Ordnung. Die Zirkularität einer 65-MB-Datei stellt eine inhärente und absolute Einschränkung dar, wie viele historische FS-Transaktionen möglich sind. Systemlaufwerke haben daher eine begrenzte Historie in $LogFile, während externe/sekundäre Laufwerke mehr historische Transaktionen gespeichert haben. Die Größe von $LogFile kann mit chkdsk erhöht werden (chkdsk c: /L:262144). Änderungen an den Daten residenter Dateien werden nicht in $LogFile gespeichert, nur die Information, dass eine Änderung durchgeführt wurde, wird gespeichert.
Note Das $UsnJrnl enthält Informationen in einer menschenfreundlicheren Form. Zum Beispiel enthält jeder Datensatz Fileref, Dateiname, Zeitstempel und eine Erklärung, was passiert ist. Es enthält auch weit mehr historische Informationen als $LogFile, allerdings ohne viele Details. Wenn $UsnJrnl aktiv ist, dann sind alle Transaktionen, die während der Recycle-Lebensdauer der $LogFile in es geschrieben wurden, auch innerhalb der $LogFile vorhanden. Das bedeutet, dass es keinen Grund gibt, das $UsnJrnl zu dekodieren, um die $LogFile besser zu verstehen.
Slack space In diesem Kontext bedeutet Slack-Space der Raum innerhalb eines RCRD-Datensatzes, der der Rest im Datensatz über die letzte Transaktion hinaus ist. Ich glaube nicht, dass dies zuvor beschrieben wurde, also lassen Sie es mich erklären. Volume-Slack ist der ungenutzte Raum zwischen dem Ende des Dateisystems und dem Ende der Partition, auf der sich das Dateisystem befindet. MFT-Datensatz-Slack ist irgendwie dasselbe, bezieht sich aber auf den Raum, der nach der Datensatz-Endsignatur (0xFFFFFFFF) bis zum physischen Datensatzende (0x400 oder 0x1000) gefunden wird. Und Slack-Space innerhalb der $LogFile ist somit der Raum, der über die letzte Transaktion hinaus bis zum RCRD-Datensatzende (normalerweise 0x1000) gefunden wird. Diese Transaktionen aus dem Slack sind tatsächlich von vor der Wiederverwendung (Überschreibung) der $LogFile vorhanden. Es gibt auch einen Algorithmus, der gültige Transaktionen aus dem Slack-Space identifiziert. Darüber hinaus können auch mehrere Schichten solcher Slack-Spaces existieren. Beispiel: Nehmen wir an, die letzte Transaktion in einem gegebenen RCRD-Datensatz endete bei Offset 0x00007D27. Von diesem Offset bis 0x00007FFF haben wir 0x2D8 Bytes Slack-Space. Es könnte dann sein, dass die Bytes ab 0x00007D28 kein gültiger Transaktionsheader sind, weil sie sich in der Mitte einer Transaktion befinden. Das Programm wird dann (wenn entsprechend konfiguriert) versuchen, einen Pseudo-Header mit gültigen Werten neu zu erstellen, um die Transaktion zu dekodieren. Wenn es scheitert, einen gültigen Header neu zu erstellen, geht es davon aus, dass zu viele Informationen des ursprünglichen Headers verloren sind, und es wird diese Bytes als verloren betrachten und den Rest des Slack-Space nach einem gültigen Transaktionsheader weiter durchsuchen. Die verlorenen Bytes werden in debug.log protokolliert, damit Sie sie untersuchen können. Wenn es andererseits einen gültigen Header neu erstellen konnte, würden die Informationen darüber im Feld lf_TextInformation gefunden werden. Nehmen wir an, es identifizierte eine Transaktion, die bei Offset 0x00007D48 beginnt und die Größe 0xB0 hat. Dann wurde eine weitere gute Transaktion unmittelbar danach bei Offset 0x00007DF8 mit Größe 0xE0 identifiziert. Bei Offset 0x00007ED8 gab es jedoch keinen gültigen Transaktionsheader. Das bedeutet, wir befinden uns jetzt auf der zweiten Schicht des Slack-Space innerhalb dieses RCRD-Datensatzes. Nehmen wir nun an, das Programm konnte nach erneutem Scannen einen gültigen Transaktionsheader bei Offset 0x00007F18 identifizieren. Diese Transaktion würde in der CSV mit einem Wert von 2 im Feld FromRcrdSlack markiert werden. Bedenken Sie jedoch, dass die Gesamtgröße der Transaktion den Offset über die RCRD-Datensatzgröße hinaus verschiebt. Im Wesentlichen wäre dies eine teilweise wiederhergestellte Transaktion, die möglicherweise gut dekodiert werden kann, aber mit einem Wert von 1 im Feld IncompleteTransaction gefunden wird. Denken Sie daran, dass die debug.log sehr detailliert ist und helfen wird, die dekodierte Ausgabe zu verstehen, insbesondere was aus dem Slack-Space stammt.
32-Bit- vs. 64-Bit-Konfiguration. Diese Einstellung ist wichtig, um sie korrekt zu setzen. Sie bedeutet, welches Betriebssystem das Zielvolume behandelt hat. Der Punkt ist, dass die Behandlung von OpenAttributeTable sich zwischen 32-Bit- und 64-Bit-Betriebssystemen unterscheidet. Es kann natürlich Fälle geben (zum Beispiel USB-Festplatte), in denen das Volume von mehreren verschiedenen Betriebssystemen behandelt wurde, in welchem Fall es schwierig sein kann, diese Einstellung zu 100 % korrekt zu setzen. Ab Version 2.0.0.8 wurde ein Autodetektionsmechanismus implementiert. Es wird jedoch weiterhin empfohlen, zu versuchen, diese Konfiguration korrekt zu setzen. Im Feld TextEinformation wird eine "Mixed OS detected"-Meldung ausgegeben, wenn ein OpenAttributeTableDump-Format erkannt wird, das von der Konfiguration abweicht, oder wenn beide Typen erkannt werden. In jedem Fall kann es nützlich sein, die LogFile_OpenAttributeTable.csv zu untersuchen, um die Ausgabe zu bewerten. Wenn Sie Einträge mit Spalten sehen, die seltsame Werte enthalten, dann ist diese spezielle Einstellung möglicherweise falsch. Wenn ja, dann sind die meisten Werte weit daneben. Zum Beispiel sind die meisten AttributeType-Felder UNKNOWN, Lsn liegt nicht im aktuellen Bereich, MftRef ist zu hoch und MftRefSeqNo ist 0. Beachten Sie, dass AttributeType als UNKNOWN für nicht initialisierte Einträge in der Tabelle aufgelöst wird, aber diese sind leicht zu erkennen, da alle Werte nach AllocatedOrNextFree 0 sind und vollkommen gültig sind. Diese Herausforderungen scheinen mit der in Version 2.0.0.8 implementierten Autodetektion behoben zu sein.Extraktion von Aktualisierungen residenter Attribute (UpdateResidentValue). Die Operation UpdateResidentValue dient Aktualisierungen des Inhalts residenter Attribute. Die Konfiguration von "Extract resident updates of min size" ermöglicht es Ihnen, die binäre Modifikation des residenten Attributs zu extrahieren. Das Eingabefeld ist für die Mindestgröße in Bytes, die extrahiert werden soll. Die wahrscheinlich interessanteste Verwendung dieser Funktion ist bei Volumes, die von Nt5.x (XP, 2003) verwaltet werden, wo die vollständigen Aktualisierungen des $DATA-Attributs (normaler Dateiinhalt) in den Redo- und Undo-Feldern mit UpdateResidentValue gespeichert werden. Dateien mit einem residenten $DATA-Inhalt sind Dateien kleinerer Größe, höchstens 744 Bytes (bei einer MFT-Datensatzgröße von 1024), aber üblicherweise weniger. Die extrahierten Daten werden in einen Unterordner namens ResidentExtract geschrieben. Die Ausgabedateien werden nach einer Logik wie dieser benannt: MFT($MFTRef)$OffsetInMft$AttributeOffset_LSN($Lsn)$Operation.bin. Zum Beispiel würde MFT(1643)_0x0098_0x00B8_LSN(1415242628)redo.bin bedeuten: MFT-Datensatznummer 1643, der Offset des Zielattributs in der MFT ist 0x98, der Offset der Modifikation innerhalb des Zielattributs ist 0xB8, die LSN der Transaktion ist 1415242628, und dies war für eine Redo-Operation. Die Extraktionen für Undo-Operationen enthalten somit die Daten an diesem Offset vor der Modifikation. Die Aktivierung dieser Funktion wird einige irrelevante und nicht interessante Ausgaben erzeugen. Die meisten False Positives werden automatisch gefiltert, aber einige sind unvermeidbar. Zum Beispiel können Aktualisierungen von $INDEX_ROOT, $ATTRIBUTE_LIST und $BITMAP enthalten sein. Es ist jedoch möglich, die Attribute manuell zurückzuverfolgen, um Nicht-$DATA herauszufiltern, indem man den OffsetInMft mit dem vergleicht, was im relevanten InitializeFileRecordSegment oder, falls zutreffend, in der $MFT selbst gefunden wird. Ab Version 2.0.0.13 wurde die Extraktion von $EA hinzugefügt. Siehe Hinweis zu $EA-Attributen.
Filenames csv Ab Version 2.0.0.6 wurde eine neue Funktion implementiert, um alle identifizierten Dateinamen auszugeben. Die Quelle dieser Einträge stammt aus InitializeFileRecordSegment, UpdateNonResidentValue, AddindexEntryRoot, DeleteindexEntryRoot, AddIndexEntryAllocation, DeleteIndexEntryAllocation und WriteEndOfIndexBuffer. Die csv mit diesen Dateinamen, LogFile_FileNames.csv, enthält somit eine rekonstruierte Historie aller Dateinamen, MftRef und MftRefSeqNo für die Dauer der $LogFile-Historie. Sie werden somit in der Lage sein, alle verschiedenen Dateinamen zu sehen, die ein gegebener Mft-Datensatz während des Zeitraums hatte, den die $LogFile abdeckte. Wenn eine Datei umbenannt wird, wird die MftrefSeqNo nicht inkrementiert. Wenn ein MFT-Datensatz als gelöscht markiert und später wiederverwendet wird, wird die MftRefSeqNo bei der neuen Initialisierung um eins inkrementiert.
$TXF_DATA Bei Transactional NTFS (TxF) wird es Vorkommen des benannten Streams $TXF_DATA im Attribut $LOGGED_UTILITY_STREAM geben. Er ist immer resident, und es kann mehrere pro Datei geben. Die Verwendung ist nicht weit verbreitet, und Microsoft ermutigt tatsächlich zu alternativen Methoden. [quote]Microsoft strongly recommends developers utilize alternative means to achieve your applications needs.[/quote]. Es scheint, dass nur wenige Software-Aktualisierungsmechanismen ihn verwenden. Jede Datei/jeder Ordner, die/die damit erstellt wird, erhält eine eindeutige Fileref (nicht zu verwechseln mit MFT-Datensatznummern). Diese eindeutige Fileref ist es, nach der die Datei benannt wird, wenn sie später gelöscht wird (und in den Ordner $Extend$RmMetadata$Txf verschoben wird). Das standardmäßige unbenannte $DATA-Attribut der $Tops-Datei enthält Informationen darüber, wohin in der $TxfLogContainer00000000000000000001 die nächste Transaktion gehen würde. Der benannte $DATA-Stream $T der $Tops enthält tatsächliche Daten (aus transaktionalen Dateioperationen), die recycelt werden. Innerhalb von $TXF_DATA gibt es auch ein Feld namens LsnUserData, das ein Offset in die $TxfLogContainer00000000000000000001 ist, wo viel mehr Transaktionsdetails zu finden sind. LsnNtfsMetadata enthält ebenfalls ein Offset in dieselbe $TxfLogContainer00000000000000000001-Datei. Beachten Sie, dass diese Offsets zu einem späteren Zeitpunkt geändert werden können und dann in einer UpdateResidentValue-Operation in der $LogFile referenziert werden. Das Feld MftRef_RM_Root ist die Dateidatensatznummer der Wurzel des Ressourcenmanagers, der für die mit dieser Datei verbundene Transaktion verantwortlich ist (Standard ist 5, was das Stammverzeichnis ist). Bei Aktualisierungen von $TXF_DATA durch UpdateResidentValue wird der Text "Partial update" im Feld TextInformation angehängt. Aus diesem Grund kann es auch Werte wie 0x0000000000007E-- in LsnUserData geben. Dies liegt daran, dass ein UpdateResidentValue der Größe 31 Bytes bedeutet, dass die ersten 3 Mitglieder der vollständigen Struktur fehlen und auch 1 Byte von LsnUserData fehlt. Das fehlende Byte ist das "niedrige Byte", also 2 Zeichen/Nibbles von jeweils "-" als Ersatz, um das fehlende unbekannte Byte anzuzeigen (eigentlich nur das vorhandene Byte). Wenn UpdateResidentValue bei 32 Bytes läge, wären keine Ersatzzeichen/Nibbles erforderlich, da die vollständige LsnUserData bereitgestellt würde.
debug.log In diesem Log werden Fehlermeldungen und ausführliche Informationen geschrieben. Wenn seltsame Werte oder Kommentare in der Ausgabe gefunden werden, suchen Sie in debug.log nach der lsn. Üblicherweise wird die gesamte Transaktion ausgegeben, was beim Verständnis helfen kann. Zur Unterstützung von Untersuchungen von Transaktionen kann es hilfreich sein, eine kommagetrennte Liste von lsn's in das Eingabefeld einzutragen. Dann werden ausführliche Informationen für diese lsn's ausgegeben.
$EA Das $EA-Attribut ist eine Menge von Name-Wert-Paaren und wird vermutlich aus Kompatibilität mit OS/2 dort belassen. Es wird selten verwendet, obwohl einige Malware es genutzt hat. Es kann mehrere Paare pro Attribut geben, aber die maximale Größe aller beträgt 65535 Bytes. Es kann nur 1 $EA-Attribut pro Datei geben. Größerer Inhalt kann über mehrere Dateien verteilt werden, wie im EaTools PoC gezeigt; https://github.com/jschicht/EaTools Bestehende $EA-Attribute können nicht direkt geändert werden. Zusätzliche Name/Wert-Paare können jederzeit hinzugefügt werden, solange die Größe aller Paare unter 0xFFFF Bytes liegt. Das seltsame Verhalten dieses Attributs ist, dass der gesamte Inhalt des gesamten $EA für jedes neue Paar in die $LogFile geschrieben wird. Das gilt sowohl für residenten als auch für nicht-residenten $EA-Inhalt. Das bedeutet, wenn ein drittes Name/Wert-Paar zu einem $EA hinzugefügt wird, werden alle 3 Paare in die $LogFile geschrieben, entweder durch UpdateResidentValue oder UpdateNonResidentValue.
Todo Implementierung weiterer Analysen der in ntfs.db vorhandenen Daten. Derzeit erfordert es ein gewisses Maß an NTFS-Kenntnissen, um die Ausgabe zu verstehen. Ausgabe von nicht-residentem $EA-Inhalt.
Kommandozeilenverwendung Wenn keine Parameter angegeben werden, startet standardmäßig die GUI. Gültige Schalter sind:
Schalter: /LogFileFile: Eingabe der extrahierten $LogFile. Erforderlich, es sei denn /LogFileFragmentFile: wird verwendet. /LogFileFragmentFile: Optional Eingabe eines $LogFile-Fragments. Kann ein beliebiges defektes Fragment mit mindestens 1 Transaktion sein. /MftCsvFile: Die Ausgabe-csv des neuesten Mft2Csv. Optional. /OutputPath: Der Ausgabepfad aller Parser-Ausgaben. Standardmäßig das Programmverzeichnis. /TimeZone: Ein Zeichenkettenwert für die Zeitzone. Siehe Hinweise weiter unten für gültige Werte. /OutputFormat: Das Ausgabeformat der csv. Gültige Werte sind l2t, BodyFile, all. /BrokenMft: Boolescher Wert für die Behandlung von MFTs mit fehlerhaftem Format. Standard ist 0. Kann 0 oder 1 sein. /SkipFixups: Boolescher Wert zum Überspringen von Fixups. Wird primär bei Speicherabbildern verwendet. Standard ist 0. Kann 0 oder 1 sein. /Separator: Das in der csv zu verwendende Trennzeichen. Standard ist | /Unicode: Boolescher Wert für die Dekodierung von Unicode-Zeichenketten. Standard ist 0. Kann 0 oder 1 sein. /TSFormat: Eine Ganzzahl von 1 - 6 zur Angabe des Zeitstempelformats. Starten Sie die GUI, um zu sehen, was sie bedeuten. Standard ist 6. /TSPrecision: Welche Genauigkeit im Zeitstempel verwendet werden soll. Gültige Werte sind None, MilliSec und NanoSec. Standard ist NanoSec. /TSPrecisionSeparator: Das Trennzeichen, das zur Trennung der Genauigkeit verwendet werden soll. Standard ist ".". Starten Sie die GUI, um zu sehen, was es bedeutet. /TSPrecisionSeparator2: Das Trennzeichen, das zwischen MilliSec und NanoSec in der Genauigkeit des Zeitstempels verwendet werden soll. Standard ist leer/nichts. Starten Sie die GUI, um zu sehen, was es bedeutet. /TSErrorVal: Ein benutzerdefinierter Fehlerwert, der bei Fehlern in der Zeitstempeldekodierung verwendet wird. Standardwert ist '0000-00-00 00:00:00', was mit MySql kompatibel ist und einen ungültigen Zeitstempelwert für NTFS darstellt. /ReconstructDataruns: Boolescher Wert zur Angabe, ob eine Rekonstruktion von Dataruns durchgeführt werden soll. Standard ist 0. Kann 0 oder 1 sein. /MftRecordSize: Die Größe der MFT-Datensätze. Gültige Werte sind 1024 und 4096. Standard ist 1024. /RebuildHeadersSlack: Boolescher Wert zur Angabe, ob versucht werden soll, den Header aus defekten Transaktionen, die aus Slack wiederhergestellt wurden, neu aufzubauen. Standard ist 0. Kann 0 oder 1 sein. /SectorsPerCluster: Anzahl der Sektoren pro Cluster. Standard ist 8. Kann 1,2,4,8,16,32,64 und 128 sein. /LsnErrorLevel: Ein Wert zwischen 0 und 1 (100%) als Schwellenwert zur Identifizierung gültiger/ungültiger Transaktionen aus Slack, basierend auf der vorherigen lsn. Standard ist 0.1 (10%). /SourceIs32bit: Boolescher Wert zur Angabe, ob das Volume von einem 32-Bit-System stammt. Standard ist 0 (x64). Kann 0 oder 1 sein. /ExtractDataUpdates: Boolescher Wert zur Angabe, ob eine Extraktion des residenten Dateninhalts durchgeführt werden soll. Standard ist 0. Kann 0 oder 1 sein. /ExtractDataUpdatesSize: Wert zur Festlegung der Mindestgröße in Bytes für das, was extrahiert werden soll. Wird nur mit der Einstellung ExtractDataUpdates verwendet. Standard ist 2 (Bytes) als Minimum. /VerboseLsnList: Eine kommagetrennte Liste von lsn's, die den ausführlichen Modus auslösen. Ausführliche Protokollierungsinformationen finden sich in debug.log. /SkipSqlite3: Boolescher Wert zur Angabe, ob der Parser alle sqlite3-Operationen auslassen soll. Wenn die generierte ntfs.db (Rekonstruktion von Dataruns, Import der mft csv) nicht verwendet wird, kann dies sicher ignoriert/ausgelassen werden. Standard ist 0. Kann 0 oder 1 sein. /VerifyFragment: Boolescher Wert zur Aktivierung einer einfachen Validierung nur eines Fragments und nicht des vollständigen Parsers. Kann 0 oder 1 sein. Schreibt standardmäßig das reparierte Fragment nach OutFragment.bin, sofern nicht anders in /OutFragmentName: angegeben. /OutFragmentName: Der Ausgabedateiname, in den das reparierte Fragment geschrieben werden soll, wenn /VerifyFragment: auf 1 gesetzt ist. Wenn ausgelassen, ist der Standarddateiname OutFragment.bin. /SkipFixups: Boolescher Wert zum Überspringen von Fixups. Wird bei rekonstruierten Fragmenten verwendet. Siehe Beispiele. Standard ist 0. Kann 0 oder 1 sein. /BrokenLogFile: Boolescher Wert, um $LogFile als defekt zu behandeln. Wird bei rekonstruierten RCRDs verwendet und umgeht mehrere Validierungsprüfungen. Standard ist 0. Kann 0 oder 1 sein.
Die verfügbaren TimeZone's zur Verwendung sind: -12.00 -11.00 -10.00 -9.30 -9.00 -8.00 -7.00 -6.00 -5.00 -4.30 -4.00 -3.30 -3.00 -2.00 -1.00 0.00 1.00 2.00 3.00 3.30 4.00 4.30 5.00 5.30 5.45 6.00 6.30 7.00 8.00 8.45 9.00 9.30 10.00 10.30 11.00 11.30 12.00 12.45 13.00 14.00
Fehlerstufen Die aktuellen Exit-(Fehler-)Codes wurden im Kommandozeilenmodus implementiert, was ihn besser für Batch-Skripting geeignet macht.
Wenn Sie also %ERRORLEVEL% == 1 erhalten, bedeutet dies, dass nichts dekodiert wurde, und wenn Sie %ERRORLEVEL% == 2 erhalten, dann wurde höchstwahrscheinlich der Parameter SectorsPerCluster falsch gesetzt.
Beispiele: LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:2.00 /MftRecordSize:4096 /ExtractDataUpdates:1 /ExtractDataUpdatesSize:8 /SectorsPerCluster:64 /TSFormat:1 /TSPrecision:NanoSec /Unicode:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:-5.00 /MftRecordSize:1024 /SectorsPerCluster:1 /TSFormat:1 /TSPrecision:MilliSec /Unicode:0 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TSFormat:3 /ReconstructDataruns:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:7.00 /MftRecordSize:1024 /TSFormat:2 /TSPrecision:None /SourceIs32bit:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:7.00 /MftRecordSize:1024 /TSFormat:2 /TSPrecision:None /SourceIs32bit:1 /SkipSqlite3:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /OutputPath:E:\LFP-Output LogFileParser.exe /LogFileFile:c:\temp$LogFile /MftCsvFile:c:\temp$MFT LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output /VerifyFragment:1 LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output /VerifyFragment:1 /OutFragmentName:FragmentsRCRDCollection.bin LogFileParser.exe /LogFileFile:E:\LFP-Output\FragmentsRCRDCollection.bin /OutputPath:E:\LFP-Output /SkipFixups:1 /BrokenLogFile:1
Das letzte Beispiel ist ein einfaches, das gängige Standardwerte verwendet, die in vielen Fällen gut funktionieren. Auch kompatibel mit MySql-Importen.
Referenzen: Windows Internals 6th Edition http://www.opensource.apple.com/source/ntfs/ntfs-80/kext/ntfs_logfile.h https://dl.dropbox.com/s/c0u980a53ipaq7h/CEIC-2012_Anti-Anti_Forensics.pptx?dl=1
