← 返回博客

$UsnJrnl 与 $MFT:把变更日志与文件表配对使用

· 阅读 1 分钟

$MFT 是一张快照。它描述每个文件此刻的样子 —— 元数据、数据所在位置、分配状态。它没有记录的,是产生这一状态的那一连串变更。为此,NTFS 还维护着第二件遗留物:Update Sequence Number Journal,简称 $UsnJrnl

$UsnJrnl 记录了什么

每当一个文件被创建、修改、重命名或删除,NTFS 都会向 $UsnJrnl 追加一条固定长度的记录来描述此事件。字段包括:

  • USN(单调递增的 64 位整数);
  • 被修改文件的 MFT 记录号;
  • 父目录的 MFT 记录号;
  • 原因掩码(reason mask):FILE_CREATEDATA_OVERWRITERENAME_OLD_NAMECLOSEFILE_DELETE 等等;
  • 一个时间戳。

整体效果,就是从日志创建或上一次轮转以来,每一次有意义的文件系统事件按时间排成的日志。在普通系统上,这通常覆盖几天到几周。

它住在哪里

$UsnJrnl 就是一份普通的 NTFS 文件,它的数据放在名为 $J 的命名数据流里。它位于特殊目录 $Extend 中,与 $LogFile$Quota 等系统文件并列。

你可以用获取 $MFT 的同一批工具拿到它:

  • KAPE 的 MFT 目标里就包含了 $UsnJrnl;
  • FTK Imager 可从 [NTFS 卷]/$Extend/$UsnJrnl:$J 导出;
  • 各类取证镜像工具可直接从原始簇中读取。

它如何补全 $MFT

把这两者配在一起,会浮现出任何一者单独看不到的规律:

  • 一个你在磁盘上找不到,却出现在 $UsnJrnl 中的文件 —— 在两次快照之间被创建又被删除,但日志保留了痕迹。
  • 勒索软件期间重命名的精确顺序 —— OPENDATA_OVERWRITERENAME_OLD_NAMERENAME_NEW_NAMECLOSE
  • 「被修改」的文件究竟是真被改写,还是只是被触碰了一下 —— $UsnJrnl 的原因掩码可以区分数据覆盖与元数据变更。

在时间线重建中,典型流程是:先遍历 $MFT 拿到现状,再遍历 $UsnJrnl 看清通往现状的变更轨迹。

限制

$UsnJrnl 会循环覆盖。默认大小是 32 MB,在繁忙系统上只够装几天活动。旧事件从末端被丢出。如果你在事件发生后一周以上才介入调查,就要做好出现缺口的心理准备 —— 这时要更多地依靠 $MFT 的 slack 与 $LogFile

外部资源