NTFS 硬盘上 $I30 的无效索引条目
Invalid INDX entries for $I30 on NTFS harddisk
在解析我的 NTFS 格式的硬盘时，我发现了一些无效的 INDX 条目，而 Windows 仍然能够列出所有的根目录内容！
NTFS 3.1中Index Record的结构清晰(NTFS doc):
Offset Description
-------------------------------------
0x00 MFT Reference of the file
0x08 Size of the index entry
0x0A Offset to the filename
...
0x52 Filename
...
但是，我发现一些条目的大小以及它们的 MFT 参考（是一堆零）都是错误的！
我附上了一张屏幕截图，其中显示了 INDX 的一部分及其文本表示，其中每行的宽度为 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
上找到纯文本形式的十六进制转储
随着文件被重命名、添加和删除，INDX 记录最终在其末尾包含未归零的松弛 space。每个 INDX "page" 总是 4096 字节长，随着文件被删除，B+ 树节点被移动，在 INDX 页面的末尾留下旧的、废弃的节点。这对取证非常有用。
"Buziol Games" 条目似乎是完全有效的 INDX 记录。你认为它被删除的原因是什么？
请注意，INDX header（就在 "INDX" 字符串所在的位置）可以告诉您页面中有多少条目 - 检查偏移量 0x1c（索引条目的大小）与偏移量0x20（分配的索引条目大小）。并注意这些是相对于偏移量 0x18.
因此查看您的 pastebin 输出，在偏移量 0x1c 中我们找到值 0x690，这意味着最后一个条目结束于 0x18 + 0x690 = 0x6A8。根据 https://0cch.com/ntfsdoc/concepts/index_record.html:
，您在偏移量 0x698 处看到的条目似乎是一种 "null" 条目
last entry has a size of 0x10 (just large enough
for the flags (and a mft ref of zero))
注意它的大小是 0x10，这意味着它结束于 0x6A8，如预期的那样。
可以在 http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf.
找到对 NTFS 的很好的描述
在解析我的 NTFS 格式的硬盘时，我发现了一些无效的 INDX 条目，而 Windows 仍然能够列出所有的根目录内容！
NTFS 3.1中Index Record的结构清晰(NTFS doc):
Offset Description
-------------------------------------
0x00 MFT Reference of the file
0x08 Size of the index entry
0x0A Offset to the filename
...
0x52 Filename
...
但是，我发现一些条目的大小以及它们的 MFT 参考（是一堆零）都是错误的！
我附上了一张屏幕截图，其中显示了 INDX 的一部分及其文本表示，其中每行的宽度为 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
上找到纯文本形式的十六进制转储随着文件被重命名、添加和删除，INDX 记录最终在其末尾包含未归零的松弛 space。每个 INDX "page" 总是 4096 字节长，随着文件被删除，B+ 树节点被移动，在 INDX 页面的末尾留下旧的、废弃的节点。这对取证非常有用。
"Buziol Games" 条目似乎是完全有效的 INDX 记录。你认为它被删除的原因是什么？
请注意，INDX header（就在 "INDX" 字符串所在的位置）可以告诉您页面中有多少条目 - 检查偏移量 0x1c（索引条目的大小）与偏移量0x20（分配的索引条目大小）。并注意这些是相对于偏移量 0x18.
因此查看您的 pastebin 输出，在偏移量 0x1c 中我们找到值 0x690，这意味着最后一个条目结束于 0x18 + 0x690 = 0x6A8。根据 https://0cch.com/ntfsdoc/concepts/index_record.html:
，您在偏移量 0x698 处看到的条目似乎是一种 "null" 条目last entry has a size of 0x10 (just large enough
for the flags (and a mft ref of zero))
注意它的大小是 0x10，这意味着它结束于 0x6A8，如预期的那样。
可以在 http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf.
找到对 NTFS 的很好的描述