Join Us!

Encase 7 Index Buff...
 
Notifications
Clear all

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

Page 1 / 2
  RSS
shawnz
(@shawnz)
New Member

After parsing a $I30 file with Encase Index Buffer Reader script, multiple existing files were found to have corresponding ***RECOVERED ENTRY*** records. Below is an example of one of these files.

Does this imply that these files were once deleted and then recovered somehow? How are the "Recovered Entry" records created by the script?

**RECOVERED ENTRY***
FILE NAME ZFTE553n.jpg
FILE ID 432884
PARENT ID 154315
CREATED 09/26/15 103503AM
WRITTEN 09/25/15 015207PM
MODIFIED 09/26/15 103503AM
ACCESSED 09/26/15 103503AM
NAME TYPE Win32
LOGICAL SIZE 185498
PHYSICAL SIZE 188416
DOS PERMISSIONS Archived

FILE NAME ZFTE553n.jpg
FILE ID 432884
PARENT ID 154315
CREATED 09/26/15 103503AM
WRITTEN 09/25/15 015207PM
MODIFIED 09/26/15 105600AM
ACCESSED 09/26/15 103503AM
NAME TYPE Win32
LOGICAL SIZE 185498
PHYSICAL SIZE 188416
DOS PERMISSIONS System Archived

Quote
Posted : 03/12/2018 8:06 pm
JerryW
(@jerryw)
Junior Member

I don't know if this will help your understanding, but may be a good starting point.

https://digital-forensics.sans.org/blog/2011/09/20/ntfs-i30-index-attributes-evidence-of-deleted-and-overwritten-files

ReplyQuote
Posted : 03/12/2018 9:29 pm
shawnz
(@shawnz)
New Member

Tnx. That link is helpful but not enough details on the script. Hopefully someone can decipher the Encase Index Buffer Reader script and share the logic behind it.

ReplyQuote
Posted : 03/12/2018 10:26 pm
JimC
 JimC
(@jimc)
Member

The $I30 indexes (like all NTFS indexes) are stored in a sorted tree. The tree is frequently re-arranged to make it sort efficiently.

During this re-arrangement entries may be discarded. When this happens, they can still hang around on disk and thus there may be multiple identical (or very similar) entries. This is normal. It doesn't necessarily mean the file/directory no longer exists - rather it is just an indication of what did exist (and may still exist) at the point the index record was last updated.

You can find good explanation this here

File System Forensic Analysis

Does the index help your case, are the name, date, size etc relevant? If not, they can probably be ignored.

Jim

www.binarymarkup.com

ReplyQuote
Posted : 03/12/2018 10:34 pm
hommy0
(@hommy0)
Member

What is the exact name of the script? and do you know where you got the script from?

Regards

ReplyQuote
Posted : 04/12/2018 11:37 am
Gsibat
(@gsibat)
New Member

Index buffers are a supplementary indices to MFT Record entries for folders that contain more than roughly 4-5 files. Typically a copy of the File Name attribute for a file in a folder forms part of the MFT Record for the folder containing the file(s). Therefore, for a folder that contains a significantly greater number of files then there isn't enough space within an MFT Record to store the File Name attributes for each file so the supplementary indices, Index Buffers, are created to store that data. Data with theses index buffers are stored using the BTree method and are in a permanently sorted state. So as files get deleted, so the remaining records are ordered accordingly. The reference to 'Recovered Entries' refer to entries that have been recovered. If the entry relates to file in question then it indicates that a file by that name existed at sometime. Other corroborative information would be required to support the existence or deletion of a file such as $USNjrnl and $Recycle.bin

ReplyQuote
Posted : 27/01/2019 7:58 pm
JimC
 JimC
(@jimc)
Member

A significant problem with NTFS analysis is the lack of "official" documentation from Microsoft. This means that lots of different terms are used to describe the same concepts and the resulting explanations, whilst generally accurate, can be a little imprecise in the details. To expand on @Gsibat's post

The start of an NTFS index is held in a $INDEX_ROOT attribute (90h). This attribute is always resident in the $MFT and named. If the index is small then this attribute will hold the entire index.

In the case of a larger index, the $INDEX_ROOT attribute will contain the start of the index tree with pointers to child index entries. These are contained in the data stream of a non-resident $INDEX_ALLOCATION attribute (A0h). This stream is composed of one or more “INDX” records which contain further index entries. If the tree is sufficiently complex these entries may in turn point to other records representing further nodes in the tree and so on.

The indexes are not essential to NTFS analysis because the directory tree can be determined just from the $MFT alone. I cannot remember seeing any official documentation on why the indexes exist but assume it is a performance measure for faster directory look-ups (the clue is in the name). 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. These can remain on disk long after the actual data was deleted and maybe the original $MFT record amended or reused.

Jim

www.binarymarkup.com

ReplyQuote
Posted : 29/01/2019 12:42 pm
thefuf
(@thefuf)
Active Member

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).

ReplyQuote
Posted : 29/01/2019 6:26 pm
JimC
 JimC
(@jimc)
Member

@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

ReplyQuote
Posted : 29/01/2019 8:00 pm
thefuf
(@thefuf)
Active Member

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 211523.496492
$SI A 2019-01-29 211647.817726
$SI C 2019-01-29 211247.618634
$SI E 2019-01-29 211523.496492

$FN M 2019-01-29 211247.618634
$FN A 2019-01-29 211247.618634
$FN C 2019-01-29 211247.618634
$FN E 2019-01-29 211247.618634

2. Source index record (for the same file)

$FN M 2019-01-29 211523.496492 = ($SI M)
$FN A 2019-01-29 211523.496492 != ($SI A)
$FN C 2019-01-29 211247.618634 = ($SI C)
$FN E 2019-01-29 211523.496492 = ($SI E)

Nuff said.

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

ReplyQuote
Posted : 29/01/2019 9:30 pm
thefuf
(@thefuf)
Active Member

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.

ReplyQuote
Posted : 29/01/2019 9:48 pm
JimC
 JimC
(@jimc)
Member

@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 0000

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

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

ReplyQuote
Posted : 29/01/2019 10:34 pm
thefuf
(@thefuf)
Active Member

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. lol

ReplyQuote
Posted : 29/01/2019 10:43 pm
JimC
 JimC
(@jimc)
Member

@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. oops

Jim

www.binarymarkup.com

ReplyQuote
Posted : 29/01/2019 10:52 pm
thefuf
(@thefuf)
Active Member

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.

ReplyQuote
Posted : 29/01/2019 10:52 pm
Page 1 / 2
Share: