Join Us!

Finding traces of a...
 
Notifications
Clear all

Finding traces of a given file in unallocated space  

  RSS
Benot
(@benot)
New Member

Hello,

I am in the following situation. I suspect certain specific files have been on a PC but then (unsecurily) deleted. Subsequent usage of the machine has very likely triggered a (at least) partial destruction of the files.

Use of recovery tools has not given any meaningful results. I guess I have now to carve into unallocated space. My questions are the following, knowing I do have copies of the suspected files :

- What would be the best process to follow here? 

- I assume looking for segments of those files would be the way to go, but which chain of (hexadecimal? Binary?) data would be long enough to be meaningful, and not trigger false positives?

Happy to hear your views, and thanks for the help.

Quote
Posted : 25/05/2020 2:39 pm
hommy0
(@hommy0)
Member

Hi,

Do you have access to EnCase?

If you do the following enscript may help to find your fragments

https://www.guidancesoftware.com/app/File-Block-Hash-Map-Analysis

It should work with both EnCase 7 and EnCase 8 (or recently released 20.2)

Regards

 

ReplyQuote
Posted : 25/05/2020 4:06 pm
jaclaz
(@jaclaz)
Community Legend
Posted by: @benot

Hello,

I am in the following situation. I suspect certain specific files have been on a PC but then (unsecurily) deleted. Subsequent usage of the machine has very likely triggered a (at least) partial destruction of the files.

Use of recovery tools has not given any meaningful results. I guess I have now to carve into unallocated space. My questions are the following, knowing I do have copies of the suspected files :

- What would be the best process to follow here? 

- I assume looking for segments of those files would be the way to go, but which chain of (hexadecimal? Binary?) data would be long enough to be meaningful, and not trigger false positives?

Happy to hear your views, and thanks for the help.

Well, you are definitely in a "special" (and "privileged") status (you have an exact copy of what to look for).

"Recovery tools" is a tad bit too generic to make sense, depending on the actual "specific" file types, and on the filesystem in use "recovery tool A" may fail whilst "recovery tool B" may succeed.

Anyway, since you have the copy of the files you suspect, you are not going to "carve", you are going to "search" or (suggested) "hash and compare".

You need to be more specific about:
1) type of file at hand
2) number of these files
3) size of these files
4) apparent status (level of fragmentation) of the filesystem
5) size of the imaged device

To explain:
1) depending on the specific file type there may be "patterns"
2) if they are a handful of files the approach may be different if they are tens, hundreds, thousands
3) if they are "small" files the approach may be different than if they are "huge" (let's say movies)
4) if the filesystem is largely fragmented or not defragmented or only slightly defragmented
5) of course processing an 8 GB USB stick is different form processing a - say - 6 TB disk

And you have to state what the "exact goal" is.

As an example you can decide that if you find 2 contiguous "unique" sectors (i.e. surely belonging to one of the reference files) is enough to prove that the file has been *before* present on the device, is different than rebuilding the whole file.

The theory of operation (generic) for hash and compare could be:
1) calculate a checksum/hash for each sector of the "reference" files (and store them)
2) calculate a chacksum/hash for each sector of the device (and store them)
3) compare the two lists

The point might be which tool to use and which checksum/hash.

Typically CRC32 would be very fast (but very prone to collisions) and SHA-1 (with a low probability of collisions) is probably too slow, MD5 is midway and probably the right choice.

And depending if you are working on Windows or Linux there may be different options for the hashing software (personally I would use dsfo on Windows and dcfldd on Linux, but there may be other suitable programs). 

ReplyQuote
Posted : 25/05/2020 5:03 pm
Benot
(@benot)
New Member

Thanks for the prompt and detailed answer, this is much appreciated. Please find below the details

1) Considered files are .jpg and .mov

2) There are a few dozens of them (less than 50)

3) Most of the files are 1-3Mo. Biggest one is ~200Mo

4) I am not sure. Filesystem is the one of a Windows Vista machine which has been through (assumed) normal use  

5) Imaged hard drive is ~300GB

 

The end goal is not to rebuilding the whole file, but rather as you say to prove that the considered file has been present before on the device.

 

I can use either Windows or Linux, but Windows would be preferred - unless of course there is a strong rationale to prefer Linux in considered case. 

ReplyQuote
Posted : 25/05/2020 10:14 pm
minime2k9
(@minime2k9)
Active Member

If you have access to X-Ways, you can use the block hashing feature in that to do this.

It will split the files into sector sized chunks and remove any that are going to cause lots of false positives (such as a sector full of 0x00) and hash each chunk. It will then hash all the sectors of the disk and compare against the chunks and tell you how many it has located for each file.

This should give you an indication which of the files were previously on the device, assuming they were not securely erased or since completely overwritten.

ReplyQuote
Posted : 26/05/2020 7:49 am
Bunnysniper
(@bunnysniper)
Active Member

In this case I would try 3 different ways:

1. Use Yara. Define a rule with some of the pattern you can take from the files you know.

2. Check the Windows Search Database. If the file was on a local drive, you might find a reference to it in the edb database.

3. Have a look at the MFT. With some luck you might find traces of the files there, too.

 

regards, Robin

ReplyQuote
Posted : 26/05/2020 11:19 am
jaclaz
(@jaclaz)
Community Legend
Posted by: @benot

4) I am not sure. Filesystem is the one of a Windows Vista machine which has been through (assumed) normal use  

Well, then it is NTFS, which may offer some "additional hint" to file recovery tools.

It would cost you nothing to try DMDE:

https://dmde.com/

and see if it can recover - even if partially - some of the files.

About the "poor man" hashing method, you can try using the dcfldd in windows as well (there is a port of it):
http://dcfldd.sourceforge.net/

Something *like* this:
dcfldd.exe if= of=NUL bs=512 hash=md5 hashlog=tempmd5.txt hashwindow=512

should work nicely.

Use this batch or similar:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
CD /D "%~dp0"
IF %1.==. GOTO :Error

SET ThisfileName=%~n1
SET Thisfile="%~dpnx1"

dcfldd.exe if=%ThisFile% of=NUL bs=512 hash=md5 hashlog=%ThisfileName%.md5.txt hashwindow=512
GOTO :EOF

:Error
ECHO Usage:
ECHO %~nx0 ^

 

jaclaz

ReplyQuote
Posted : 26/05/2020 1:51 pm
Em-Belkasoft
(@em-belkasoft)
Junior Member

If you have Belkasoft Evidence Center, you can use the custom carving function to carve into unallocated space. 

ReplyQuote
Posted : 02/06/2020 8:21 pm
Benot
(@benot)
New Member

Thanks all for feedback, much appreciated. I'll look into the aforementioned directions and revert if encounter additional difficulties 

ReplyQuote
Posted : 11/06/2020 4:04 pm
Share: