Re: [sleuthkit-users] file analysis in autopsy

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

On Jul 29, 2005, at 5:36 PM, youcef bichbiche wrote:

> Hi,
> I got a couple of questions regarding file analysis in
> autopsy.
>
> When conduction a file type analysis using the
> undelete images test #6 I came up with a summary
> where:
>
> Files (27)
> Files Skipped (9)
>
>
> 1- Can I assume that the skipped files in FAT system
> would be used to list the directory & volume entries,
> in other word any directory entry structure that's not
> a file?

I forget the details of this specific image, but that is typically the 
reason for the skipped files (and device files in Unix systems).

> 2- Also under the mismatch section I've seen a zero
> hit even though there is an image on the image system
> with a dll extension, like in the volume lable test
> image #9.
>
> How does autopsy detect mistmach. Does it need a hash
> database or can it use the file command instead?

Interesting. I hadn't noticed that one before.  The reason that it 
occurs with test #9 is that those "dll" files have an attribute type of 
volume label, which means that the 11 bytes in the name field are used 
as a full name and a '.' isn't added between bytes 8 and 9 (like what 
happens for normal directory entries).  Therefore, the name of the file 
is "FILE2   DLL" with spaces between the name and extension.  That is 
why 'sorter' does not pick them up as extension mismatches -- because 
there is no extension.

> 2- Looking at the saved files in the data category,
> I've seen a lot of files with a dead suffix like:
> data/6-fat-undel.dd-4-dead
> data/6-fat-undel.dd-5-dead
> data/6-fat-undel.dd-6-dead
>
> Interestingly enough the same inodes are also used for
> recovered files like:
>
> C:/_rag1.dat
> data/6-fat-undel.dd-4.dat
>
> C:/_rag2.dat
> data/6-fat-undel.dd-5.dat
>
> C:/_ing.dat
> data/6-fat-undel.dd-6.dat
>
>
> What are these files? and Why they are considered dead
> when they already appear as undeleted?

dead and deleted are the same.  The dead ones are found by looking for 
any unallocated directory entry.  This searches every sector of the 
disk. The "_XYZ" ones are from recursing the directory hierarchy.  
There will be overlap. Ideally, I should keep a history of the ones 
found from recursing the directory and show them only once, but 
currently they are in their twice.  There could be "dead" ones that are 
not in the directory structure if the parent directory was deleted and 
could not be recovered.

brian