Hi.
01. How can one by examining the MFT determine how big the MFT is? Is there a set of bits in the $MFT somewhere that denotes the size of the MFT?
02. How do you determine the address of a non-resident file's $DATA? I think it is by finding its sequence number + the entry address, but I am not sure about the offsets for which to find the entry address.
Basically, I want to know how to determine the size of the MFT and how to find the address of a file's data portion via its MFT entry.
Thanks guys.
Hi Newwave,
1. $MFT has a record for itself. It is record #0. Since it describes the MFT, you can tell how large it is in the same way you would for any other file.
Which leads into ….
2. I'm not sure what $DATA is, but the 0x80 attribute contains data runs. If you decode these, you will know the start (and in fact every cluster) of the file.
HTH.
In the 0x80 chunk, do you happen to know the offset and how many bits it makes up describing the lcns of the file's non-resident data?
One more question please. I was wondering for the size of a file as described in the MFT entries, how many bits make up that values (i.e., 2, 4, 8, 16, 32, etc).
Also, it appears that the size of files are stored using the KB value, is this the same as the MFT size? Should I be decoding the MFT size and interpreting it as a KB value?
In terms of the size of the $MFT WinHex says the MFT is 131 MB in size, so where in this . . .
0000 46 49 4C 45 2A 00 03 00 40 BA 00 B6 00 00 00 00
0010 01 00 01 00 30 00 01 00 D0 01 00 00 00 04 00 00
0020 00 00 00 00 00 00 00 00 04 00 0D 02 00 00 00 00
0030 10 00 00 00 60 00 00 00 00 00 18 00 00 00 00 00
0040 48 00 00 00 18 00 00 00 40 F6 68 6F 04 F4 C8 01
0050 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01
0060 40 F6 68 6F 04 F4 C8 01 06 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 30 00 00 00 68 00 00 00 00 00 18 00 00 00 01 00
00A0 4A 00 00 00 18 00 01 00 05 00 00 00 00 00 05 00
00B0 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01
00C0 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01
00D0 00 00 C8 00 00 00 00 00 00 00 C8 00 00 00 00 00
00E0 06 00 00 00 00 00 00 00 04 03 24 00 4D 00 46 00
00F0 54 00 00 00 00 00 00 00 80 00 00 00 70 00 00 00
0100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00
0110 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
0130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
0140 01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86
0150 32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B
0160 94 02 00 00 00 00 00 00 B0 00 00 00 60 00 00 00
0170 01 00 40 00 00 00 03 00 00 00 00 00 00 00 00 00
0180 04 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0190 00 50 00 00 00 00 00 00 98 41 00 00 00 00 00 00
01A0 98 41 00 00 00 00 00 00 31 01 FF FF 0B 21 01 28
01B0 8A 31 01 B9 8A 55 31 01 69 36 04 31 01 5E 8E A1
01C0 00 00 10 CF B8 42 D9 EE FF FF FF FF 00 00 00 00
01D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0D 02
. . . would that size be denoted exactly? thanks
First things first…..here is the 0x80 attribute from your post
80 00 00 00 70 00 00 00
0100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00
0110 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
0130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
0140 01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86
0150 32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B
0160 94 02 00 00 00 00 00 00
Sorry, my cut and paste isn't as pretty as the original. In NTFS, many things are variable length. So, it isn't as easy as saying "go to offset XX and read XX bytes". From the beginning of the 0x80 shown above, go 32 bytes and read 2 bytes. This hex value tells the offset of the data runs (in your case 0x40 …..4 lines….or 64 bytes). So, go to offset 64 (from the beginning of the 0x80) to find the data runs themselves.
Reading the data runs is also complicated as they are variable size and the number of them depends on how fragmented the file is. Each data run contains a relative starting cluster number and the number of clusters in the run. I don't have time to do a whole explanation now…..off to vacation early tomorrow. I hope this gets you started.
To calculate size, go to the 0x80 attribute and using the data runs, count how many clusters are used for the file content. Then, multiply this number by the number of bytes per cluster (usually 4 KB, but variable).
HTH…..
Wow, that posted even uglier than I thought……this one has no row numbers….might make it easier.
80 00 00 00 70 00 00 00
01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00
2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86
32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B
94 02 00 00 00 00 00 00 B0 00 00 00 60 00 00 00
01 00 40 00 00 00 03 00 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00 50 00 00 00 00 00 00 98 41 00 00 00 00 00 00
98 41 00 00 00 00 00 00 31 01 FF FF 0B 21 01 28
8A 31 01 B9 8A 55 31 01 69 36 04 31 01 5E 8E A1
00 00 10 CF B8 42 D9 EE FF FF FF FF 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 0D 02
Use [ /code ] without the spaces between the square brackets to line up your soldiers.
OK, so here is the 0x80 chunk broken down.
00F0 54 00 00 00 00 00 00 00
The start of 0x80 chunk . . .
80 00 00 00 70 00 00 00
0100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00
0110 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
0130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
Here are the data runs, I think. . .
0140 01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86
0150 32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B
0160 94 02
Here is the end of the 0x80 chunk.
00 00 00 00 00 00
So, from what I could gather I am supposed to count these values, so I count 34 which can't be right because (4096 * 34) / 1024 = 136 MB.
If I count just 32 we get, (4096 * 32) / 1024 = 128 MB which is closer, but still not 131 MB. Am I supposed to decode these values then add them up or literally count them? Sorry for bothering you so much about this.
wait a second, I think I figured it out
80 00 00 00 70 00 00 00
0100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00
0110 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
0130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
From 0x80 you skip 16 bits, then 32 bits, then 2 bits and the offset 0x111 denotes in MB the size of the $MFT. So
80 00 00 00 70 00 00 00 <– skip this (16 bits)
0100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00 <– skip this (32 bits)
0110 2B <– skip this (2 bits)83 <– decode this (0x83 == 131)
00 00 00 00 00 00 40 00 00 00 00 00 00 00
0120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00
0130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12
However, I am still not sure if I can rely on this as it wasn't derived the way you mentioned.
The length of the MFT file is given in bytes and is 0x832c000 or 137,543,680 bytes approx 131MB
The data run strings start at offset 0x40 so the first one is
The length of the MFT file is given in bytes and is 0x832c000 or 137,543,680 bytes approx 131MB
The data run strings start at offset 0x40 so the first one is
0x65fe clusters starting at cluster 0xc0000 - very common starting place
Michael