±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35894
New Yesterday: 3 Visitors: 111

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Forensic software discussion (commercial and open source/freeware). Strictly no advertising.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3 
  

thefuf
Senior Member
 

Re: Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Post Posted: Jan 29, 19 23:52

For sure, I can post a sample $MFT file, if anyone wants to see what's happening. The $FILE_NAME timestamps in the index entry are kept in sync with the $STANDARD_INFORMATION timestamps, with the only exception for the last access timestamp (which is likely caused by a bug, not by a feature).

@JimC conducted a test, but he/she provided the $FILE_NAME timestamps from an index entry for another directory, not for a file in question (the timestamps are stored before the name, not after).

Edit: less offensive.  
 
  

JimC
Senior Member
 

Re: Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Post Posted: Jan 30, 19 00:04

I got the following comment from a member of the NTFS development team on why there are timestamps in both $SI and $FN. This may be useful (paragraphs added by me to improve readability):

"I can only speculate but my guess is that very early on in development, the intention was when updating duplicated information in the parent directory that we would first update the $FILE_NAME attribute and then copy that verbatim to the parent directory. That way they would always be exactly in sync. You could look at the $FILE_NAME attributes and know exactly what the duplicated information should look like.

Importantly if a directory got corrupted and needed to be re-created from scratch by chkdsk, it would end up getting created with the precise duplicated information it would have had. But I'm guessing the early developers quickly realized the perf impact of having to update the $FILE_NAME attribute every time duplicated information got updated, including logging the update of the $FILE_NAME attribute, was just not worth it just to maintain that property. So they ended up just leaving the $FILE_NAME attribute alone, except as you noticed when the $FILE_NAME attribute needs to be updated anyway for a name change, the duplicated fields can get updated at that time because it is basically free.

I can tell you (since I have access to all historic released code) that it was already this way in Windows NT 3.1. So if they changed their mind for perf reasons as I suspect, it was done before the initial release. They may have not wanted / had time to do the work of removing those fields from the $FILE_NAME attribute, or they may have just like the symmetry of having $FILE_NAME attributes and duplicated information use the same data structure. But it is a complete waste of file record space that we are still living with. Theoretically if we ever get a chance to make sweeping breaking changes to the on-disk format then we could consider optimizing this."


Jim

www.binarymarkup.com  
 
  

thefuf
Senior Member
 

Re: Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Post Posted: Jan 30, 19 00:14

- JimC
I got the following comment from a member of the NTFS development team on why there are timestamps in both $SI and $FN. This may be useful (paragraphs added by me to improve readability):

"I can only speculate but my guess is that very early on in development, the intention was when updating duplicated information in the parent directory that we would first update the $FILE_NAME attribute and then copy that verbatim to the parent directory. That way they would always be exactly in sync. You could look at the $FILE_NAME attributes and know exactly what the duplicated information should look like.

Importantly if a directory got corrupted and needed to be re-created from scratch by chkdsk, it would end up getting created with the precise duplicated information it would have had. But I'm guessing the early developers quickly realized the perf impact of having to update the $FILE_NAME attribute every time duplicated information got updated, including logging the update of the $FILE_NAME attribute, was just not worth it just to maintain that property. So they ended up just leaving the $FILE_NAME attribute alone, except as you noticed when the $FILE_NAME attribute needs to be updated anyway for a name change, the duplicated fields can get updated at that time because it is basically free.

I can tell you (since I have access to all historic released code) that it was already this way in Windows NT 3.1. So if they changed their mind for perf reasons as I suspect, it was done before the initial release. They may have not wanted / had time to do the work of removing those fields from the $FILE_NAME attribute, or they may have just like the symmetry of having $FILE_NAME attributes and duplicated information use the same data structure. But it is a complete waste of file record space that we are still living with. Theoretically if we ever get a chance to make sweeping breaking changes to the on-disk format then we could consider optimizing this."


Jim

www.binarymarkup.com


The only thing I can add is that there is a need to keep $FILE_NAME timestamps (and other $FILE_NAME metadata) in a directory index: this allows a program to retrieve more information about a file with a single system call. I'm happy that NTFS developers didn't do that in the Linux way (a system call to get a next file name and inode information, then another system call for metadata about that inode).  
 
  

JimC
Senior Member
 

Re: Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Post Posted: Jan 30, 19 00:33

I tried another experiment to get to the bottom of this once and for all. This time I used XWF to manually edit the 3 different sets of time stamps to each have a unique value (changed the year in each) giving 12 unique values. The 3 timestamp locations were:

1. MFT / $SI
2. MFT / $FN
3. INDX / $FN

I then checked again with Windows Explorer, FindFirstFileEx etc. The results were:

1. FindFirstFile/Ex (and applications) report the INDX timestamps
2. The MFT / $FN timestamps are not reported
3. Changes to timestamps by SetFileTime() are reflected in $SI and INDX / $FN

My apologies to @thefuf. He was correct.

The mistake I made was to assume the timestamps in the INDX were identical to that in the MFT / $FN. I made this mistake because the storage structure is very similar (but not quite identical). This isn't the case - it looks like the NTFS developers reused the same structure but don't keep the timestamps in sync. As per my last post, the timestamps in MFT / $FN seem to only be updated when that attribute is re-written (when they come from $SI).

Jim

www.binarymarkup.com  
 

Page 3 of 3
Page Previous  1, 2, 3