±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36296
New Yesterday: 2 Visitors: 138

±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 1, 2, 3  Next 
  

shawnz
Newbie
 

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

Post Posted: Dec 03, 18 20:06

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 10:35:03AM
WRITTEN: 09/25/15 01:52:07PM
MODIFIED: 09/26/15 10:35:03AM
ACCESSED: 09/26/15 10:35:03AM
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 10:35:03AM
WRITTEN: 09/25/15 01:52:07PM
MODIFIED: 09/26/15 10:56:00AM
ACCESSED: 09/26/15 10:35:03AM
NAME TYPE: Win32
LOGICAL SIZE: 185498
PHYSICAL SIZE: 188416
DOS PERMISSIONS: System Archived  
 
  

JerryW
Member
 

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

Post Posted: Dec 03, 18 21:29

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

digital-forensics.sans...tten-files  
 
  

shawnz
Newbie
 

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

Post Posted: Dec 03, 18 22:26

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.  
 
  

JimC
Senior Member
 

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

Post Posted: Dec 03, 18 22:34

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  
 
  

hommy0
Senior Member
 

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

Post Posted: Dec 04, 18 11:37

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

Regards  
 
  

Gsibat
Member
 

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

Post Posted: Jan 27, 19 19:58

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  
 
  

JimC
Senior Member
 

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

Post Posted: Jan 29, 19 12:42

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  
 

Page 1 of 3
Page 1, 2, 3  Next