Re: [sleuthkit-developers] Question about resident files & tsk_loaddb

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

Right.  Resident files don't have entries in fs_Blocks because they don't have blocks allocated to them.   The only way to really map it in the current version is to get the offset in the MFT and figure out the MFT entry by dividing the offset by 1024.  You can them map the MFT entry to a file name...  

The next release of loaddb uses an entirely new schema and the fs_blocks table is gone.  it has been replaced by a structure that maps byte runs to a file (to allow for carved files outside of a file system). Currently, we don't map resident files into this though because the files don't have data explicitly allocated to them.  I'll make a tracker story though to see if there is a clean solution to this problem. 

thanks,
brian



On Nov 11, 2011, at 1:25 AM, Andrew Case wrote:

> Hello,
> 
> I was writing as I am attempting to write a script that can take an offset in a partition, such as the location of a file found by Scalpel, and then automatically determine which file in the filesystem it belongs to (if any).
> 
> My algorithm is to get the partition offset, divide by the block size (to get the block number), and use this as the starting block in tsk_fs_blocks, and then use that information to query in tsk_fs_files.This works very well except for the case of small (resident) files that are stored in the MFT. For these files, the resulting report, which lists the file names, says that the hit was found in the MFT instead of the actual file. I looked into the issue and it seems that no tsk_fs_blocks row is created for resident files.
> 
> So I am kind of stuck at this point.... I don't see a way using only the information in tsk_loaddb to handle this situation, and would greatly appreciate any pointers...
> 
> Thanks,
> Andrew
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers