NTFS MFT Analysis I...
 
Notifications
Clear all

NTFS MFT Analysis Identifying Cluster run

12 Posts
4 Users
0 Likes
2,178 Views
Dermot29
(@dermot29)
Posts: 15
Active Member
Topic starter
 

I am cuurently working on an NTFS analysis of a 249 mb pen drive formatted to ntfs on a windows 8 machine.

The ntfs system I created has 512 bytes per sector, and 1 sector per cluster. I have done a boot sector analysis and everything seems to be making sense.

The problem I am having now is that I cannot identify the cluster run numbers for a jpg file I have on the system.

I know that the data of the file starts in cluster 288 and ends in cluster 304.

What I have in the cluster run doesn't make much sense to me

21 11 20 01 00 00 00 00 FF FF FF FF 82 79 47 11.

except for (0120) = 288 which is the starting sector of the data and (0121) which is the next.

I just need to be able to determine accurately the cluster run numbers that specify the data clusters for the file

288 to 304.

I am also trying to understand why the base mft record is at 170494 and the first data record is at 170564,

70 sectors after. I understand the first 16 entrys are reserved, but it doesn't add up.

I got some stats from active disk editor

2 clusters per file record segment, so I think each mft is 1024 bytes, 2 sectors,
8 clusters per index block, don't know what that is ?

Any help with this would be great, particularly regarding the cluster run numbers

Thanks

 
Posted : 24/04/2014 4:51 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

It's difficult to interpret without seeing the actual data, so in the future would it be possible for you to post the $MFT record in question?

HOWEVER - given what you've mentioned, here are some hopefully helpful pointers.

The first thing to understand is that in the section you posted, not everything is relevant. Here it is


21 11 20 01 00 00 00 00 FF FF FF FF 82 79 47 11

The "FF FF FF FF" indicates the end of the $MFT record - so anything after that we won't consider (it can be useful sometimes, but for the sake of your example we will ignore this "$MFT slack").

So once we remove that, we are left with this - your cluster run itself.


21 11 20 01 00 00 00 00

You state that your file data is from cluster 288 to 304. This means it is 17 clusters long.

Cluster runs in the $MFT define two things; the address of the first cluster, and the length of the continuous bytes (also called contiguous data) after this cluster. The first byte of your example data is "21". This means that in the following cluster run, we will expect "2" bytes to be used for the cluster offset, and "1" byte for number of contiguous clusters.

This is what we now have left

11 20 01 00 00 00 00

The first byte is our expected "number of contiguous clusters". This is "11", which (when converted from hex) is decimal 17. Sound familiar? )
Next we expect there to be "2" bytes used for the address of the first cluster in the run. This is "20 01", or in little endian "01 20" - which is 288 in decimal.

Therefore you now know that your data starts at cluster 288 and runs for 17 clusters. Which is exactly as it is on disk!

For your query regarding when the first data record starts in the $MFT - bear in mind that NTFS uses not just the $MFT but other files too, such as $bitmap. This will be included in the $MFT, which is why records for user-created data may not appear until "later" in the table.

I hope this has been helpful! Once you understand cluster runs you realise it is a very nice and elegant method of doling things - but they can be a bit of a headache at first. )

Edit I have produced possibly the world's ugliest diagram for your cluster run in the hope it might might things clearer. Here it is!

 
Posted : 24/04/2014 6:55 pm
Dermot29
(@dermot29)
Posts: 15
Active Member
Topic starter
 

Thanks Chris. Exactly the explanation I was looking for. I'm feeling a bit stupid because I went over this stuff half a dozen times before I posted. I just failed to read it properly. I was expecting to see each cluster specified in the run. Anyway

Makes perfect sense now. I can finally move on with my analysis

thanks again

BTW, great diagram, I might actually screen grab that for my assignment too

 
Posted : 24/04/2014 7:15 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

You're welcome! Glad it helped.

 
Posted : 24/04/2014 8:31 pm
mscotgrove
(@mscotgrove)
Posts: 934
Prominent Member
 

Dermot - Think in Hex, it will actually make far more sense than decimal

 
Posted : 25/04/2014 3:58 am
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
 

I would say, even binary as we are dealing here with nibbles.

But, man that drawing is hideous! mrgreen

Despite being a Microsoft implementation, one must admit, it is beautiful.
Think about how big a single byte represents. 16-byte-long sized cluster-count, as far as 16-byte-long address away…

 
Posted : 25/04/2014 4:13 am
Dermot29
(@dermot29)
Posts: 15
Active Member
Topic starter
 

Hi again. I got such great advice last time that I have returned for more. I am continuing to look more at Master File Table records, and have been encouraged to find file metadata in the mtf entry itself by my lecturer.

Trouble is I cannot see any metadata in any of the records. Everything I read tells me there should be file metadata in there

I believe there should be metadata stored in the $STANDARD_INFORMATION attribute.

I cannot see anything in the data area of my hex editor, only the file name. I cannot even find metadata by searching the entire disk.

Where should the metadata be. ie time stamps, owner.
Is there a link to the cluster somewhere in the record?

I would like to get an image up here but doesn't seem to be an option to upload on here.

Ill try this
[image "https://www.forensicfocus.com/C\Users\manus30\Desktop\NTFS_TestFiles\mf.jpg" not found]

 
Posted : 28/04/2014 9:47 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
 

Hi again. I got such great advice last time that I have returned for more. I am continuing to look more at Master File Table records, and have been encouraged to find file metadata in the mtf entry itself by

my lecturer

.

So this is homework?

 
Posted : 29/04/2014 12:34 am
Dermot29
(@dermot29)
Posts: 15
Active Member
Topic starter
 

Im a 31 year old student. Too old for homework. I just hit a dead end with it, so thought Id ask for help. My lecturer also encouraged me to use forums.

 
Posted : 29/04/2014 12:51 am
Dermot29
(@dermot29)
Posts: 15
Active Member
Topic starter
 

I figured this out by researching. Found a great explanation and guide if anyone else is having difficulty with this in the future. My problem was that I was expecting to see all the metadata in plain text in the data area of the hex viewer.

Anyway, turns out its a bit more complicated than that. Not too bad, once ya know what your doing and definitely worth researching from a digital forensics point of view.

Anyway. This my last academic assignment in Digital Forensics. With a bit of luck my next post will be about a work related problem

good link explaining my problem

http//gerbenkleijn.com/?p=261

Also good tool to decode the Timestamps in the MFT

http//www.digital-detective.net/digital-forensic-software/free-tools/

 
Posted : 29/04/2014 9:02 pm
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

Well done! I think if you fiogure things out yourself then you retain it better.

Dcode is good, but personally I prefer Stampede as if you're not entirely sure of the type of timestamp it can help!

 
Posted : 01/05/2014 3:12 pm
mscotgrove
(@mscotgrove)
Posts: 934
Prominent Member
 

The demo of my www.cnwrecovery.com software has a feature in the sector view. If you display a MFT sector and move the cursor over the hex display, it will decode most of the elements. This includes the dates which you will discover are stored in several places. It will also decode the first cluster run.

It is not 100% comprehensive, and only works on first 0x200 bytes of the $MFT entry, but may be a quick way to help you understand the $MFT

 
Posted : 01/05/2014 3:44 pm
Share:
Share to...