Please help: learning how NTFS $MFT $DATA attribute works.

[Michael.Reilly]

Hi there, I have a bit of a situation with a drive that had been partially overwritten. I still have most of the File Records from the drive but it seems that the original boot sector was overwritten and I don't know the offset of where to put it back. (And the software I'm using will not honor the existence of a former partition unless one exists it seems.) I have located several $MFTMirr Records in hex, and I'm trying to determine which one was the old one. I was trying to figure it out by examining the $MFTMirr record for the $MFT to figure out where the original $MFT is, and from there find the offset.

I've been researching a bit, and while I've determined where the unnamed $DATA attribute is, the length I'm getting for the Attribute is over 50MB (00 00 0C 03 00 00 00 00) and I haven't been able to determine an offset using this. $MFTMirr has a still larger than expected but more reasonable 64k (00 00 01 00 00 00 00 00.)

How would one determine the offset of a data stream from the on disk layout?

Is there any material online or in book for that would assist me in figuring this out?

In specific the $MFT Record I'm looking at looks like this (from offset 0x100 where the $DATA Record begins):

Code:

80 00 00 00 50 00 00 00  01 00 40 00 00 00 01 00
00 00 00 00 00 00 00 00  BF 30 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 00 0C 03 00 00 00 00
00 00 0C 03 00 00 00 00  00 00 0C 03 00 00 00 00

Beginning of record datastream
(my documentation doesn't cover what this part means:)

32 C0 28 00 00 0C 32 00  08 17 73 13 00 A0 A5 8D
B0 00 00 00 50 00 00 00  01 00 40 00 00 00 05 00
00 00 00 00 00 00 00 00  02 00 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 30 00 00 00 00 00 00
08 20 00 00 00 00 00 00  08 20 00 00 00 00 00 00
31 01 FF FF 0B 31 02 63  5B F7 00 00 00 70 A4 8D
FF FF FF FF 00 00 00 00  31 40 00 00 0C 00 50 8F
B0 00 00 00 50 00 00 00  01 00 40 00 00 00 05 00
00 00 00 00 00 00 00 00  00 20 00 00 00 00 00 00
08 10 00 00 00 00 00 00  08 10 00 00 00 00 00 00
31 01 FF FF 0B 11 01 FF  FF 00 00 01 00 10 48 00

End of sector

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
* (Repeated lines all empty)
00 00 00 00 00 00 00 00  00 00 00 00 00 00 48 00

End of sector

[Russwinters]

boot sector for NTFS i usually sector 63

[Michael.Reilly]

It's not in this situation, the drive previously had a recovery partition at the beginning of the drive. Now it no longer does.

[Russwinters]

find the start of the boot partition, and navigate 63 sectors from the start?

Unless the boot code was modified the boot sector for a windows system should always be located at both the 0 sector for the start of the partition, and the 63rd.

This isn't my "best" area of expertise though, so I *could* be wrong, just throwing some ideas out there for you to check.

[Doomer]

The second boot sector copy located at the end of the volume. It will give you exact location of the first copy

[dobrevjetser]

The book "File system forensic analysis" could help.

Dobre

[Michael.Reilly]

The second boot sector copy located at the end of the volume. It will give you exact location of the first copy

It's been overwritten.

The book "File system forensic analysis" could help.

Dobre

Thank you, I'll look into it.

[Michael.Reilly]

Thank you for your assistance, between http://www.tom.womack.net/projects/ntfs-notes.html and http://kcrazy.timeegg.com/Favorites/ntf ... ute_header and File System Forensic Analysis (my coworker happened to have a copy) I now understand that I'm looking at a runlist and how they work.

[xsoliman]

As you have already worked out, the numbers are the encoded data cluster infomation (data runs)
as briefly mentioned on P747 of Windows Internals 4th edition
The entries are variable lenght (starting 32 means 2 byte length, 3 byte start position)

The dat just above here gives the data length = 030c0000

The data cluster runs are

32 C0 28 00 00 0C 32 00 08 17 73 13 00

(vcn 0), lcn cluster 0c0000, length 28c0
(vcn 28c0), lcn 137317 length 0800
00 terminator
so end is just before vcn 28c0+0800 = 30c0 which matches the 30c0000 data length in bytes
ie 2 largish data runs, as expected