NTFS MFT Analysis Identifying Cluster run
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
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!
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
BTW, great diagram, I might actually screen grab that for my assignment too
You're welcome! Glad it helped.
Dermot - Think in Hex, it will actually make far more sense than decimal
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…
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]
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 bymy lecturer
So this is homework?
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.
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
Also good tool to decode the Timestamps in the MFT
Well done! I think if you fiogure things out yourself then you retain it better.
Dcode is good, but personally I prefer
The demo of my
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