LogFileParser

機能 $LogFile レコードとトランザクションエントリをデコードしてダンプします。 NTFS 属性の変更をデコードします。 $LogFile で利用可能なすべての datarun リスト情報をオプションで解決します。オプション: 「Reconstruct data runs」。 $LogFile 内のスラックスペースからトランザクションを復元します。 スラック内で見つかったトランザクションの欠落または破損したヘッダーを再構築することを選択します。オプション: 「Rebuild header」。 オプションで LSN エラーレベル値を使用して結果を微調整します。オプション: 「LSN error level」。 csv にログを記録し、複数のテーブルを持つ sqlite データベースにインポートします。 オプションで mft2csv の csv 出力を db にインポートします。 6 種類の異なるタイムスタンプ形式から選択します。 タイムスタンプの精度を選択: None、MilliSec、NanoSec。 ミリ秒での精度セパレータを選択します。 ナノ秒での精度セパレータを選択します。 タイムスタンプの地域調整を選択します。デフォルトはタイムスタンプを UTC 0.0 で表示します。 出力セパレータを選択します。オプション: 「Set separator」。 UNICODE または ANSI 出力を設定可能。オプション「Unicode」。 MFT レコードサイズ (1024 または 4096) を設定可能。オプション「MFT record size」。 オプションで個々のトランザクションまたは部分的なトランザクション (フラグメント) をデコードします。 単一または複数のトランザクション (フラグメント) から RCRD を再構築するオプション。 破損した $LogFile を設定するオプション。carved RCRD を入力として使用する場合に便利です。 fixup をスキップするオプション (破損した $LogFile、通常はメモリから carved されたもの)。 debug.log への詳細な冗長出力。 特定のトランザクションに関する超冗長情報を debug.log に出力するためにトリガーする lsn のカンマ区切りリストを設定可能。 32 ビット OS 用の設定。 常駐データ更新のバイナリデータ抽出用の設定。 出力を MySql データベースにインポートするための自動生成 sql。 sqlite3 関連をすべてスキップして解析全体を高速化するオプション。 オプションのコマンドラインモード。バッチスクリプトに適した errorlevel をサポート。

背景 NTFS は回復可能なファイルシステムとして設計されています。これはボリューム構造を変更するすべてのトランザクションをログに記録することで実現されます。したがって、ボリューム上のファイルへの変更は、いつでもシステム障害が発生した場合に元に戻せるように、$LogFile にも何かがログに記録される必要があります。そのため、このファイルには大量の情報が書き込まれ、循環型であるため、新しいトランザクションが古いレコードを上書きします。したがって、このファイルから取得できる履歴データの量にはある程度の制限があります。これもまた、ボリュームの種類と $LogFile のサイズに依存します。頻繁に使用されるシステムのシステムドライブでは、おそらく数時間分の履歴しか得られませんが、バックアップファイルが置かれた外部/セカンダリディスクでは、より多くの履歴情報が含まれている可能性があります。また、2MB のファイルは 256MB のものよりもはるかに少ない履歴しか含みません。では、このファイルはどのようなサイズ範囲で設定できるのでしょうか? 256 KB 以上であれば何でも可能です。サイズを 2 GB に設定するには、次のようにします: 「chkdsk D: /L:2097152」。大きなサイズのログファイルがパフォーマンスに与える影響は、このテキストの範囲外です。2048 より小さく設定することは通常できません。ただし、untfs.dll にパッチを適用することで可能です: http://code.google.com/p/mft2csv/wiki/Tiny_NTFS

はじめに このパーサーは、NTFS 上の $LogFile から多くのトランザクション情報をデコードしてダンプします。いくつかの csv と、すべての関連情報を含む ntfs.db という名前の sqlite データベースが生成されます。出力は非常に詳細で非常に低レベルであるため、理解するにはある程度の NTFS の知識が必要です。現在、意味のある出力デコードで処理される Redo トランザクションタイプは次のとおりです:

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

現在サポートされている属性のリスト: $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

つまり、基本的にすべての属性がサポートされています。

生成される各種出力の説明:

LogFile.csv: パーサーから生成されるメインの csv。

LogFile_DataRuns.csv datarun を再構築するために必要な入力情報

LogFile_DataRunsResolved.csv 再構築された datarun の最終出力

LogFile_INDX_I30.csv ダンプおよびデコードされたすべてのインデックスレコード (IndexRoot/IndexAllocation)

LogFileJoined.csv LogFile.csv と同じですが、$UsnJrnl または mft2csv の csv からファイル名情報が結合されています。

MFTRecords.bin InitializeFileRecordSegment トランザクションで見つかった MFT レコードに基づいて再作成されたダミーの $MFT。これに対して mft2csv を使用できます (「broken MFT」と「Fixups」を適切に設定することを忘れないでください)。

LogFile_lfUsnJrnl.csv $LogFile 内でデコードされた $UsnJrnl のレコード

LogFile_UndoWipe_INDX_I30.csv ディレクトリインデックス (INDX) のクリアに対するすべての undo 操作。

LogFile_AllTransactionHeaders.csv デコードされたトランザクションのすべてのヘッダー。

LogFile_BitsInNonresidentBitMap.csv デコードされたすべての SetBitsInNonresidentBitMap 操作。

LogFile_DirtyPageTable32bit.csv および LogFile_DirtyPageTable64bit.csv 32 ビット OS と 64 ビット OS の両方について、デコードされたすべての DirtyPageTableDump 操作のすべてのエントリ。

LogFile_Mft_ObjectId_Entries.csv デコードされた $ObjectId 属性。

LogFile_ObjIdO.csv システムファイル $ObjId:$O からのすべてのデコード。

LogFile_OpenAttributeTable.csv デコードされたすべての OpenAttributeTableDump 操作のすべてのエントリ。

LogFile_QuotaO.csv システムファイル $Quota:$O からのすべてのデコード。

LogFile_QuotaQ.csv システムファイル $Quota:$Q からのすべてのデコード。

LogFile_RCRD.csv デコードされた RCRD レコードのすべてのヘッダー。

LogFile_ReparseR.csv システムファイル $Reparse:$R からのすべてのデコード。

LogFile_SecureSDH.csv システムファイル $Secure:$SDH からのすべてのデコード。

LogFile_SecureSII.csv システムファイル $Secure:$SII からのすべてのデコード。

LogFile_SecurityDescriptors.csv デコードされたセキュリティ記述子。ソースは $SECURITY_DESCRIPTOR または $Secure:$SDS からです。

LogFile_SlackAttributeNamesDump.csv スラックスペースで見つかった、デコードされた AttributeNamesDump トランザクションからのすべてのエントリ。

LogFile_SlackOpenAttributeTable.csv スラックスペースで見つかった、デコードされた OpenAttributeTableDump トランザクションからのすべてのエントリ。

LogFile_TransactionTable.csv デコードされた TransactionTableDump トランザクション。

LogFile_Filenames.csv MftRef、MftRefSeqNo、Lsn を持つすべての解決済みファイル名。

LogFile_TxfData.csv $LOGGED_UTILITY_STREAM 内の $DATA:$TXF_DATA からデコードされたデータ。

LogFile_UpdateFileName_I30.csv redo 操作と undo 操作の両方について、UpdateFileNameRoot と UpdateFileNameAllocation のすべてのデコード。

LogFile_CompensationlogRecord.csv CompensationlogRecord のすべてのデコード。nt5.x には関係ありません。

Ntfs.db 上記の csv とほぼ同等のテーブルを持つ sqlite データベースファイル。データベースには 5 つのテーブルが含まれています: DataRuns IndexEntries LogFile LogFileTmp (datarun を再作成するときに使用される一時テーブル)。 UsnJrnl

タイムスタンプ デフォルトは UTC 0.00 で、ナノ秒精度で表示されます。デフォルト形式は YYYY-MM-DD HH:MM:SS:MSMSMS:NSNSNSNS です。これらは設定可能です。異なるタイムスタンプは次のことを指します: CTime はファイル作成時刻を意味します。 ATime はファイル変更時刻を意味します。 MTime は MFT エントリ変更時刻を意味します。 RTime はファイル最終アクセス時刻を意味します。

