Encase 7 Index Buff...
 
Notifications
Clear all

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

18 Posts
6 Users
0 Likes
2,039 Views
(@shawnz)
Posts: 2
New Member
Topic starter
 

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

 
Posted : 03/12/2018 8:06 pm
(@jerryw)
Posts: 56
Trusted 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

 
Posted : 03/12/2018 9:29 pm
(@shawnz)
Posts: 2
New Member
Topic starter
 

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.

 
Posted : 03/12/2018 10:26 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable 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

 
Posted : 03/12/2018 10:34 pm
(@hommy0)
Posts: 98
Trusted Member
 

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

Regards

 
Posted : 04/12/2018 11:37 am
(@gsibat)
Posts: 12
Active 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

 
Posted : 27/01/2019 7:58 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable 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

 
Posted : 29/01/2019 12:42 pm
(@thefuf)
Posts: 262
Reputable 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).

 
Posted : 29/01/2019 6:26 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable 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

 
Posted : 29/01/2019 8:00 pm
(@thefuf)
Posts: 262
Reputable 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.

 
Posted : 29/01/2019 9:30 pm
Page 1 / 2
Share: