Re: [sleuthkit-users] Tsk_loaddb generating an inconsistent file system tree
Brought to you by:
carrier
Menu
▾
▴
Re: [sleuthkit-users] Tsk_loaddb generating an inconsistent file system tree
|
From: Alex N. <ajn...@cs...> - 2016-03-24 01:57:10
|
Hi all, I’m just seeing tonight’s thread. I did publish an article on the topic of multi-tool verification of file system state, but Simson provided the wrong link. <https://www.dfrws.org/2014/proceedings/DFRWS2014-6.pdf <https://www.dfrws.org/2014/proceedings/DFRWS2014-6.pdf>> If anybody is curious on verifying NTFS with The SleuthKit’s code base and EnCase, there is an approach you can take based on Digital Forensics XML. Try using Fiwalk and Sebastien Bourdon-Richard’s EnScript to generate DFXML: <https://github.com/Sebastienbr/DFXML-EnCase <https://github.com/Sebastienbr/DFXML-EnCase>> You can compare results using this tool, written for the DFRWS paper: <https://github.com/ajnelson/fsnview <https://github.com/ajnelson/fsnview>> I hope that helps, and I’ll be curious to hear what you find. If you have weird issues based on deletion, they may be related to this: <https://github.com/dfxml-working-group/dfxml_schema/issues/14 <https://github.com/dfxml-working-group/dfxml_schema/issues/14>> I’m still interested in the topic of tool verification, but I’m wrapping up an unrelated multi-year project in the next two months, so I’ve been quiet on this front. —Alex > On Mar 23, 2016, at 21:06 , Simson Garfinkel <si...@ac... <mailto:si...@ac...>> wrote: > > Mike, > > That's fine. If multiple paths work, then we should either have a canonical path or a way for validating that a path is correct. However, I think that another thing you would want to check is to make sure that the different tools consistently report whether or not a file is allocated, the file's physical location in the disk image, file length, etc. > > Alex Nelson was looking at ways of doing inter-tool verification and had a published article on this: > https://www.soe.ucsc.edu/events/event/2981 <https://www.soe.ucsc.edu/events/event/2981> > > I'm curious as to whether or not the TSK developers have such a validation process in place. > > Simson > > >> On Mar 23, 2016, at 8:42 PM, Mike Haaf <mi...@zu... <mailto:mi...@zu...>> wrote: >> >> 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... <mailto: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... <mailto: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... <mailto: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_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________> >>>> sleuthkit-users mailing list >>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users <https://lists.sourceforge.net/lists/listinfo/sleuthkit-users> >>>> http://www.sleuthkit.org <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 <http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140>_______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users <https://lists.sourceforge.net/lists/listinfo/sleuthkit-users> >>> http://www.sleuthkit.org <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_______________________________________________ <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 |
