±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35535
New Yesterday: 1 Visitors: 129

±Follow Forensic Focus

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

RSS feeds: News Forums Articles

±Latest Articles

±Latest Webinars

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  Next 
  

thefuf
Senior Member
 

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

Post Posted: Jan 29, 19 19:26

The indexes are not essential to NTFS analysis because the directory tree can be determined just from the $MFT alone.


Nevertheless, the indexes (especially $INDEX_ALLOCATION) can be useful because they contain a snapshot of the $FILE_NAME (30h) attribute at the time the index was generated.


They are essential, because the $FILE_NAME attribute within an index entry may contain a different set of timestamps. For example, a different last access timestamp (this is not so unusual on Windows 10).  
 
  

JimC
Senior Member
 

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

Post Posted: Jan 29, 19 21:00

@thefuf - I think you may have read more into my post than I intended. All I said was that the (current) directory tree can be determined just from the $MFT alone. The indexes are redundant information to speed up file system performance. However, they are potentially forensically significant because they contain snapshots of how the file system looked at some point in the past.

That said, the $FILE_NAME ($FN) timestamps in the index are very problematic because the rules for how they are generated and when they change are not clear. Generally, Windows uses the timestamps in the $STANDARD_INFORMATION ($SI) attribute and ignores those in the $FN attribute. The $FN attribute is not typically accessible to standard user applications and similarly cannot be directly changed by standard means.

Pros: $FN timestamps are almost invisible to user and applications. Much less likely (but not impossible) to tamper with
Cos: $FN timestamps are only updated sometimes. The rules for when this happens are not obvious.

I did some experiments on this a couple of years ago that may be helpful. The following describes the detailed behaviour of each timestamp field of the $FN attribute for a file:

a. The creation (C) timestamp is persistent, even when the file is renamed. The
only occasion this timestamp is updated is when the file is moved. In this case,
the timestamp is inherited from the $SI attribute value present immediately
before the move operation. This may be forensically useful.

b. The last modified (M) timestamp is persistent except when the file is renamed
or moved. In these two cases, the timestamp is inherited from the $SI
attribute value present immediately before the operation.

c. The last accessed (A) timestamp is persistent except when the file is renamed
or moved. In these two cases, the timestamp is inherited from the $SI
attribute value present immediately before the operation

d. The entry last updated (E) timestamp is persistent except when the file is
renamed or moved. In these two cases, the timestamp is inherited from the
$SI entry last updated timestamp value present immediately before the
operation.

e. In other words, when a file is renamed three timestamps (MAE) of the $FN
attribute contain a copy of the same fields in the $SI attribute immediately
before the rename operation. The (C) timestamp is not changed by a rename
operation. This could be forensically useful as matching (MAE) timestamps,
with an earlier (C) timestamp may indicate the file has been renamed.

f. Similarly, all four (MACE) timestamps of the $FN attribute are updated when a
file is moved to contain a copy of the time fields in the $SI attribute
immediately before the rename operation. This could be forensically
significant as, in this case, the $FN attribute effectively caches the $SI
timestamps present at the point of renaming.

g. All four timestamps (MACE) are reset when a file is created by copying. This is
consistent with the observation that all four timestamps are initialised for a
new file.

h. Windows XP and Windows 7 can create an MS-DOS "compatible" short (8.3)
filename when a file is renamed. This produces a second $FN attribute. It is
assumed this behaviour is for backwards compatibility reasons although this
was not investigated further. Once created the second $FN attribute behaves
as described above.

i. Windows 10 does not automatically create a second MS-DOS “compatible”
short (8.3) filename $FN attribute when a file is renamed. It is assumed this is
for efficiency reasons. More surprisingly, Windows 10 actually discards additional
$FN records following move or copy operations.

This is arguably an implementation bug because it breaks the “contract” the
filesystem has with the user to retain information. It is possible Microsoft will
fix this behaviour in the future.

To summarise, the $FN attribute timestamps are initially the same as the $SI
timestamps and remain unchanged except for certain operations where they
are either reset to the current time (move operation) or inherit the
timestamps present in the $SI attribute (rename operation). There is no
situation where the $SI timestamps should precede those present in the $FN
attribute. Based on these experimental results, this scenario should be
considered suspicious and indicative of timestamp manipulation of the $SI
attribute.

I hope this helps. I would be very interested to hear about other research in this area and if you want to know more about how I did the experiments please PM me.

Jim

www.binarymarkup.com  
 
  

thefuf
Senior Member
 

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

Post Posted: Jan 29, 19 22:30

Generally, Windows uses the timestamps in the $STANDARD_INFORMATION ($SI) attribute and ignores those in the $FN attribute. The $FN attribute is not typically accessible to standard user applications and similarly cannot be directly changed by standard means.


