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

[Luís F. N. <lfc...@gm...>]

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
>>
>>