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

[Simson G. <si...@ac...>]

tsk_recover relies on metadata to recover files.

photorec is a carver.  It recovers files based on patterns in the data.

They use completely different approaches. As such, they will recover different content. 

If you got back the files, and there are only 400 of them, then be grateful and rename them manually.  Either that, or restore from your backups.


> On Sep 19, 2015, at 7:37 PM, brads <br...@ny...> wrote:
> 
> 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... <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 <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 <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 <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 <https://lists.sourceforge.net/lists/listinfo/sleuthkit-users>
>>> http://www.sleuthkit.org <http://www.sleuthkit.org/>
>>  
> 
>