代码之家 › 专栏 › 技术社区 › ÙØÙØ¯ Ø¬Ø¹ÙØ± ÙØ¹ÙØ©

NTFS硬盘上$I30的INDX条目无效

ntfs reverse-engineering hex

ÙØÙØ¯ Ø¬Ø¹ÙØ± ÙØ¹ÙØ© · 技术社区 · 7 年前

Offset      Description
-------------------------------------
0x00        MFT Reference of the file
0x08        Size of the index entry
0x0A        Offset to the filename
...
0x52        Filename
...

然而,我发现一些条目的大小有问题,以及它们的MFT引用(这是一堆零)!

0x20 .我强调了故障部分。

0x0628 :

MFT参考(8字节): 66 30 00 00 00 00 01 00
条目大小(2字节): 70 00 因此条目结束于 0x0697

之后,事情变得很奇怪!条目位于 0x0698 :

MFT参考(8字节): 00 00 00 00 00 00 00 00
条目大小(2字节): 10 00 当然无效,因为大小小于包含文件名的条目结构最小大小 0x52

对我来说,“Buziol Games”似乎是硬盘根目录上删除的文件夹,我不确定。无论如何,Windows资源管理器在列出内容时不会遇到麻烦。

有人知道它是怎么工作的吗?Windows如何继续解析?

编辑 :此外,请在上找到纯文本形式的十六进制转储 pastebin

1 回复 | 直到 7 年前

YSK 7 年前

当文件被重命名、添加和删除时,INDX记录的末尾包含未归零的空闲空间。每个INDX“页面”总是4096字节长,当文件被删除时,B+树节点被移动,在INDX页面的末尾留下旧的、被遗弃的节点。这对取证非常有用。

请注意,INDX标头(INDX字符串的右侧)可以告诉您页面中有多少个条目-签出偏移量0x1c(索引项的大小)与偏移量0x20(索引项的分配大小)。注意,这些是相对于偏移量0x18的。

因此,看看你的pastebin输出,在偏移量0x1c中,我们发现值0x690,这意味着最后一个条目结束于0x18+0x690=0x6A8。你在偏移量0x698处看到的条目似乎是一种“null”条目,根据 https://0cch.com/ntfsdoc/concepts/index_record.html :

last entry has a size of 0x10 (just large enough for the flags (and a mft ref of zero))

注:它的大小是0x10,这意味着它结束于0x6A8,正如预期的那样。

另请参见 https://www.fireeye.com/blog/threat-research/2012/10/incident-response-ntfs-indx-buffers-part-4-br-internal.html

有关NTFS的详细说明,请访问 http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf