Re: [sleuthkit-users] The "right way" to find deleted files on NTFS

[Brian C. <ca...@sl...>]

Michael,

The most efficient way to do what you want (with the current version)  
is as follows:

- Identify all of the inodes associated with directories.   You can  
do this with 'fls' or 'ils'.
- Run 'ifind -p' on all of those inodes.

The way to get around the performance impact is to write a program  
that uses the TSK library instead scripting around the command line  
tools. Each time a command line tool is run, a lot of initialization  
stuff needs to be run.  The 3.00 version of TSK will be listing all  
of the deleted files with 'fls'.

thanks,
brian



On May 29, 2008, at 12:53 AM, Michael Rich wrote:

>
>
> I've spent the last few days exhaustively pouring over the mailing  
> list archives, SKINS, man pages.  I've written script after script  
> trying things out.  I just can't seem to find a way to  
> comprehensively list deleted files on an NTFS partition using TSK  
> tools or Autopsy.
>
> I think I'm missing a clue.  But let me tell you what I've tried:
>
> First, the standard "fls -dFr ..." method.  I was excited by how  
> fast that was but then I realized all the "realloc" files are still  
> accessible by normal means.  That led me to the archived forum  
> message talking about using "ifind -p ..."  I was trying to build a  
> tool similar to "Recuva" that will list every deleted file on the  
> partition so I wrote a script that found all the current  
> directories (fls -Dur ...), pulled the inodes out and then ran  
> "ifind -p " against every active directory.
>
> That might have worked but the I never had the patience to let it  
> run since it takes a good 2-3 seconds per inode and I'm looking at  
> 6000+ inodes on my test drive.  I checked the results after 500  
> inodes completed and only found one deleted file.  I know from  
> running recuva that I've got a lot more than that on my test  
> drive.  I did test it quickly by ntfs-3g mounting the drive,  
> picking an innocous file and deleting it.  I then ran "ifind -p" on  
> the parent directory.  It failed to find the file I just deleted.
>
> So, then I started playing around with ils -A.  I took the inodes  
> from this and ran them through ffind to get some decent results,  
> but only 49 listings were found.  From Recuva, I know I'm looking  
> at a lot more than that.
>
> Then I got the bright idea to just run ffind againt EVERY inode.   
> So I ran "ils -e" and pulled the inodes from this, running each  
> through ffind to see what turns up.   It's running slow too, but  
> not as bad as "ifind -p".  I'm 40% through my test run here and I  
> just checked my results.  So far, it's only found 5 files.  These  
> same five were part of the "ils -A" attempt above.
>
> Then I tried autopsy, but the results for "Show All Deleted Files"  
> is the same as "fls -dFr" above.
>
> All of these efforts were run against live hard drives and not images.
>
> I'm just trying to find the right way to get results closer to what  
> the Win-native recovery tools are producing.  I know about foremost  
> for carving, but I don't think that's what Recuva is using (unless  
> you check the "deep scan" option).  I'm pretty certain they are  
> simply using the MFT some way to identify deleted files.  Recuva  
> (and most Win-native tools) can scan a big drive in less than a  
> couple of minutes and identify thousands of deleted files and judge  
> their integrity.  There's got to be a way to do it with linux.
>
> Can anyone help me out?
>
> Thanks for your expertise and time.
>
> Mike
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org