datarun の再構築。

ファイルシステム上の多くの操作は、$LogFile へのトランザクションをトリガーします。$DATA 属性、つまりファイルの内容に関連するものは、これまでに次のように識別されています:

InitializeFileRecordSegment CreateAttribute UpdateMappingPairs SetNewAttributeSizes

これらはすべて $LogFile に異なる情報を残します。常駐データの変更は異なる動作をし、少なくとも現代の Windows バージョンに由来する NTFS ボリュームでは、そのままでは再構築できません。

InitializeFileRecordSegment は、新しいファイルが作成されたときのものです。したがって、$FILE_NAME 属性と、datarun を含む元の $DATA 属性の内容を持ちます。$LogFile は循環型であり、古いイベントは新しいものによって上書きされるため、$LogFile の課題は、十分に過去の情報を取得することです。ただし、InitializeFileRecordSegment が存在する場合、それ以降に書き込まれたすべてのレコードも利用可能であるため、すべてを再構築できるはずです。また、datarun リストへのオフセットに関する情報も得られます。これは $DATA 属性の先頭から計算された相対オフセットです。これは、UpdateMappingPairs が datarun リストのどこで変更を行ったかを計算する際に重要な情報です。

CreateAttribute は、最初に作成されたときの元の属性です (InitializeFileRecordSegment の一部として書き込まれていない場合)。これについても、利用可能なすべてのトランザクションがあるため、datarun を再構築できるはずです。ただし、これ自体はファイル名を提供しません。ここでも、UpdateMappingPairs を解決する際に非常に役立つ datarun リストへのオフセットが利用可能です。

UpdateMappingPairs は、$DATA/datarun への変更 (ファイル内容が変更された) が実行されたときのトランザクションです。このトランザクションで見つかる情報は完全ではなく、既存の datarun リストに追加された新しい値のみを含みます。また、datarun リストのどこに変更が書き込まれたかを示す相対オフセットも含まれます。このオフセットは、InitializeFileRecordSegment と CreateAttribute で見つかる datarun へのオフセットと組み合わせて使用されます。

SetNewAttributeSizes は、$DATA 属性に対して行われたサイズ値に関連する変更に関する情報を含むトランザクションです。これは、datarun の変更のみを含む UpdateMappingPairs と密接に関連しています。

上記の 4 つの異なる redo 操作により、特定の参照番号 (個別のファイル) について、ファイルのファイルシステム変更履歴の一部を再構築できます。循環性のため、履歴の一部、つまり最新のものしか得られません。取得できる履歴の範囲は、ターゲットがどのような種類のボリュームであるかに大きく依存します。システムボリュームの場合、1 週間分の履歴はおそらく期待以上ですが、リムーバブル、外部、またはセカンダリディスクにははるかに多くの履歴が含まれます。したがって、削除されたファイル ($MFT レコードが上書きされている) の完全な履歴を再構築し、次に復元を実行するための datarun リストを再作成できる場合があります。他のケースでは、完全な履歴を再構築できないため、部分的な datarun リストのみを再構築できます。調整された datarun を含む最終的な csv ファイル LogFile_DatarunsModified.csv では、datarun が異なる方法で表示されます。

説明: 「!」で始まるものは、完全な datarun リストが再作成されたことを示します。 「?」で始まるものは、部分的な復元を示し、「**」の数は元の datarun リストから欠落しているバイト数を表します。

datarun に基づいてファイルを復元するのを簡素化するために、ExtractFromDataRuns という添付の PoC を使用できます。これはかなり自明です。完全な datarun リスト、実際のサイズと init サイズ、および出力ファイルの名前を入力するだけです。オプションでイメージファイル (ディスクまたはパーティション) を処理することを選択します。圧縮/スパースフラグが検出された場合もチェックを入れます。部分的に再構築された datarun リストを与えても機能しません! 代替データストリームは、dataname の存在によって、また特定の fileref に対する OffsetInMft 値の違いによって区別できることに注意してください。