EnCase Search Problem

Hi Mark,

What file system is in use? Is it NTFS? If so, when you performed your search for the keyword 'numbers' did you search in Unicode as well as ANSI? Filename entries in the MFT are stored in Unicode so if there is an MFT record for it this should be picked up.

It is difficult to carve for a text file as they have no file signature. I think an MFT record or directory entry record are your best options without knowing the content of the file. You could also try searching for a bit more of the path in both ANSI and Unicode in case there are any other link files pointing to that location.

Hope that helps

Did you try looking for "umbers" or "umbers.txt" without the first character? Text files won't have a header/footer to carve, so you'll either need to locate the file reference in MFT/FAT or search for known text from the file…which is difficult if you don't know the text.

BTW this doesn't looks like an "EnCase Search Problem" to me.

Is there a way of searching for the .txt file, and possibly restoring it, as I suspect it has been deleted?

My advise is to get up to date with the latest file recovery and carving techniques.

Text files won't have a header/footer to carve, so you'll either need to locate the file reference in MFT/FAT or search for known text from the file…which is difficult if you don't know the text.

Because the extension is .txt, it isn't necessarily a text file; these are dangerous assumptions to make as a CF. You're largely right about the header/footer; most text files do not have a distinct header/footer (Note that XML and HTML files are also text files that do have header/footer like properties).

It is difficult to carve for a text file as they have no file signature

Actually for most latin based languages it is very simple, you could use content characteristics to carver the file. You know that the byte value distribution of a text file is limited, mainly alpha numeric, punctuation and whitespace (zero byte for UTF16/32), and take some margin of error into account like 2-5%.

You all 3 might want to check the DFRWS 2006 and 2007 challenges and my work on the ReviveIt proof-of-concept carver for this.

Hello,

Thanks for the quick responses.

I have found reference to the file in the Prefetch, showing it was opened by Notepad. There's also reference to it in the Layout.ini file, $LogFile, and a couple of hits in unallocated clusters, but none are the original file. The hits in unallocated look like .lnk file hits.

The file system is NTFS, but searches haven't shown any hits in the $MFT.

We don't know the original text either.

It's not looking good!

Because the extension is .txt, it isn't necessarily a text file; these are dangerous assumptions to make as a CF. You're largely right about the header/footer; most text files do not have a distinct header/footer (Note that XML and HTML files are also text files that do have header/footer like properties).

Actually for most latin based languages it is very simple, you could use content characteristics to carver the file. You know that the byte value distribution of a text file is limited, mainly alpha numeric, punctuation and whitespace (zero byte for UTF16/32), and take some margin of error into account like 2-5%.

You all 3 might want to check the DFRWS 2006 and 2007 challenges and my work on the ReviveIt proof-of-concept carver for this.

Joachimm, I appreciate what you are saying, I was just going for the simple solutions first with the limited info provided. Of course if this text file was considered crucial for a case I would delve into it further…..no assumptions made.

Mark, have you looked in to the System Restore Points? Any hits in there?

I'd personally start with the simple things, ie. checking the MFT for "umbers". A text file _might_ be small enough to be resident, so the data _might_ be resident in the MFT. Or there _may_ be a reference to a sector where the data is. If these aren't getting any results, then look to the next levels of analysis, carving, etc. But carving for raw text is going to be a pain if you're dealing with a TB of data or more…not that I know how big the source media is. Just trying to help the guy with some simple stuff first.

Thanks for the tips.

I have searched the MFT, but there's nothing there.

I've also tried searching for raw text that I think might be in the document, but got no hits.

I'm probably worrying about this file too much anyway.

Just trying to help the guy with some simple stuff first.

Both kiashi and darren_q, good to hear that both of you take your work seriously.

However IMHO this post is somewhat in line with earlier discussions about "Solve my case/homework" for me. Even the subject is off topic. Don't get me wrong I find it very good that we should help people.

My point is best illustrated by an old Chinese saying
Give a person a fish, and you feed them for a day. Teach a person how to fish, and you feed them for a lifetime.

But carving for raw text is going to be a pain if you're dealing with a TB of data or more…not that I know how big the source media is.

You're right, but you could use additional techniques to filter out a lot of the unwanted text.
Also if you're dealing with an NTFS compressed volume you're not going to find it in this way.

Two things you should try, neither of which will help you get the file back

- parse out INFO2 records, which will give you information about Recycle Bin activity

- parse out the "Index Buffers" of the /Documents and Settings/User/My Documents/Private directory. In EnCase, clicking on folders in an NTFS volume will show you data for the folders, as if they're files, too. This data is a cache of the metadata for files contained within the folder. You may find a record pertaining to the Numbers.txt file.

Of course, parsing the associated link file records you've found is a good idea, too. This helps you build up a record of activity concerning the file and confirmation of its past existence. Unless you can find some tangible association of the filename with disk location, carving the file from unallocated probably won't work–not that the data can't be recovered with some of the techniques recommended here, but it will be difficult to establish the data comprises this particular file.

In particular, scour the link files for volume IDs, browser history for other volume names, optical media burning artifacts, and the registry for any indication of removable media. This file may no longer exist in the My Documents/Private folder, but it may yet exist on a thumb drive that the user has retained.

Jon