This is not true. $FILE_NAME timestamps are used to provide information about files in a directory when functions like FindFirstFileExA() are called. Again, this is all about $FILE_NAME timestamps in an index entry, not in a file record.

Here is what I got in a simple test case (Windows 10).

1. Source: file record
$SI M: 2019-01-29 21:15:23.496492
$SI A: 2019-01-29 21:16:47.817726
$SI C: 2019-01-29 21:12:47.618634
$SI E: 2019-01-29 21:15:23.496492

$FN M: 2019-01-29 21:12:47.618634
$FN A: 2019-01-29 21:12:47.618634
$FN C: 2019-01-29 21:12:47.618634
$FN E: 2019-01-29 21:12:47.618634

2. Source: index record (for the same file)

$FN M: 2019-01-29 21:15:23.496492 = ($SI M)
$FN A: 2019-01-29 21:15:23.496492 != ($SI A)
$FN C: 2019-01-29 21:12:47.618634 = ($SI C)
$FN E: 2019-01-29 21:15:23.496492 = ($SI E)

Nuff said.

PS. The last access updates are back for some systems in recent versions of Windows 10.  
 
  

thefuf
Senior Member
 

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

Post Posted: Jan 29, 19 22:48

Windows 10 does not automatically create a second MS-DOS “compatible”
short (8.3) filename $FN attribute when a file is renamed. It is assumed this is
for efficiency reasons.


There is a per-volume flag to control this behavior. My Windows 10 system writes short names in the system volume. On other volumes, this behavior (along with the tunneling cache) can be disabled.  
 
  

JimC
Senior Member
 

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

Post Posted: Jan 29, 19 23:34

@thefuf - My impression has always been that the $FN timestamps (in $MFT) were redundant and were not reported by the standard Windows API or applications. I set up a quick experiment to verify what you said about FindFindEx(). Please find results below.

Test procedure:

1. Create small test drive and format as NTFS
2. Create text file in root of drive "Example.txt"
3. Touch timestamps ($SI) to be 01/01/2000 00:00

Results:


1. Windows Explorer reports $SI timestamps:



2. Command prompt DIR command reports $SI timestamps:



3. I wrote a quick program to report timestamps via FindFirstFileEx(). The code was:



4. When run, this code reported the $SI timestamps (as expected):



5. I then looked at the on disk data using XWF. The MFT entry clearly shows that the $SI timestamps have been modified but the $FN timestamps are those of original creation:



6. Finally, I checked the root directory $I30 INDX. Again, this shows the unmodified $FN timestamps:



[NOTE: This screenshot is wrong - see below]

Conclusions[u]

1. Standard Windows APIs and applications report the $SI timestamps
2. The SetFileTime() API modifies the $SI timestamps
3. The $FN timestamps are not reported in Windows Explorer (probably uses FindFirstFile/Ex)
4. The $FN timestamps are not reported by command prompt / DIR (probably uses FindFirstFile/Ex)
5. FindFirstFile/Ex reports the $SI timestamps (not $FN as reported by @thefuf)

For practical purposes: The $FN timestamps are redundant. They reflect the state of $SI timestamp at the point the $FN record was last updated. Forensically, they may be useful but must be treated with caution because how and when they were last changed depends on the operation and may have been some time ago.

@thefuf - Based on the above experiment, I am sorry, but I think your results were incorrect. Please can you post the procedure/code you used so we can verify.

Jim

www.binarymarkup.com  

Last edited by JimC on Jan 30, 19 00:38; edited 2 times in total
 
  

thefuf
Senior Member
 

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

Post Posted: Jan 29, 19 23:43

1. Standard Windows APIs report the $SI timestamps
2. The SetFileTime() API modifies the $SI timestamps
3. The $FN timestamps are not reported in Windows Explorer (probably uses FindFirstFile/Ex)
4. The $FN timestamps are not reported by command prompt / DIR (probably uses FindFirstFile/Ex)
5. FindFirstFile/Ex reports the $SI timestamps
6. For most purposes: The $FN timestamps are redundant. They reflect the state of $SI timestamp at the point the $FN record was last updated.

Based on the above experiment, I am sorry, but I think your results were incorrect.


With the following exception: you were looking at $FILE_NAME timestamps for the "System Volume Information" directory. Laughing  
 
  

JimC
Senior Member
 

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

Post Posted: Jan 29, 19 23:52

@thefuf - I am sorry, you are correct. My picture (6) was incorrect.

The $FN timestamps in the INDX are different to the $FN timestamps in the $MFT. I will repeat my experiments. Embarassed

Jim

www.binarymarkup.com  
 

Page 2 of 3
Page Previous  1, 2, 3  Next