Lab FTK Imager: file carving using the MFT

NTFS uses the MFT as a kind of database to keep track of files. We can use the MFT to find the location (cluster) of the file and we can carve the file in order to study it. Let's use FTK Imager to see how it works. 

I have searched for a keyword (in this case: "question") and I have found a record in the MFT:

 

It looks like the MFT record belongs to a Gif image. Now, I want to carve the specific image and, in order to do so, I want to know the exact starting cluster where the file resides.

I have to start with the MFT record header:

I see the offset of the MFT record header is 127306752

 

I know that each MFT record is always a 1024 bytes long:

127306752 / 1024 = 124323

Now, I know the file identifier (or inode) of the file: 124323

CONTENTS OF THE MFT RECORD

Each MFT record starts with a header (5 bytes)

 

Since Windows XP, the actual MFT record header is 56 bytes:

 
The MFT record header is followed by 10 00 00 00h, which is the start of the standard information section. The 4 bytes after 10 00 00 00 (in this case 60 00 00 00h) tells us the length of this standard information section:

You can use the Hex Value Interpreter of FTK Imager to see the exact length of the section. Just take a look at the left side of the image above. The value of signed integer is 96. This tells us the standard information section is 96 bytes long.

After 96 bytes the File name section starts (30 00 00 00h):

We can see the length of this section, just by selecting the 4 bytes after 30 00 00h (in this case: 78 00 00 00h). The Hex Value Interpreter tells us this section is 120 bytes long.

After the File name section, the data section starts (with 80 00 00 00h). This is a very important section which tells us the exact location of the file on the hard drive.

The four bytes after 80 00 00 00h (in this case 48 00 00 00h) tells us the length of the data section. The Hex Value Interpreter of FTK Imager tells us this section is 72 bytes long. In this data section, we have to look for data runs, which points to the clusters containing the file's data stream.

A data run always starts with 31h and ends with 00h. In this case, we find a data run after 64 bytes:

31 = marker for the data run
01 = cluster length (in this case: 1 cluster)

Because of the fact most Windows XP computers work with little endian, we have to turn the last three bytes of the data run around:

 

3E EC 7B becomes 7B EC 3E

We can convert this hex value to a decimal value with the help of Windows calculator:

 
 

After this conversion we know this:

The file we're looking for starts in cluster 8121406 and the length of the file is 1 cluster. FTK Imager's Properties tab tells us one cluster is 4096 bytes. So, now we can go to cluster 8121406 and save the contents of 4096 bytes to a file:

Select 4096 bytes and use the right mouse button to save the selection to a file

I save the selection to a file named question.gif

Now, I can easily open the file with Windows explorer and see the result:

 

There's far more to tell about the MFT, but I thought this was a nice start. Please let me know if you have any questions or comments.

Comments

[Ken Pryor]

Excellent post! I learned a lot from this. It's very timely for me, as I've been learning about NTFS and the MFT recently in a course I'm taking. Keep up the good work and thanks!
KP

[Mark]

You're welcome Ken ! Let me know if I can help you with other things regarding NTFS and MFT, Mark

[troy]

31h is not a marker for a cluster run. This number describes the cluster run, and can be other values than 31.

[James]

Thought I would expand on Troy's post. 31h is not a marker for the cluster run. However, if you go to offset 32(decimal)within the $DATA attribute and convert the two byte value, this will give you the decimal offset to the cluster run in decimal. So, in the above example the value at offset 32 is 0x40 00. Convert this (little endian of course) to decimal and you get 64. Go to byte 64 from the beginning of the $DATA attribute and you have the first part of the cluster run.

[Hyip Monitor]

Very nice article thanks for sharing this info.