Re: [sleuthkit-users] how do I get the file location without a scan?

[brads <br...@ny...>]

I think you are correct in your first assessment of how it is created. I was
a little off.

 

tsk_recover failed to retrieve unallocated files that photorec was able to
retrieve.

I don't understand why one would fail and the other would not.

 

Brad

 

From: Simson Garfinkel [mailto:si...@gm...] On Behalf Of Simson
Garfinkel
Sent: Saturday, September 19, 2015 4:03 PM
To: brads <br...@ny...>
Cc: sle...@li...
Subject: Re: [sleuthkit-users] how do I get the file location without a
scan?

 

Hi Brad.

 

It sounds like you are trying to recover the data from a drive that has been
hit by Cryptowall. 

 

Are you sure that it first deletes the file, then make a copy of the file,
and encrypt the resulting file. If it does that, then how would it get the
data for the deleted file?  More likely, the program encrypts the file to a
new, temporary name, deletes the file, and then renames the encrypted file
to the new file. Or, alternatively, it could simply encrypt in place.
(That's what I would do, if I was writing such a program, as it wouldn't
require additional file space.)

 

In any event, you can use tsk_recover to recover all of the unallocated
files that can be "undeleted". If you are going to go after this with file
carving it's unlikely that you'll like the results, as most file carvers can
only recover contiguous files. The except is JPEGs, which isn't what you are
trying to recover.

 

Is this your system or a clients? Faced with Cryptowall, your best bet is to
go to the backups.

 

Simson

 

 

On Sep 19, 2015, at 2:34 PM, brads <br...@ny...
<mailto:br...@ny...> > wrote:

 

Yes, the string in question is the filename.

The data in question fell victim to Cryptowall 3.0

>From what I read and can tell, Cryptowall 3.0 first deletes the file and
then makes a copy of the file and encrypts that.

Extundelete fails to undelete the original file. Photorec recovers the
original file but blows out the file name with is not acceptable for the
4000 files in question.

All corrupted files are .docx and .pdf formats.

 

My thought is to create a python script that searches the string, then
calculates the offset and then use dd to carve out the file and name that
file to the proper name.

The image is 189GB and is mounted ro from and EXT4 file system 

 

Thank you sincerely for any guidance you can provide.

 

Brad

 

From: Simson Garfinkel [mailto:si...@gm...] On Behalf Of Simson
Garfinkel
Sent: Saturday, September 19, 2015 1:43 PM
To: brads <br...@ny... <mailto:br...@ny...> >
Cc: sle...@li...
<mailto:sle...@li...> 
Subject: Re: [sleuthkit-users] how do I get the file location without a
scan?

 

Hi Brad.

 

Is the string in the file name, in the file contents, or in unallocated
space?  How big are your disk images?

 

Are you trying to probe for the existence of the string, do you need to
learn its block number, or are you trying to learn the actual file in which
the string resides?

 

Do you know anything else about the files? Such as their file type? Do you
need to analyze every file, or just files of a particular type?

 

Simson

 

 

 

 

On Sep 19, 2015, at 1:15 PM, brads <br...@ny...
<mailto:br...@ny...> > wrote:

 

I followed the instruction from
http://wiki.sleuthkit.org/index.php?title=FS_Analysis but following the
process, I am unable to find a given string  http://i.imgur.com/kYuEatn.png 

I know the string is there because I can locate it using the string command
http://i.imgur.com/alQCRfM.png but, this is not an acceptable solution
because the scan takes 3 hrs against the image, I have 400 to do.

How do I get blkfs to work correctly or an alternative to getting a string
location at the disk layer like string but more robust?

 

Brad

----------------------------------------------------------------------------
--
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org <http://www.sleuthkit.org/>