Search code examples
hexreverse-engineeringntfs

Invalid INDX entries for $I30 on NTFS harddisk

While parsing my NTFS formatted hard disk, I found some invalid entries of INDX while Windows is still able to list all the root directory contents!

The structure of the Index Record in NTFS 3.1 is clear (NTFS doc):

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

However, I found some entries where their size is faulty as well as their MFT Reference (which is a bunch of zeros)!

I enclose a screenshot that shows a part of INDX along side with their text representations where each line is of width 0x20. I highlighted the faulty part.

The invalid entries of INDX

The figure shows that entries were parsed rationally until the last correct entry at 0x0628:

  • MFT Reference (8 bytes): 66 30 00 00 00 00 01 00
  • Size of entry (2 bytes): 70 00 So the entry ends at 0x0697.

Thereafter, things got weird! Entries at 0x0698:

  • MFT Reference (8 bytes): 00 00 00 00 00 00 00 00 Seems invalid
  • Size of entry (2 bytes): 10 00 Of course invalid because the size is less than the entry structure minimum size that includes the filename at 0x52 for instance.

For me, it seems that "Buziol Games" was a deleted folder on the root directory of the harddisk, I am not sure. Anyway, Windows explorer is not facing troubles on listing the contents.

Do anybody understand how does it work? How do Windows continue parsing?

EDIT: In addition, please find the hex dump as a pure text on pastebin

Solution

  • As files get renamed, added, and deleted, INDX records end up containing unzeroized slack space at their end. Each INDX "page" is always 4096 bytes long, and as files get deleted the B+ tree nodes get shifted, leaving old, abandoned nodes at the end of INDX pages. This is very useful for forensics.

    The "Buziol Games" entry appears to be a perfectly valid INDX record. Why do you think it was deleted?

    Note that the INDX header (right where the "INDX" string is) can tell you how many entries there are in the page - check out offset 0x1c (size of index entries) vs offset 0x20 (allocated size of index entries). And note that these are relative to offset 0x18.

    So looking at your pastebin output, in offset 0x1c we find the value 0x690 which means that the last entry ends at 0x18 + 0x690 = 0x6A8. The entry you see at offset 0x698 seems to be a kind of "null" entry, as per 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))

    Note thst its size is 0x10 which means it ends at 0x6A8, as expected.

    See also https://www.fireeye.com/blog/threat-research/2012/10/incident-response-ntfs-indx-buffers-part-4-br-internal.html.

    A good description of NTFS can be found at http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf.