Hi,
Would that total clusters you gave cover the entire MFT, as in would it provide where the last record is; taking in account the fragmented $DATA in between records? Or would that count be translated as the total of records minus the $DATA in between them?
mscotgrove's notes are exactly right.
One other thing to keep in mind, since it hadn't been addressed is that $MFT records are *not* guaranteed to be 1024 bytes long. Microsoft acknowledges this, and though they are nearly always 1024B in length, if you're a perfectionist and have a few extra computing cycles, you should verify you're working with the typical record length.
An MFT entry will not be greater than 1024 bytes. An entries contents might be less than 1024 in length, however the next MFT entry will start at byte 1025 after the start of the previous record.
If an entry requires more than 1024 bytes, the additional data will be stored in a new MFT record (known as a non base entry). An attribute list in the original record (the base entry) will point to the non base MFT entry.
Newwave,
I am not entirely sure by what you are refering to with the $DATA comment. The $MFT is a file with a size. The location of each cluster is dependant on the data run information (attribute 0x80). The final physical sector has no arithmetic relationship to the start of the $MFT when the file is fragmented. ie the data run information is essential.
Most $MFTs I see have a few fragments, typically 3 to 10.
OIC. Thank you. So, in terms of parsing the individual records and avoiding the fragmented areas, finding the last record, etc… the actual size of the MFT is irrelevant? What could I be using the actual MFT size for, programmatically, when the MFT is fragmented?
On the side-topic of MFT record sizes,
An MFT entry will not be greater than 1024 bytes. An entries contents might be less than 1024 in length, however the next MFT entry will start at byte 1025 after the start of the previous record.
…from the classical standpoint of looking at the $MFT file as nothing more than a database, an entry greater than 1024B is still a singular entry; everything past the 1024th byte uses a distinct subset of the "base entry" attribute parsers. For instance, you'll find $STANDARD_INFORMATION and $FILE_NAME are missing (so technically, no, this is not a separate record as the isolated bytes at [1025-(end record)] do not conform to Microsoft's entry standards; but you are correct, the non-base entries do have distinct, linking IDs). If anyone is interested,
http//
Now if you want to call the subset of bytes [1025-(end)] a separate entry, we're just getting into semantics. My point is to show that "1024" should not be hard-coded into a calculation if it can be avoided; an oversight of useful data may occur.
in terms of parsing the individual records and avoiding the fragmented areas
When you parse the $MFT file, you will not need to worry about fragmentation or data runs (ie where the fragmented portions of the file reside). All high-level programming languages will default to a bytestream-read, that is, you'll see the file as a single stream.
Now if you are addressing the actual clusters of the $MFT file to do your parsing, you should just Google for the necessary code, because there is no reason to need to access the $MFT file in this manner.
I'm doing this from outside the host OS, so no API. Unless I write it myself.
mscotgrove, I am looking at the MFT and I am seeing something weird
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
3221225712 80 00 00 00 70 00 00 00 € p
3221225728 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00 @
3221225744 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00 +ƒ @
3221225760 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00 À2 À2
3221225776 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12 À2 2þe 2
3221225792 01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86 Ä» 2 B|2œ z†
3221225808 32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B 2, $5 2A ³É|2û
3221225824 94 02 00 00 00 00 00 00 B0 00 00 00 60 00 00 00 ” ° `
3221225840 01 00 40 00 00 00 03 00 00 00 00 00 00 00 00 00 @
3221225856 04 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 @
3221225872 00 50 00 00 00 00 00 00 98 41 00 00 00 00 00 00 P ˜A
3221225888 98 41 00 00 00 00 00 00 31 01 FF FF 0B 21 01 28 ˜A 1 ÿÿ ! (
3221225904 8A 31 01 B9 8A 55 31 01 69 36 04 31 01 5E 8E A1 Š1 ¹ŠU1 i6 1 ^Ž¡
3221225920 00 00 10 CF B8 42 D9 EE FF FF FF FF 00 00 ϸBÙîÿÿÿÿ
Paticulary, this portion
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
3221225888 31 01 FF FF 0B 21 01 28 1 ÿÿ ! (
3221225904 8A 31 01 B9 8A 55 31 01 69 36 04 31 01 5E 8E A1 Š1 ¹ŠU1 i6 1 ^Ž¡
3221225920 00 00 10 CF B8 42 D9 EE FF FF FF FF 00 00 ϸBÙîÿÿÿÿ
Where does the data runs end? Is it before this part directly above or after it?
The attribute type 0x80 is where data runs are stored. This has a length of 0x70, and so this attribute ends at location 3221225832
The data runs are
Length 0x65ff Cluster 0xc0000
Length 0x112 Relative cluster 0x5bbc4
Length 0x218 Relative cluster 0x7c421f
etc
The terminator is at location 3221225826 where the value for length and offset elngths is zero
The second attribute you show is type 0xb0, length 0x60. This is bitmap attribute and nothing to do with the locations of the physical sectors of the $MFT
Well, then I guess I was doing it right, unless I am still missing something. I manually navigated to those locations I was getting from the Record(0) and
01. The first address+cluster_size (0xC65FE) actually took me to the end of a MFT record and the start of some non-resident data area.
02. The second address+cluster_size (0x5BCD6) takes me to free space.
03. The third address+cluster_size (0x7C4437) takes me to the start of some more non-resident data.
etc… all taking me to different regions of free space or data regions. Only the ((0xC0000+0x65FE)*8)+63 actually provides the proper results that I am after. But, you have made it so convincing that I am still missing records, so what am I still doing wrong? thanks
01 sounds correct. Non resident data is part of the $MFT file. Such records can be anywere in the $MFT and reused when free. The address 0xc65fe*8+0x3f will be the end of the first fragment of the $MFT
02 - you miss a very critical point on cluster runs. The cluster number after the first one is a relative cluster, relative to the previous run. It may be possitive or negative and is done this way to be as efficent as possible with the limited space for data runs. I think it is relative to the start of the previous run (though could be the end of the previous run, i'd need to check this point) so the second fragment would be at
(0xc0000 + 0x5bbc4)*8 + 0x3f