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

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

Hi Luis,

Thanks for this info. Can you send me the ‘istat’ output for dir1 and dir2? I’m curious to see how they are different.

thanks,
brian


> On Mar 24, 2016, at 9:29 AM, Luís Filipe Nassif <lfc...@gm...> wrote:
> 
> Hi Brian,
> 
> I have just confirmed fls shows the file path as /dir1/file1.txt based on your example.
> 
> But in tsk_objects table the parent of file1.txt is dir2, which has the same meta_addr and meta_seq of dir1. I think the problem is in the parent cache map used in TskDbSqlite::storeObjId() and TskDbSqlite::findParObjId()
> 
> I detected the issue in my cases searching for allocated files under unallocated folders, maybe you could find that in your test cases.
> 
> Thank you very much for your time,
> Luis
> 
> 2016-03-24 0:11 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
> Hi Brian,
> 
> Your example illustrates the issue, except that file1.txt and dir1 are allocated and dir2 is unallocated.
> 
> I will run fls on one image to check what it reports and post results.
> 
> Thank you,
> Luis
> 
> Em 23 de mar de 2016 23:44, "Brian Carrier" <ca...@sl...> escreveu:
> Hi Luis,
> 
> Can you provide a sanitized example of what you are seeing?  Is it that:
> 
> - You have an unallocated file.  If you look at its parent_path and file name in tsk_file, then you get something like /dir1/ and file1.txt (i.e. /dir1/file1.txt)
> - When you use the DB / Autopsy, the file is actually shown as a child of another directory, dir2 for example.  (i.e. /dir2/file1.txt).
> - dir1 and dir2 have the same meta_add and meta_seq values in the database.
> - If you were to run ‘fls’ on the image, it would show the file as (/dir1/file1.txt).
> 
> Is this correct?
> 
> At some point in the past couple of years, we added a bunch of sequence checks because we were incorrectly mapping files to parent folders.  In theory, the sequence number is incremented each time an entry is reallocated, so it should be a reliable way of mapping it to the correct path.
> 
> thanks,
> brian
> 
> 
> > On Mar 22, 2016, at 12:10 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
> >
> > 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