Hi -,
My goal is to use the following attributes to enumerate all of the nodes belonging to this paticular record (MFT#5) by hand. All attributes came from the (MFT#5) record and are in order. I cannot figure out
How do I interpret MFT attribute (0x90) $INDEX_ROOT in general?
0C0001520 -- -- -- -- -- -- -- -- 90 00 00 00 58 00 00 00 1 }ù X
0C0001530 00 04 18 00 00 00 06 00 38 00 00 00 20 00 00 00 8
0C0001540 24 00 49 00 33 00 30 00 30 00 00 00 01 00 00 00 $ I 3 0 0
0C0001550 00 10 00 00 01 00 00 00 10 00 00 00 28 00 00 00 (
0C0001560 28 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 (
0C0001570 18 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
And, how do I interpret MFT attribute (0xA0) Index Allocation? Will it point to an INDX or to the MFT records of each node or something else?
0C0001580 A0 00 00 00 50 00 00 00 01 04 40 00 00 00 08 00 P @
0C0001590 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0C00015A0 48 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 H
0C00015B0 00 10 00 00 00 00 00 00 00 10 00 00 00 00 00 00
0C00015C0 24 00 49 00 33 00 30 00 31 01 7C F9 1F 00 00 00 $ I 3 0 1 |ù
Lastly, how do I interpet the MFT attribute (0xB0) $Bitmap in order to determine if the nodes decribed above are allocated?
0C00015D0 B0 00 00 00 28 00 00 00 00 04 18 00 00 00 07 00 ° (
0C00015E0 08 00 00 00 20 00 00 00 24 00 49 00 33 00 30 00 $ I 3 0
0C00015F0 01 00 00 00 00 00 00 00 FF FF FF FF 00 00 13 00 ÿÿÿÿ
0C0001600 00 10 00 00 00 00 00 00 24 00 49 00 33 00 30 00 $ I 3 0
0C0001610 31 01 7C F9 1F 00 00 00 B0 00 00 00 28 00 00 00 1 |ù ° (
0C0001620 00 04 18 00 00 00 07 00 08 00 00 00 20 00 00 00
0C0001630 24 00 49 00 33 00 30 00 01 00 00 00 00 00 00 00 $ I 3 0
0C0001640 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ÿÿÿÿ
0C0001650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Thanks.
Have a look at http//
H
Thanks very much. It is like a datasheet for NTFS, this will certainly come in handy. Much appreciated.
So, the MFT is a bit crazy. I am trying to make some sense out of the INDX records, and just when I thought I had it, it seems to deviate from its own standard. Meaning, some index entries are without a VCN and a Size. I worked past this, by adding 8 to the offset until I read the entry id (i.e., 0x05 in this case), then I check my results against the actual directory in Windows and I notice some files were missing. I check the INDX and realize that not all files/folders are represented in that one INDX and that there are more INDX records to read that even echo entries already represented in the previous INDX!! Thus, arise three more questions
01. In the MFT record, does the Index Root or Allocation attribute describe how many INDX records there will be? Is it a total size given? Total Size/4096=INDX Count?
02. Is it normal to have INDX entries without the VCN and Size (First 16B)? If so, why? If one were to run through it using code, it would halt the procedure, unless you detect the craziness and skip ahead by 8… that seems a bit silly, so I must be missing something there.
03. Why does the MFT echo entries in separate INDX records belonging to the same Index? It seems like a waste of space.
Thanks
Well, I have managed to derive an answer for question number 1, and I digress interest in question number 3; yet still, question number 2 does still interest me and continues to baffle me immensely. Any ideas?
Well, I have managed to derive an answer for question number 1, and I digress interest in question number 3; yet still, question number 2 does still interest me and continues to baffle me immensely. Any ideas?
I'm not entirely sure whether it is usual to have a 00h value in the ending VCN (it does seem reasonable for a starting VCN) but my thoughts are that both VCN values likely hold little of forensic value in any event, given that we should be more interested in the physical disk location.
Oh thank you, I need to correct that what I am talking about isn't a VCN, but is actually the MFT reference number. I use it to find the VCN and from that the PSN of the MFT record, from there I have it all. The Size value is used to determine the size of the node in INDX (i.e., 0x68 bytes) used for finding the start of the next node entry in the INDX list. It is cumbersome to work with the INDX list once you come across an entry without a size value, and it is worthless to lack the MFT reference number. The node entry could be of any size (based on the size of the name) and without knowing its MFT reference number, one could never locate its MFT record. I also found one entry (which was a duplicate entry) whose name was misspelled, yet was considered "in-use". I must be missing something. Any ideas?
This is to end the thread and to dump a few jewels for preservation.
01. The entries without a MFT Record Number and Size should be considered deleted, not "in-use". Skip over these records using the name size.
02. The entries which are misspelled should be ignored, made invalid once a character less than 0x21 appears.
03. Entries which are duplicates. I haven't really figured out what to do with these, except I take the first one I see and ignore the rest. Each duplicate could have a separate MFT record, and in that record might reveal its state.
Thanks