Hi,
What is the formula for calculating the physical sector of the final MFT record listed in the MFT? I thought since each record is 1024 bytes, that
MFT_SIZE\1024==NUM_OF_PHY_SECTORS_IN_MFT
But, that doesn't seem to work as I begin to read in the non-resident $DATA portions of the disk, so I tried
(MFT_SIZE\1024)\8)==NUM_OF_PHY_SECTORS_IN_MFT
*Using division by 8 because that is how many sectors per track I have, but using this figure stops really short of the last record.
Thanks
It's not actually that easy.
What if your MFT is fragmented? There could be for example 10 million bytes between the segments of MFT…
If you were to process the MFT entry within the MFT and calculate it's cluster runs, you would get it's cluster runs. Do the maths with that and you'll know how many sectors there are, how many clusters and where each segment starts and stops.
HTH.
Right! I don't know why I didn't think of that. I keep forgetting that the MFT has its own record/attributes. Thanks
Hi,
I am having issues figuring this out, here is the data runs
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 ϸBÙîÿÿÿÿ
How would I use these to figure out the end of the MFT? None of these values jive with what WinHex is showing me. Should be about PSN 78733838 or cluster 9841721. Thanks
I have just finished my degree project which was to read data from an NTFS volume in an image. The cluster run list is read like so
1st byte explains how the next few bytes are arranged
lower 4 bits = number of bytes to read for run length
upper 4 bits = number of bytes to read for the logical cluster number (LCN)
so "31" = read 1 byte for run length and 3 bytes for LCN
31 01 FF FF 0B
Run length = 01
LCN = 0B FF FF
I got this info from File System Forensic Analysis book by Brian Carrier - it is very good and explains pretty much all you need to know.
Also in the attribute you could extract the start and end virtual cluster numbers (then you would not need to look at cluster runs). Maybe you could find out the length by looking at these values.
OK, I have it finally. Here is how to do it
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 À2 2þe
Here is the $DATA attribute (0x80). We skip down (0x40) from the beginning and land on 0x32.
0x03 = Three bytes for cluster number
0x02 = Two bytes for cluster count
We then read in the next 5 bytes.
We get 0x65FE //cluster count
We get 0x0C0000 //cluster number
Now for the math.
0x65FE = 26110
0x0C0000 = 786432
NTFS_MFT_END = (786432+26110)*8
NTFS_MFT_END = 6500336
And, that is correct. Verified by WinHex. Thanks for the help.
You are missing a few points out from your calculation
1) For the final physical sector you need to know the starting sector of the NTFS partition. For a single partition drive, this is normally 0x3F
2) The length of the $MFT file in this case is 0x832c000 bytes, or 0x832C clusters. You have only calculated the first 0x65FE clusters. ie the $MFT is fragmented
3) You have assumed a cluster is 8 sectors - this is almost always the case, but it can be any multiple of 2, ie 2, 4,8,16 sectors
4) You need to display more of the 0x80 attribute to allow one to calculate the final sector
5) It is much easier to 'think' in hex. For instance, cluster 0xc0000 becomes sector 0x600000 plus start of partition. 0x60003f is much easier to recognise and remember than 6291519
I'm sorry, I think I might have called an apple an orange in this case. I meant that I wanted to find the PSN of the last *record* in the MFT, not it's physical end. And, you're right about the 63, sorry about that.
No, I used 8 because that was what I had read from the MBR. I am of course doing this programmatically. I probably should have used a variable instead of an actual value in my explanation, good point.
You still need to allow for the multiple fragments. A data run will be terminated by 0x00 rather than a length and offset length indicator byte.
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.