$MFT -> $SI differs...
Clear all

$MFT -> $SI differs from $FN for 50% of the files

5 Posts
3 Users
0 Reactions
Posts: 13
Active Member
Topic starter


I am trying new things on my testsystem and actually I try to find traces for timestamp manipulation so I extracted $MFT with OSForensics and parsed it with anylyseMFT ( https://github.com/dkovar/analyzeMFT).

So far, so good - I got 640k enties.

Then I tryed to filter out entires which have different timestamps in $FN and $SI. My first try gives me 560k entries and that can't be true.

So I inspected the data an found ot some entries just differ in the fraction of the seconds ans so I altered the filter to ignore the fractions of the second and that gave me 440k entries. WTF?

I checked the data and found out that some programm files have that issue so I guessed that may be due to some installers and I filtered all paths out starting with "/Program" or "/Windows". But I have still 340k entires.

I remembered that access time updates can be deactivated and ignored there timestamps and include /Program* and /Windows* back in the filter and finally I end up with 364k entries.

Any suggestions why there are so many FS entries which differ in various timestamps? In some cases the timestamps differ for few minutes in some cases for multiple years.

The thing is that is a testsystem from me and I tempered with timestomb in one folder and I was expecting that I would be able to filter the files with not matching timestamps quite fast but the reality is different. Is that a normal behavor or could that be a error while parsing?

Posted : 13/07/2021 6:31 pm
Posts: 1158
Noble Member


These are not questions that need posted answers.  They might help you consider what you are doing, and identify any issues with your testing methodology.

You start from an unknown platform (Which Windows release?). You start from an unknown position: why do $FN time stamps on that platform help in identifying time stamp manipulations?  (I mean ... your test results seem to indicate that they don't, so perhaps your starting position incorrect? Or have you performed a test that isn't designed to give you useful results?)

Do you have a homogeneous test environment?  That is, a file system created by one single Windows version.  If it is a multi-year file system that has seen multiple Windows releases, you just might have different rules for timestamps over time, and that might be a factor. Do you know that you don't?

And that is assuming that your filters and other software do the correct thing.  Do they?

There seems to be a complicating factor of timestomping effects already being in place. How do you separate those from 'normal' files?  (You didn't mention it ... are you looking at existing MFT records only, or are you looking at deleted MFT entries as well?)

As to your central question:

Any suggestions why there are so many FS entries which differ in various timestamps? In some cases the timestamps differ for few minutes in some cases for multiple years.

You may need to state which specific timestamps you are referring to.  Are they always the same, or is it one set of timestamps for one group of files, and another set for another?

Posted : 15/07/2021 6:38 am
Posts: 1158
Noble Member

foo ... what happened?

Posted : 15/07/2021 1:25 pm
Posts: 1158
Noble Member

Sorry about this ... something seems to have gone wrong with my reply to the OP -- I can't see my reply, and I don't seem to be delete or quote it or the reply I tested ... oh, well.

Posted : 15/07/2021 1:28 pm
Posts: 86
Estimable Member

Please see this thread for a discussion of something very similar:

NTFS MFT Entry Modified


In this thread, I referred to some research into NTFS timestamps that I did a few years ago and the relationship between the $FILE_NAME and $STANDARD_INFORMATION timestamps (see post for full details). I summarised the results in a number of state diagrams which are available on the project website: www.binarymarkup.com






Posted : 20/07/2021 9:33 am