MFT Data Runs

Your first cluster run data is

21 02 EF 07

This means that the first run is 2 clusters in length

The first cluster is cluster 0x7EF

To get the sector number you must multiply the clsuter number by sectors per cluster. In this case, as I think the file is compressed the cluster size will be 8. This gives a sector number of 0x3f78

You now need to add the starting cluster of the partition you are on, it does not look like the first partition. The partition may well start at sector 0x2d 42c4

The next part of the data run is 01 0E This is padding due to the compresed data.

I hope this is correct. From my recollection the data runs are located as follows;

The data run information is located in the $Data attribute.
The header for the $Data attribute is 80 00 00 00 (located at offset 000027904 in your example).
The following four bytes are the Attribute size (50 00 00 00). This in little endian = 80 bytes this is the length of the attribute.
The next byte at 00027912 is 01 which indicates data is NON RESIDENT so data runs as you have identified.
The bytes from offset 32 of the $Data attribute identify the location of the data run. In your example I believe it is the hex string 48 00 = 72 bytes in decimal.
72 bytes from start of $Data attribute is hex21 this firstly identifies the size of the data run information i.e.2 +1 =3, so the following 3 bytes are to be used to identify the location and length of the data, namely 02 EF 07.
02 = length of data i.e. 2 x clusters
EF 07 = starting logical cluster 2031

Cheers DK

I'm sorry. I am not coming up with the right numbers. OK, so I

01. Take 0x7EF which is in decimal form 2031
02. I multiply that number by 8 2031 * 8 = 0x3F78 or 16248

Here is where it starts getting fuzzy . . .

03. I add that value to the cluster I am on which is 786439 (lcn) or 6291573 (psn), so 786439 + 16248 = 802687 (lcn) or . . .

conversion to PSN

(802687 * 8) + 63 = 6421559 psn

So we have

LCN 802687
PSN 6421559

We are supposed to have (per WinHex) . . .

LCN 2982460
PSN 23859743

It calculated when I used your example start (0x2d42c4), but I am not sure how to find that out. Any idea?

I cheated, and calculated the start of the partition (0x2d42c4) from the the expected value, and the cluster of the file 0x7ef * 8

To determine the partition start, you need to go the entry for $MFT. This is in the first MFT, should be 0x1b x 2 sectors earlier. The number of your MFT is in position 0x2c, ie 0x1b. Each MFT is 2 sectors long.

When you find MFT 0, with SMFT in the name you want to look at the start of the MFT run. It may well be cluster 0xc0000, which is reference it itself. You can then work out the sector number of the start of the partition

I figured you guessed it. lol

Well I have that sector number and it is (786432 * 8) + 63 = 6291519

but that isn't 2966212 or 0x2d42c4

How do I figure that number out using 6291519? If I take

2031 * 8 = 16248 + 2966212 that does equal out to the right LCN 2982460, but only that number does so, however, if I use that same number on a different record, the math does not work anymore. I have a feeling that something is missing or that I am not truly understanding this concept.

I looked at the $MFT record (#0) and it does indeed start at 0xC0000, but that value is not working in my computations either. Are the data runs simply an offset from the start of the $MFT? I don't think that can be true, the math just doesn't add up.

Here is the first record in $MFT


Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

0C0000000 46 49 4C 45 2A 00 03 00 40 BA 00 B6 00 00 00 00 FILE* @º ¶
0C0000010 01 00 01 00 30 00 01 00 D0 01 00 00 00 04 00 00 0 Ð
0C0000020 00 00 00 00 00 00 00 00 04 00 0D 02 00 00 00 00
0C0000030 10 00 00 00 60 00 00 00 00 00 18 00 00 00 00 00 `
0C0000040 48 00 00 00 18 00 00 00 40 F6 68 6F 04 F4 C8 01 H @öho ôÈ
0C0000050 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01 @öho ôÈ @öho ôÈ
0C0000060 40 F6 68 6F 04 F4 C8 01 06 00 00 00 00 00 00 00 @öho ôÈ
0C0000070 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
0C0000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0C0000090 30 00 00 00 68 00 00 00 00 00 18 00 00 00 01 00 0 h
0C00000A0 4A 00 00 00 18 00 01 00 05 00 00 00 00 00 05 00 J
0C00000B0 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01 @öho ôÈ @öho ôÈ
0C00000C0 40 F6 68 6F 04 F4 C8 01 40 F6 68 6F 04 F4 C8 01 @öho ôÈ @öho ôÈ
0C00000D0 00 00 C8 00 00 00 00 00 00 00 C8 00 00 00 00 00 È È
0C00000E0 06 00 00 00 00 00 00 00 04 03 24 00 4D 00 46 00 $ M F
0C00000F0 54 00 00 00 00 00 00 00 80 00 00 00 70 00 00 00 T € p
0C0000100 01 00 40 00 00 00 02 00 00 00 00 00 00 00 00 00 @
0C0000110 2B 83 00 00 00 00 00 00 40 00 00 00 00 00 00 00 +ƒ @
0C0000120 00 C0 32 08 00 00 00 00 00 C0 32 08 00 00 00 00 À2 À2
0C0000130 00 C0 32 08 00 00 00 00 32 FE 65 00 00 0C 32 12 À2 2þe 2
0C0000140 01 C4 BB 05 32 18 02 1F 42 7C 32 9C 01 7A 8D 86 Ä» 2 B|2œ z†
0C0000150 32 2C 06 24 35 02 32 41 04 B3 C9 7C 32 FB 0D 0B 2, $5 2A ³É|2û
0C0000160 94 02 00 00 00 00 00 00 B0 00 00 00 60 00 00 00 ” ° `
0C0000170 01 00 40 00 00 00 03 00 00 00 00 00 00 00 00 00 @
0C0000180 04 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 @
0C0000190 00 50 00 00 00 00 00 00 98 41 00 00 00 00 00 00 P ˜A
0C00001A0 98 41 00 00 00 00 00 00 31 01 FF FF 0B 21 01 28 ˜A 1 ÿÿ ! (
0C00001B0 8A 31 01 B9 8A 55 31 01 69 36 04 31 01 5E 8E A1 Š1 ¹ŠU1 i6 1 ^Ž¡
0C00001C0 00 00 10 CF B8 42 D9 EE FF FF FF FF 00 00 00 00 ϸBÙîÿÿÿÿ
0C00001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0C00001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0C00001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0D 02

Thanks for all your help.

It may be helpful to post a dump of the actual MFT record for the file you cited in your first post. In Winhex's directory browser context menu, select Position and Go To FILE Record. In the run list, the first byte provides address/number_of_clusters, 4 bits each, which reference the bytes that follow. Remember endian-ness.

Lets's assume the run list is 0x2102EF07010E. 0x21 describes the first run. Two bytes for address and one for number of clusters. One byte for number of clusters goes to the next byte, 0x02=2 clusters. Two bytes for address, 0x0xEF07, or Cluster 2,031. Adressing is relative to the preceding address, and can be + or -.

The 0x010E group seems to indicate a sparse file, but i didn't study the entire record. Three virtual clusters.

Thank you, but I understand that part of it. The record I am looking at is #27 of the $MFT and it is the same as I posted above. I know that the address is 2031, but my question is how do I calculate using 2031 the start of the $DATA of that file (in this case; hh.exe)?

I noticed that if I do this (2031 * 256) * 256 = 0x7EF0000, that is probably nothing to do with my goal, but it was interesting.

I just don't understand how one can get an address of 2031 and know that it translates to 2982460 (cluster)? If I could then I could calculate the PSN, LCN, etc… I would also like to note that I am not trying to find this file on disk manually, but instead programmatically so I will need to know how to do the conversions to find the $DATA.

thanks

Perhaps I misunderstand what you're trying to determine. 2031 is the cluster number of the first cluster of the file. I guess I don't know where you're finding 2982460. If the run list is 0x2102EF07010E, then 2982460 is not part of the equation. In the example below, the run list is 0x3101EEC72400. The starting cluster is 2410478 (0xEEC724). The file consumes one cluster.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

0C4B46000 46 49 4C 45 30 00 03 00 4F 59 09 93 00 00 00 00 FILE0 OY “
0C4B46010 10 00 01 00 38 00 01 00 58 01 00 00 00 04 00 00 8 X
0C4B46020 00 00 00 00 00 00 00 00 04 00 00 00 18 2D 01 00 -
0C4B46030 04 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00 `
0C4B46040 00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00 H
0C4B46050 51 3B BD D8 1A 6E C9 01 AD 5F C4 D8 1A 6E C9 01 Q;½Ø nÉ ­_ÄØ nÉ
0C4B46060 AD 5F C4 D8 1A 6E C9 01 39 FE C1 D8 1A 6E C9 01 ­_ÄØ nÉ 9þÁØ nÉ
0C4B46070 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0C4B46080 00 00 00 00 27 03 00 00 00 00 00 00 00 00 00 00 '
0C4B46090 88 92 6D 1B 00 00 00 00 30 00 00 00 70 00 00 00 ˆ’m 0 p
0C4B460A0 00 00 00 00 00 00 02 00 52 00 00 00 18 00 01 00 R
0C4B460B0 B9 0B 00 00 00 00 17 00 51 3B BD D8 1A 6E C9 01 ¹ Q;½Ø nÉ
0C4B460C0 39 FE C1 D8 1A 6E C9 01 39 FE C1 D8 1A 6E C9 01 9þÁØ nÉ 9þÁØ nÉ
0C4B460D0 39 FE C1 D8 1A 6E C9 01 00 00 00 00 00 00 00 00 9þÁØ nÉ
0C4B460E0 00 00 00 00 00 00 00 00 20 20 00 00 00 00 00 00
0C4B460F0 08 03 74 00 65 00 73 00 74 00 2E 00 64 00 61 00 t e s t . d a
0C4B46100 74 00 00 00 00 00 00 00 80 00 00 00 48 00 00 00 t € H
0C4B46110 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00
0C4B46120 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 @
0C4B46130 00 10 00 00 00 00 00 00 DC 05 00 00 00 00 00 00 Ü
0C4B46140 DC 05 00 00 00 00 00 00 31 01 EE C7 24 00 FF FF Ü 1 îÇ$ ÿÿ
0C4B46150 FF FF FF FF 82 79 47 11 00 00 00 ÿÿÿÿ‚yG

Well, then how would you take that number and convert it to the equivalent PSN or LSN?