jschicht/logfileparserNTFS上の$LogFile用パーサー
機能 $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 値の違いによって区別できることに注意してください。
別のダウンロードパッケージ「SampleTinyNtfsVolume.zip」には、テスト用の小さな NTFS ボリュームを持つパーティションイメージがあります。ボリューム上には 2 つの削除された非常駐ファイルがあり、どちらも MFT レコードが新しいファイルによって上書きされています。シグネチャ検索に基づくまともな復元ソフトウェアなら、jpg ファイル (Tulips.jpg) は連続しているため復元できるはずです。ただし、そのファイル名やファイルに関するその他の情報を特定できる可能性は低いです。2 番目のファイルは断片化 (圧縮) されており、MFT レコードが上書きされているため、datarun リストなしでファイルを解決することは不可能であり、標準ツールでは復元できない可能性があります。PoC を使用すると、ファイル名 (suspicious.zip) を特定し、完璧な状態で抽出できます (心配しないでください。Windows に同梱されているサンプル画像の 1 つが含まれているだけです)。サンプルイメージの詳細と、出力の解釈方法およびファイルの復元方法については、readme.DataRunsResolved.txt をお読みください。
これで達成したことは、MFT レコードが上書きされた断片化されたファイルを復元することです。部分的な/完全な datarun 履歴を再構築したので、ファイルスラックデータが特定のファイルに属していたかどうかを確実に (少なくとも完全な履歴が再構築された場合は) 判断できます。
制限事項。 datarun の再構築は UNICODE では壊れています (ANSI は問題ありません)。 Mft2Csv 出力のインポートは、csv が UNICODE の場合壊れています (ANSI は問題ありません)。 IndexRecords (IndexRoot/IndexAllocation) への部分的な更新は、元のインデックスに関する知識がない可能性が高いため、解釈が非常に困難です。完全なレコードは問題ありません。 65 MB ファイルの循環性は、履歴 FS トランザクションの数に固有かつ絶対的な制限を課します。したがって、システムドライブは $LogFile 内の履歴が限られていますが、外部/セカンダリドライブにはより多くの履歴トランザクションが保存されています。chkdsk で $LogFile のサイズを増やすことができます (chkdsk c: /L:262144)。 常駐ファイルのデータへの変更は $LogFile 内に保存されず、変更が行われたという情報のみが保存されます。
注記 $UsnJrnl には、より人間に優しい方法で情報が含まれています。たとえば、各レコードには fileref、filename、timestamp、および何が発生したかの説明が含まれています。また、$LogFile よりもはるかに多くの履歴情報を含みますが、多くの詳細は含まれていません。$UsnJrnl がアクティブな場合、$LogFile のリサイクルライフ中にそれに書き込まれたすべてのトランザクションも $LogFile 内に存在します。これは、$LogFile をよりよく理解するために $UsnJrnl をデコードする理由がないことを意味します。
スラックスペース この文脈では、スラックスペースとは、RCRD レコード内で最後のトランザクションを超えたレコード内の残りのスペースを意味します。これは以前に説明されたことがないと思うので、説明させてください。ボリュームスラックは、ファイルシステムの終わりとファイルシステムが存在するパーティションの終わりの間の未使用スペースです。MFT レコードスラックも同様ですが、レコード終了シグネチャ (0xFFFFFFFF) の後から物理レコード終了 (0x400 または 0x1000) までのスペースを指します。そして $LogFile 内のスラックスペースは、最後のトランザクションを超えて RCRD レコード終了 (通常は 0x1000) までのスペースです。スラックからのこれらのトランザクションは、実際には $LogFile がリサイクル (上書き) される前のものです。スラックスペースから有効なトランザクションを識別するアルゴリズムもあります。さらに、そのようなスラックスペースの複数の層が存在する場合もあります。 例: 特定の RCRD レコードの最後のトランザクションがオフセット 0x00007D27 で終了したとします。このオフセットから 0x00007FFF までに 0x2D8 バイトのスラックスペースがあります。その場合、0x00007D28 から始まるバイトはトランザクションの途中であるため、有効なトランザクションヘッダーではない可能性があります。プログラムは (設定されている場合) トランザクションをデコードするために有効な値を持つ疑似ヘッダーの再構築を試みます。有効なヘッダーの再構築に失敗した場合、元のヘッダーからあまりにも多くの情報が失われたと見なし、これらのバイトを失われたものとして扱い、スラックスペースの残りをスキャンして有効なトランザクションヘッダーを探し続けます。失われたバイトは調査のために debug.log に記録されます。一方、有効なヘッダーを再構築できた場合、これに関する情報は lf_TextInformation フィールドにあります。オフセット 0x00007D48 で始まりサイズ 0xB0 のトランザクションが識別されたとします。次に、すぐ後に続くオフセット 0x00007DF8 でサイズ 0xE0 の別の良好なトランザクションが識別されました。ただし、オフセット 0x00007ED8 には有効なトランザクションヘッダーがありませんでした。これは、その RCRD レコード内のスラックスペースの第 2 層にいることを意味します。次に、プログラムが再スキャン後、オフセット 0x00007F18 で有効なトランザクションヘッダーを識別できたとします。このトランザクションは、csv の FromRcrdSlack フィールドに値 2 でマークされます。ただし、トランザクションの合計サイズがオフセットを RCRD レコードサイズを超えて押し出す場合を考慮してください。本質的に、これは部分的に復元されたトランザクションであり、正常にデコードされる可能性がありますが、IncompleteTransaction フィールドに値 1 で見つかります。debug.log は非常に詳細であり、デコードされた出力、特にスラックスペースから来るものを理解するのに役立つことを覚えておいてください。
32 ビット vs 64 ビット構成。 この設定は正しく設定することが重要です。これは、どの OS がターゲットボリュームを処理したかを意味します。ポイントは、OpenAttributeTable の処理が 32 ビット OS と 64 ビット OS で異なることです。もちろん、ボリュームが複数の異なる OS によって処理された場合 (たとえば USB ディスク) があり、その場合はこの設定を 100% 正確にするのが難しいかもしれません。バージョン 2.0.0.8 から自動検出メカニズムが実装されました。ただし、この構成を正しく設定することを試みることは依然として推奨されます。TextEinformation フィールドには、構成と異なる OpenAttributeTableDump 形式が検出された場合、または両方のタイプが検出された場合に「Mixed OS detected」メッセージが出力されます。いずれにせよ、LogFile_OpenAttributeTable.csv を調べて出力を評価するのが役立つかもしれません。奇妙な値を含む列を持つエントリが表示される場合、この特定の設定が間違っている可能性があります。その場合、ほとんどの値が大きくずれています。たとえば、ほとんどの AttributeType フィールドが UNKNOWN であり、Lsn が現在の範囲内になく、MftRef が高すぎ、MftRefSeqNo が 0 です。AttributeType はテーブル内の未初期化エントリに対して UNKNOWN として解決されますが、これらは AllocatedOrNextFree 以降のすべての値が 0 であり完全に有効であるため、簡単に見つけることができます。これらの課題は、バージョン 2.0.0.8 で実装された自動検出で修正されたようです。レジデント属性更新の抽出（UpdateResidentValue）。 UpdateResidentValue操作は、レジデント属性の内容への更新のためのものです。「Extract resident updates of min size」の設定により、レジデント属性へのバイナリ変更を抽出できます。入力フィールドは、抽出する最小サイズ（バイト単位）を指定するためのものです。この機能の最も興味深い用途は、おそらくNt5.x（XP、2003）で処理されるボリュームでしょう。そこでは、$DATA属性（通常のファイル内容）への完全な更新が、UpdateResidentValueを伴うredoおよびundoフィールドに格納されます。レジデントな$DATA内容を持つファイルは、より小さいサイズのファイルであり、最大で744バイト（MFTレコードサイズが1024の場合）ですが、通常はそれより小さいです。抽出されたデータは、ResidentExtractという名前のサブフォルダに書き込まれます。出力ファイルは、次のようなロジックで命名されます：MFT($MFTRef)$OffsetInMft$AttributeOffset_LSN($Lsn)$Operation.bin。例えば、MFT(1643)_0x0098_0x00B8_LSN(1415242628)redo.binは、MFTレコード番号1643、MFT内の対象属性のオフセットが0x98、対象属性内の変更のオフセットが0xB8、トランザクションのLSNが1415242628、そしてこれがredo操作のものであったことを意味します。したがって、undo操作の抽出物には、変更前のそのオフセットにおけるデータが含まれています。この機能を有効にすると、いくつかの無関係で興味のない出力が発生します。ほとんどの誤検出は自動的にフィルタリングされますが、一部は避けられません。例えば、$INDEX_ROOT、$ATTRIBUTE_LIST、$BITMAPの更新が含まれることがあります。ただし、OffsetInMftを、関連するInitializeFileRecordSegmentで見つかったもの、または該当する場合は$MFT自体で見つかったものと比較することにより、手動で属性を追跡して非$DATAをフィルタリングすることは可能です。バージョン2.0.0.13から、$EAの抽出が追加されました。$EA属性に関する注記を参照してください。
Filenames csv バージョン2.0.0.6から、特定されたすべてのファイル名をダンプする新機能が実装されました。これらのエントリのソースは、InitializeFileRecordSegment、UpdateNonResidentValue、AddindexEntryRoot、DeleteindexEntryRoot、AddIndexEntryAllocation、DeleteIndexEntryAllocation、およびWriteEndOfIndexBufferから来ています。これらのファイル名を含むcsv、LogFile_FileNames.csvは、したがって、$LogFileの履歴の期間中におけるすべてのファイル名、MftRef、およびMftRefSeqNoの再構築された履歴を含んでいます。これにより、$LogFileがカバーする期間中に、特定のMftレコードが持っていたさまざまなファイル名をすべて見ることができるようになります。ファイルの名前が変更されても、MftrefSeqNoはインクリメントされません。MFTレコードが削除済みとしてマークされ、後に再利用されると、新しい初期化に伴ってMftRefSeqNoが1つインクリメントされます。
$TXF_DATA Transactional NTFS（TxF）では、$LOGGED_UTILITY_STREAM属性内に$TXF_DATAという名前のストリームが出現することがあります。これは常にレジデントであり、1つのファイルに複数存在することがあります。使用は広く普及しておらず、Microsoftは実際には代替手段を推奨しています。[quote]Microsoft strongly recommends developers utilize alternative means to achieve your applications needs.[/quote]。これを利用するソフトウェア更新メカニズムはごく少数のようです。これで作成されたすべてのファイル/フォルダは、一意のfileref（MFTレコード番号と混同しないでください）を取得します。この一意のfilerefは、後で削除されたとき（そして$Extend$RmMetadata$Txfフォルダに移動されたとき）にファイルが命名される名前です。$Topsファイルの標準の名前なし$DATA属性には、$TxfLogContainer00000000000000000001内の次のトランザクションがどこに行くかに関する情報が含まれています。$Topsの名前付き$DATAストリーム$Tには、リサイクルされる実際のデータ（トランザクションファイル操作からのもの）が含まれています。$TXF_DATA内には、LsnUserDataというフィールドもあり、これは$TxfLogContainer00000000000000000001へのオフセットで、そこにはるかに多くのトランザクション詳細が見つかります。LsnNtfsMetadataも、同じ$TxfLogContainer00000000000000000001ファイルへのオフセットを含んでいます。これらのオフセットは後の段階で変更される可能性があり、その場合は$LogFile内のUpdateResidentValue操作で参照されることに注意してください。MftRef_RM_Rootフィールドは、このファイルに関連するトランザクションを担当するリソースマネージャのルートのファイルレコード番号です（デフォルトは5で、これはルートディレクトリです）。UpdateResidentValueを通じた$TXF_DATAへの更新では、TextInformationフィールドに「Partial update」というテキストが追加されます。このため、LsnUserData内に0x0000000000007E--のような値が存在することもあります。これは、サイズ31バイトのUpdateResidentValueは、完全な構造の最初の3つのメンバーが欠けており、さらにLsnUserDataから1バイトが欠けていることを意味するためです。欠けているバイトは「下位バイト」であり、したがって「-」が2文字/ニブルずつ、欠けている未知のバイト（実際には単に既存のバイト）を示す置換として使用されます。UpdateResidentValueが32バイトであった場合、完全なLsnUserDataが提供されているため、置換文字/ニブルは必要ありません。
debug.log このログには、エラーメッセージと詳細情報が書き込まれます。出力に奇妙な値やコメントが見つかった場合は、debug.logでそのlsnを検索してください。通常、トランザクション全体がダンプされており、理解の助けになるかもしれません。トランザクションの調査を支援するために、入力フィールドにlsnのカンマ区切りリストを記入すると役立つ場合があります。そうすると、これらのlsnの詳細情報が出力されます。
$EA $EA属性は名前と値のペアのセットであり、OS/2との互換性のために存在すると考えられています。使用されることはまれですが、一部のマルウェアがこれを使用しています。1つの属性に複数のペアが存在することがありますが、すべての最大サイズは65535バイトです。1つのファイルに存在できる$EA属性は1つだけです。より大きな内容は、EaTools PoCで示されているように、複数のファイルに分散させることができます：https://github.com/jschicht/EaTools 既存の$EA属性を直接変更することはできません。すべてのペアのサイズが0xFFFFバイト未満である限り、いつでも追加の名前/値ペアを追加できます。この属性の奇妙な挙動は、新しいペアに対して$EA全体のすべての内容が$LogFileに書き込まれることです。これはレジデントおよび非レジデントの$EA内容の両方に当てはまります。つまり、3番目の名前/値ペアが$EAに追加されると、3つのペアすべてがUpdateResidentValueまたはUpdateNonResidentValueを通じて$LogFileに書き込まれます。
Todo ntfs.dbに存在するデータのより多くの分析を実装する。現在、出力を理解するには一定レベルのNTFS知識が必要です。 非レジデント$EA内容のダンプ。
Command line use パラメータが指定されていない場合、GUIがデフォルトで起動します。有効なスイッチは次のとおりです：
Switches: /LogFileFile: 入力$LogFileを抽出したもの。/LogFileFragmentFile:が使用されない限り必須です。 /LogFileFragmentFile: オプションで$LogFileフラグメントを入力します。少なくとも1つのトランザクションを含む任意の壊れたフラグメントで構いません。 /MftCsvFile: 最新のMft2Csvの出力csv。オプション。 /OutputPath: すべてのパーサー出力の出力パス。デフォルトはプログラムディレクトリです。 /TimeZone: タイムゾーンの文字列値。有効な値については後述の注記を参照してください。 /OutputFormat: csvの出力形式。有効な値はl2t、BodyFile、allです。 /BrokenMft: 不正な形式のMFTを処理するためのブール値。デフォルトは0。0または1を指定できます。 /SkipFixups: fixupをスキップするためのブール値。主にメモリダンプで使用されます。デフォルトは0。0または1を指定できます。 /Separator: csvで使用する区切り文字。デフォルトは| /Unicode: Unicode文字列をデコードするためのブール値。デフォルトは0。0または1を指定できます。 /TSFormat: タイムスタンプ形式を指定する1～6の整数。それぞれの意味についてはGUIを起動して確認してください。デフォルトは6です。 /TSPrecision: タイムスタンプで使用する精度。有効な値はNone、MilliSec、NanoSecです。デフォルトはNanoSecです。 /TSPrecisionSeparator: 精度の区切りに使用する区切り文字。デフォルトは「.」。その意味についてはGUIを起動して確認してください。 /TSPrecisionSeparator2: タイムスタンプの精度においてMilliSecとNanoSecの間に使用する区切り文字。デフォルトは空/なし。その意味についてはGUIを起動して確認してください。 /TSErrorVal: タイムスタンプデコード時のエラーに付与するカスタムエラー値。デフォルト値は「0000-00-00 00:00:00」で、MySqlと互換性があり、NTFSにとって無効なタイムスタンプ値を表します。 /ReconstructDataruns: datarunの再構築を実行するかどうかを指定するブール値。デフォルトは0。0または1を指定できます。 /MftRecordSize: MFTレコードのサイズ。有効な値は1024と4096です。デフォルトは1024です。 /RebuildHeadersSlack: slackから復元された壊れたトランザクションからヘッダーの再構築を試みるかどうかを指定するブール値。デフォルトは0。0または1を指定できます。 /SectorsPerCluster: クラスタあたりのセクタ数。デフォルトは8。1、2、4、8、16、32、64、128を指定できます。 /LsnErrorLevel: 前のlsnに基づいて、slackから有効/無効なトランザクションを識別するためのしきい値としての0から1（100%）の間の値。デフォルトは0.1（10%）です。 /SourceIs32bit: ボリュームが32ビットシステム由来かどうかを指定するブール値。デフォルトは0（x64）。0または1を指定できます。 /ExtractDataUpdates: レジデントデータ内容の抽出を実行するかどうかを指定するブール値。デフォルトは0。0または1を指定できます。 /ExtractDataUpdatesSize: 抽出する対象の最小サイズ（バイト単位）を設定する値。ExtractDataUpdates設定と併用する場合にのみ使用されます。デフォルトは最小2（バイト）です。 /VerboseLsnList: 詳細モードをトリガーするlsnのカンマ区切りリスト。詳細ログ情報はdebug.logにあります。 /SkipSqlite3: パーサーがすべてのsqlite3操作を省略すべきかどうかを指定するブール値。生成されたntfs.db（datarunの再構築、mft csvのインポート）が使用されない場合、これは安全に無視/省略できます。デフォルトは0。0または1を指定できます。 /VerifyFragment: 完全なパーサーではなく、フラグメントのみに対して簡単な検証を有効にするブール値。0または1を指定できます。/OutFragmentName:で別途指定されない限り、デフォルトで修正されたフラグメントをOutFragment.binに書き込みます。 /OutFragmentName: /VerifyFragment:が1に設定されている場合に、修正されたフラグメントを書き込む出力ファイル名。省略した場合、デフォルトのファイル名はOutFragment.binです。 /SkipFixups: fixupをスキップするためのブール値。再構築されたフラグメントで使用されます。例を参照してください。デフォルトは0。0または1を指定できます。 /BrokenLogFile: $LogFileを壊れているものとして扱うブール値。再構築されたRCRDで使用され、いくつかの検証チェックをバイパスします。デフォルトは0。0または1を指定できます。
使用可能なTimeZoneは次のとおりです： -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
Error levels 現在の終了（エラー）コードはコマンドラインモードで実装されており、バッチスクリプトにより適しています。
したがって、%ERRORLEVEL% == 1が得られた場合は何もデコードされなかったことを意味し、%ERRORLEVEL% == 2が得られた場合はほとんどの場合SectorsPerClusterパラメータが誤って設定されていたことを意味します。
Examples: 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
最後の例は、多くの場合に問題なく機能する一般的なデフォルトを使用した基本的なものです。MySqlインポートとも互換性があります。
References: 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
