Re: [sleuthkit-users] Tsk_loaddb generating an inconsistent file system tree

[Mike H. <mi...@zu...>]

Depending on how you traverse NTFS it is possible to come up with multiple paths for the same file.  Parents have pointers to their children and children have pointers to their parents, and (in the case of deleted directories) they don't have to match.  A top down traversal of the tree via the Index Root and Index Allocation attributes will result in allocated files under deleted directories.  A flat (or bottom up) traversal of the MFT that uses the parent reference in the File Name attribute is going to give you a file's true parent directory, which should always be allocated if the file was allocated.  Most tools show the results of the bottom up approach as the "path" of a file.

> On Mar 23, 2016, at 7:32 PM, Simson Garfinkel <si...@ac...> wrote:
> 
> Luis,
> 
> This is the point at which someone (Alex?) should be asking a few pointed questions, to wit:
> 
> • Does anybody know of any formal validation that's been done to compare the output of FTK, EnCase, TSK, and Autopsy?
> 
> 
>> On Mar 23, 2016, at 7:17 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
>> 
>> I have just confirmed this issue with 2 (of 3) ntfs images processed with tsk_loaddb I am working right now, so the problem seems quite common. There are a number of allocated files below some deleted directories in the file system tree and the path of those files shows different parents. Looking into the true parent directories (not deleted), there is no children. My colleague observed this behaviour at least in 3 ntfs images.
>> 
>> I modified the logic of TskDbSqlite::storeObjId() and TskDbSqlite::findParObjId in db_sqlite.cpp to ignore the NTFS sequence number and to use the file paths when there are multiple items pointing to the same meta_addr, like is already done for other file systems. That change solved the problem, but I not sure if it could cause side effects for NTFS?
>> 
>> Best regards,
>> Luis 
>> 
>> 2016-03-22 13:10 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>>> Hi,
>>> 
>>> A colleague of mine have observed tsk_loaddb 4.2 (so I think Autopsy too) incorrectly decoding the file system tree of some NTFS images. I analysed one sqlite sent by him and tsk_loaddb is putting a number of (very important) files into a deleted directory with the same meta_addr and meta_seq of the true (not deleted) parent directory of those files, according to tsk_objects table. The parent_path of the child files are populated correctly into sqlite.
>>> 
>>> Maybe the parent cache table logic used internally by tsk_loaddb should be updated to handle that situation (NTFS files with same meta_addr and meta_seq)?
>>> 
>>> We will gladly provide any other information to help solve the problem.
>>> 
>>> Thank you very much for your attention,
>>> Luis
>>> 
>> 
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org