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

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

One more info, the obj_id of dir2 is less than obj_id of dir1, so I think
obj_id of dir2 (unallocated) is saved in the parent cache map before
processing dir1.

2016-03-24 10:29 GMT-03:00 Luís Filipe Nassif <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
>>>
>>>
>