功能 解码并转储 $LogFile 记录和事务条目。 解码 NTFS 属性更改。 可选地解析 $LogFile 中所有可用的数据运行列表信息。选项：“重建数据运行”。 从 $LogFile 内的松弛空间中恢复事务。 选择重建在松弛空间中发现的事务的缺失或损坏的头部。选项：“重建头部”。 可选地使用 LSN 错误级别值微调结果。选项：“LSN 错误级别”。 记录到 csv 并导入到包含多个表的 sqlite 数据库。 可选地将 mft2csv 的 csv 输出导入到数据库。 在 6 种不同的时间戳格式中选择。 选择时间戳精度：无、毫秒和纳秒。 选择毫秒精度分隔符。 选择纳秒精度分隔符。 选择时间戳的区域调整。默认以 UTC 0.0 呈现时间戳。 选择输出分隔符。选项：“设置分隔符”。 可配置 UNICODE 或 ANSI 输出。选项“Unicode”。 可配置 MFT 记录大小（1024 或 4096）。选项“MFT 记录大小”。 可选地解码单个事务或部分事务（片段）。 选项从单个或多个事务（片段）重建 RCRD。 选项配置损坏的 $LogFile。在将雕刻出的 RCRD 作为输入时有用。 选项跳过修复（用于损坏的 $LogFile，通常从内存中雕刻）。 将详细的详细输出写入 debug.log。 可配置的逗号分隔的 lsn 列表，用于触发将特定事务的超详细信息化输出到 debug.log。 32 位操作系统的配置。 用于提取常驻数据更新的二进制数据的配置。 自动生成的 sql，用于将输出导入 MySql 数据库。 选项跳过所有 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 重建数据运行所需的输入信息
LogFile_DataRunsResolved.csv 重建数据运行的最终输出
LogFile_INDX_I30.csv 所有转储并解码的索引记录（IndexRoot/IndexAllocation）
LogFileJoined.csv 与 LogFile.csv 相同，但从 $UsnJrnl 或 mft2csv 的 csv 中联接了文件名信息。
MFTRecords.bin 基于 InitializeFileRecordSegment 事务中找到的 MFT 记录重建的虚拟 $MFT。可以对此使用 mft2csv（记得正确配置“损坏的 MFT”和“修复”）。
LogFile_lfUsnJrnl.csv 在 $LogFile 中解码的 $UsnJrnl 记录
LogFile_UndoWipe_INDX_I30.csv 清除目录索引（INDX）的所有撤销操作。
LogFile_AllTransactionHeaders.csv 所有已解码事务的头部。
LogFile_BitsInNonresidentBitMap.csv 所有已解码的 SetBitsInNonresidentBitMap 操作。
LogFile_DirtyPageTable32bit.csv 和 LogFile_DirtyPageTable64bit.csv 每个已解码的 DirtyPageTableDump 操作中针对 32 位和 64 位操作系统的所有条目。
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 UpdateFileNameRoot 和 UpdateFileNameAllocation 的 redo 和 undo 操作的所有解码。
LogFile_CompensationlogRecord.csv CompensationlogRecord 的所有解码。与 nt5.x 无关。
Ntfs.db 一个 sqlite 数据库文件，其表与上述 csv 几乎等效。该数据库包含 5 个表： DataRuns IndexEntries LogFile LogFileTmp（重建数据运行时使用的临时表）。 UsnJrnl
时间戳 默认以 UTC 0.00 呈现，并具有纳秒精度。默认格式为 YYYY-MM-DD HH:MM:SS:MSMSMS:NSNSNSNS。这些可以配置。不同的时间戳指的是： CTime 表示文件创建时间。 ATime 表示文件修改时间。 MTime 表示 MFT 条目修改时间。 RTime 表示文件最后访问时间。
重建数据运行。
文件系统上的许多操作都会触发 $LogFile 中的事务。与 $DATA 属性（即文件内容）相关的事务目前被识别为；
InitializeFileRecordSegment CreateAttribute UpdateMappingPairs SetNewAttributeSizes
它们都在 $LogFile 中留下不同的信息。常驻数据修改的行为不同，不能就这样重建，至少在来自现代 Windows 版本的 NTFS 卷上是这样。
InitializeFileRecordSegment 是在创建新文件时。因此它将具有 $FILE_NAME 属性，以及原始 $DATA 属性内容，包括数据运行。由于 $LogFile 是循环的，旧事件会被新事件覆盖，因此 $LogFile 的挑战在于获取足够久远的信息。但是，如果存在 InitializeFileRecordSegment，那么我们应该能够重建所有内容，因为在此之后写入的所有记录也将可用。我们还将拥有关于数据运行列表偏移量的信息。这是从 $DATA 属性开头计算的相对偏移量。在计算 UpdateMappingPairs 在数据运行列表中的修改位置时，这是重要的信息。
CreateAttribute 是属性首次创建时的原始属性（如果不是作为 InitializeFileRecordSegment 的一部分写入）。对于这个也是如此，我们应该能够重建数据运行，因为我们拥有所有可用的事务。但是，这个本身不会为我们提供文件名。这里同样，我们有可用的数据运行列表偏移量，这在解决 UpdateMappingPairs 时非常有用。
UpdateMappingPairs 是执行对 $DATA/数据运行修改（文件内容已更改）时的事务。此事务中找到的信息并不完整，它只包含添加到现有数据运行列表中的新值。它还包含一个相对偏移量，告诉我们更改已写入数据运行列表中的位置。此偏移量与 InitializeFileRecordSegment 和 CreateAttribute 中找到的数据运行偏移量结合使用。
SetNewAttributeSizes 是一个事务，包含有关对 $DATA 属性所做的任何大小值相关修改的信息。这与仅包含数据运行更改的 UpdateMappingPairs 紧密相关。
通过上述 4 种不同的 redo 操作，对于给定的引用号（不同文件），可以重建文件的某些文件系统更改历史。由于其循环性，我们只有部分历史记录，即最近的部分。我们可以检索的历史范围高度取决于目标是什么类型的卷。如果是系统卷，那么一周的历史记录可能超出您的预期，而可移动或外部或辅助磁盘将包含更多的历史记录。因此，我们可能重建已删除文件（其 $MFT 记录已被覆盖）的完整历史，进而重新创建数据运行列表以执行恢复。在其他情况下，我们可能无法重建完整历史，因此只能重建部分数据运行列表。包含调整后数据运行的最终 csv 文件 LogFile_DatarunsModified.csv 将以不同方式显示数据运行。
说明： 以“!”开头的表示完整的数据运行列表已被重建。 以“?”开头的表示部分恢复，其中“**”的数量表示原始数据运行列表中缺失的字节数。
为了简化基于数据运行的文件恢复，可以使用附带的 PoC，称为 ExtractFromDataRuns。它相当不言自明。只需填写完整的数据运行列表、实际大小和初始大小，以及输出文件的名称。可选地选择处理镜像文件（磁盘或分区）。如果检测到任何压缩/稀疏标志，也请勾选。向其提供部分重建的数据运行列表将无法工作！请注意，备用数据流可以通过数据名称的存在以及给定 fileref 的不同 OffsetInMft 值来区分。
单独的下载包“SampleTinyNtfsVolume.zip”包含一个带有小型 NTFS 卷的分区镜像，可用于测试。该卷上有 2 个已删除的非常驻文件，它们的 MFT 记录都被新文件覆盖。任何基于签名搜索的像样的恢复软件都应该能够恢复 jpg 文件（Tulips.jpg），因为它是连续的。但是，它们很可能无法识别其文件名或有关该文件的任何其他信息。第二个文件很可能无法使用标准工具恢复，因为它是碎片化的（压缩的），并且由于其 MFT 记录被覆盖，在没有数据运行列表的情况下解析该文件是不可能的。使用 PoC，我们可以识别文件名（suspicious.zip）并将其提取为完美状态（别担心，它只包含 Windows 附带的一个示例图像）。阅读文件 readme.DataRunsResolved.txt 以了解有关示例图像的详细信息以及如何解释输出和恢复文件。
我们通过此实现的是恢复 MFT 记录被覆盖的碎片化文件。由于我们已经重建了部分/完整的数据运行历史，我们可以确定地（至少在完整历史被重建的情况下）判断文件松弛数据是否属于给定文件。
限制。 数据运行重建在 UNICODE 下会损坏（ANSI 可以）。 如果 csv 是 UNICODE，则导入 Mft2Csv 输出会损坏（ANSI 可以）。 对 IndexRecords（IndexRoot/IndexAllocation）的部分更新非常难以解释，因为我们可能不了解原始索引。不过完整记录是可以的。 65 MB 文件的循环性对可保留多少历史 FS 事务施加了固有且绝对的限制。因此系统驱动器的 $LogFile 中历史记录有限，而外部/辅助驱动器存储的历史事务更多。可以使用 chkdsk 增加 $LogFile 的大小（chkdsk c: /L:262144）。 对常驻文件数据的更改不会存储在 $LogFile 中，只存储已执行更改的信息。
注意 $UsnJrnl 以更人性化的方式包含信息。例如，每条记录包含 fileref、文件名、时间戳以及对所发生情况的说明。它还包含比 $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 记录内的第二层松弛空间。现在假设程序在重新扫描后能够在偏移 0x00007F18 处识别出有效事务头部。该事务将在 csv 中标记为 FromRcrdSlack 字段值为 2。但是，考虑事务总大小使偏移超过 RCRD 记录大小。本质上，这将是一个部分恢复的事务，可能解码正常，但会在 IncompleteTransaction 字段中发现值为 1。请记住 debug.log 非常详细，将有助于理解解码输出，尤其是来自松弛空间的内容。
