sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

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

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

Hi Luis,

I realized I forgot to circle back on this.  I committed a fix a while back to the db_cache_uses_path branch on github. It would be great if you could test that before we do another release. Can you build from github or should I send you and exe?

thanks,
brian


> On Apr 12, 2016, at 1:14 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
> 
> Hi Brian,
> 
> Yes, in my colleague's case, the deleted folder (dir2) name is "New Folder (2)" and the true parent folder has a user specific name, so I think some rename operation was done. But I am not sure if it was an unique rename that have caused the problem. In other cases it is not so clear to me, one has a Windows.old folder involved and looks like a system backup was done. In another case the false and true parent folders are at different levels in the FS tree.
> 
> Thank you for your investigation,
> Luis
> 
> 2016-04-11 22:38 GMT-03:00 Brian Carrier <ca...@sl...>:
> Hi Luis,
> 
> I want to understand how we got into this state.  Based on the names of your folders, is it likely that the deleted folder (“dir2” in our example below) was moved to be “dir1”?    That is the easiest explanation of why a deleted name and an allocated name would point to the same entry and have the same sequence.
> 
> It still means there is an issue in the caching code that you pointed out, I just want to make sure the solution makes sense for this general problem.
> 
> thanks,
> brian
> 
> > On Mar 29, 2016, at 10:14 AM, Luís Filipe Nassif <lfc...@gm...> wrote:
> >
> > Hi Brian,
> >
> > I've attached the istat output for dir1. I do not know how to get istat result for dir2, because they have the same meta_addr. I searched the $MFT for dir2 filename and did not find it, I was able to find only dir1 filename in $MFT exactly into the record at meta_addr offset.
> >
> > But I have found dir2 filename into $index_allocation ($I30) of its parent directory. It is attached too. Finally, dir2 is shown as (realloc) in fls output.
> >
> > Please let me know if you need any other info.
> >
> > Thank you very much,
> > Luis
> >
> > 2016-03-28 22:59 GMT-03:00 Brian Carrier <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
> >
> >
> > <istat_of_dir1.txt><$I30_of_dir2_parent>------------------------------------------------------------------------------
> > 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=278785471&iu=/4140_______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> 
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] OSDFCon Call For Papers and Autopsy Module Contest

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

It’s time to start getting ready for the 7th Annual OSDFCon by submitting your presentation idea, writing an Autopsy module, and saving the date on your calendar.   OSDFCon is the 1-day event to attend each year to learn about the latest open source digital forensics and incident response tools with over 400 of your colleagues. 


THE ESSENTIALS

Conference Date: October  26, 2016
Location: Herndon, VA


CALL FOR PAPERS

Each year, OSDFCon gives developers and users a platform to talk about the open source software they love.  We want to hear your presentation and hands-on workshop ideas.  Submissions are due by  June 1.  

Past presentations have covered new software, new features in mature software, modules for plug-in frameworks, and use cases that integrate several pieces of software. A detailed list of topics and submission details can be found here: 

    http://www.osdfcon.org/osdfcon-2016/2016-call-for-presentations/


AUTOPSY MODULE COMPETITION

For the third year, Basis Technology is organizing an Autopsy module writing competition.  The modules can be written in Python or Java and we have tutorials to help you get started.    Learning to write Autopsy modules will make you more effecient because Autopsy takes care of providing access to files, user interface, and reporting.  All you have to do is focus on some cool analytics. 

The winners will be chosen by the OSDFCon attendees and the top three will get cash prizes.    If we get 12 or more submissions (the number that the Volatility project got last year), Basis Technology will double the prize amounts.   Submissions are due by October 17 (6 months away!). Links to tutorials and submission details can be found here:

    http://www.osdfcon.org/osdfcon-2016/2016-module-development-contest/


ABOUT OSDFCON

OSDFCon is the premier event focused exclusively on open source digital forensics tools, OSDFCon offers short talks over the course of a single day. These talks are packed with information and present a unique opportunity to learn about new (often free) tools and provide feedback directly to developers.  Basis Technology is the organizing sponsor of the event and it is free for government employees to attend. 

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

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

Hi Brian,

Yes, in my colleague's case, the deleted folder (dir2) name is "New Folder
(2)" and the true parent folder has a user specific name, so I think some
rename operation was done. But I am not sure if it was an unique rename
that have caused the problem. In other cases it is not so clear to me, one
has a Windows.old folder involved and looks like a system backup was done.
In another case the false and true parent folders are at different levels
in the FS tree.

Thank you for your investigation,
Luis

2016-04-11 22:38 GMT-03:00 Brian Carrier <ca...@sl...>:

> Hi Luis,
>
> I want to understand how we got into this state.  Based on the names of
> your folders, is it likely that the deleted folder (“dir2” in our example
> below) was moved to be “dir1”?    That is the easiest explanation of why a
> deleted name and an allocated name would point to the same entry and have
> the same sequence.
>
> It still means there is an issue in the caching code that you pointed out,
> I just want to make sure the solution makes sense for this general problem.
>
> thanks,
> brian
>
> > On Mar 29, 2016, at 10:14 AM, Luís Filipe Nassif <lfc...@gm...>
> wrote:
> >
> > Hi Brian,
> >
> > I've attached the istat output for dir1. I do not know how to get istat
> result for dir2, because they have the same meta_addr. I searched the $MFT
> for dir2 filename and did not find it, I was able to find only dir1
> filename in $MFT exactly into the record at meta_addr offset.
> >
> > But I have found dir2 filename into $index_allocation ($I30) of its
> parent directory. It is attached too. Finally, dir2 is shown as (realloc)
> in fls output.
> >
> > Please let me know if you need any other info.
> >
> > Thank you very much,
> > Luis
> >
> > 2016-03-28 22:59 GMT-03:00 Brian Carrier <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
> >
> >
> >
> <istat_of_dir1.txt><$I30_of_dir2_parent>------------------------------------------------------------------------------
> > 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=278785471&iu=/4140_______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
>
>

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

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

Hi Luis,

I want to understand how we got into this state.  Based on the names of your folders, is it likely that the deleted folder (“dir2” in our example below) was moved to be “dir1”?    That is the easiest explanation of why a deleted name and an allocated name would point to the same entry and have the same sequence. 

It still means there is an issue in the caching code that you pointed out, I just want to make sure the solution makes sense for this general problem. 

thanks,
brian

> On Mar 29, 2016, at 10:14 AM, Luís Filipe Nassif <lfc...@gm...> wrote:
> 
> Hi Brian,
> 
> I've attached the istat output for dir1. I do not know how to get istat result for dir2, because they have the same meta_addr. I searched the $MFT for dir2 filename and did not find it, I was able to find only dir1 filename in $MFT exactly into the record at meta_addr offset.
> 
> But I have found dir2 filename into $index_allocation ($I30) of its parent directory. It is attached too. Finally, dir2 is shown as (realloc) in fls output.
> 
> Please let me know if you need any other info.
> 
> Thank you very much,
> Luis
> 
> 2016-03-28 22:59 GMT-03:00 Brian Carrier <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
> 
> 
> <istat_of_dir1.txt><$I30_of_dir2_parent>------------------------------------------------------------------------------
> 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=278785471&iu=/4140_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Using TSK from Java without SQLite

[Simson G. <si...@ac...>]

TSK is written in C/C++ and can be called natively.

See: http://www.sleuthkit.org/sleuthkit/docs/framework-docs/

For examples, you could look at the fiwalk source code, e.g.:
https://github.com/sleuthkit/sleuthkit/blob/develop/tools/fiwalk/src/fiwalk_tsk.cpp

On Mon, Apr 4, 2016 at 1:27 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
> You can try Stuart's tsk4j java bindings:
>
> https://github.com/uw-dims/tsk4j/
>
> Luis
>
> 2016-04-04 13:40 GMT-03:00 Robert James <sro...@gm...>:
>>
>> I would like to use TSK from Java, but don't want to go through
>> SQLite.  Instead, without generating a SQLite databse, I'd like to use
>> TSK much as I would from C or C++.  Is this possible?
>>
>> Specifically, I'd like to:
>> * Enumerate all files (from the FS metadata)
>> * Iterate through each file's metadata and allocation info
>>
>> How do I do that?
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] FDE Version for Dell and Lenovo And Blackberry Decryption Services

[Data R. S. L. <in...@ni...>]

Hi,

 

We are the foremost professional and pioneer Data Recovery Company in West
Africa.  We recover lost data files as well as forensically investigate
incidents.

 

We got your name via a web search.

 

A I speak to you, we have two (2) cases (issues) needing expert level
assistance, hence this email to your team.  

 

Case 1:

A client had a meeting with my firm to ask if we can be of service to
decrypt all the laptops in the Company with lost encryption keys, the client
just forwarded these images to me to shed more lights on the encryption
technologies used by the Company.

 



 

 

Lenovo- 

 




Please advise your tools/services that can decrypt these encrypted SSDs.

 

Case 2:

 

We have 4 Blackberry Phones, ranging from a Blackberry Porsche Design
P'9981:  IMEI:  359850040348604, a Curve 9320, a Bold 9990, another Touch
9550. 

 

The customer reported inaccessibility, having forgotten the passcode to
them.

 

We gave the 4 phones to a firm in the UK who had carried out a chip-off
procedures on the phones in order to access the contents of the phones.
This UK firm could not get what the client wanted, although he got some
items, the client is particularly interested in the DELETED BBM and Whatsapp
chats, WebHistory, and ANY other deleted communications.

 

Kindly confirm your ability to handle these phones to recover specifically,
the deleted BBM/Whatsapp chats, images, and cookies, web history, and ALL
the deleted data items, although, he will also want the NOT-Yet Deleted to
be preserved as well.

 

If you can partner with us on this project, we will give you access to the
forensic images of the phones after we have formally executed a business
partnership and confidentiality agreement.  We have the encrypted
information store/images of the phones on our DropBox.

 

Please note that a UK Company has already carried out a chip-off by Jtag, on
the Blackberry phones, we have the images of the chipped off memory on a
dropbox which you can download and carry out your examination once you
confirm your capability to handle same.  

 

Please request for the Dropbox access to download the images if you wish to
deliver this service.

 

Case 3:

We have a client with a Ransomware infected machine, is there anyone in the
group who can unlock drives locked by a Ransomware?

 

Regards,

 

Bolanle O. Omotoso CGEIT, CISM, CISSP, CISA, API, MCSA, BS7799 LA, APS 
Ceo
Data Recovery Specialist Limited RC:660306

https://www.nigeriadatarecovery.com

3rd Floor, Right Wing, 240, Herbert Macaulay Way, Yaba, Lagos

#160, Aminu Kano Crescent, Wuse 2, FCT-Abuja.

Cell: 234-803-5639710

 

Re: [sleuthkit-users] Using TSK from Java without SQLite

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

You can try Stuart's tsk4j java bindings:

https://github.com/uw-dims/tsk4j/

Luis

2016-04-04 13:40 GMT-03:00 Robert James <sro...@gm...>:

> I would like to use TSK from Java, but don't want to go through
> SQLite.  Instead, without generating a SQLite databse, I'd like to use
> TSK much as I would from C or C++.  Is this possible?
>
> Specifically, I'd like to:
> * Enumerate all files (from the FS metadata)
> * Iterate through each file's metadata and allocation info
>
> How do I do that?
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] Using TSK from Java without SQLite

[Robert J. <sro...@gm...>]

I would like to use TSK from Java, but don't want to go through
SQLite.  Instead, without generating a SQLite databse, I'd like to use
TSK much as I would from C or C++.  Is this possible?

Specifically, I'd like to:
* Enumerate all files (from the FS metadata)
* Iterate through each file's metadata and allocation info

How do I do that?

Re: [sleuthkit-users] Different results between tsk_loaddb and java AddImageProcess

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

Hi,

Any updates here? I can submit a patch to add a command line option to
group non adjacent unallocated blocks without changing default behaviour.

Regards,
Luis

2015-12-09 19:30 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:

> I AM exactly doing that in a forensic APP I developed: breaking big
> virtual unallocated files into smaller ones to do multithreaded carving and
> to do fast indexed searches and highlighting.
>
> Att.
> Luís Nassif
> Em 09/12/2015 13:40, "Brian Carrier" <ca...@sl...> escreveu:
>
>> We could change the default behavior and add a command line argument to
>> change it.
>>
>> Any objections to grouping unallocated space?
>>
>> As a side note (and we recently ran into this with some images in
>> Autopsy) is that the current algorithm will break the groups of unallocated
>> space at a sector boundary with an allocated sector. If there is 100GB of
>> contagious unallocated space, the resulting file will be 100GB.   We will
>> probably change the algorithm to do something like try to break it at 500MB
>> at a natural boundary, but definitely stop 10% later if there isn’t one.
>>
>>
>>
>>
>>
>> > On Dec 8, 2015, at 6:58 AM, Luís Filipe Nassif <lfc...@gm...>
>> wrote:
>> >
>> > Hi,
>> >
>> > Those 2 commands are populating the sqlite database with different
>> number of unallocated entries. Reading the code, the java command was
>> configured to group non adjacent unallocated clusters up to 500 MB, while
>> tsk_loaddb groups only adjacent blocks. Tsk_loaddb produced a sqlite with
>> 26 millions of unallocated entries in a specific case. I think those 2
>> commands should return the same output, and I prefer the java one, because
>> it makes caving fragmented files easier.
>> >
>> > Regards,
>> > Luis Nassif
>> >
>> ------------------------------------------------------------------------------
>> > Go from Idea to Many App Stores Faster with Intel(R) XDK
>> > Give your users amazing mobile app experiences with Intel(R) XDK.
>> > Use one codebase in this all-in-one HTML5 development environment.
>> > Design, debug & build mobile apps & 2D/3D high-impact games for
>> multiple OSs.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140_______________________________________________
>> > sleuthkit-users mailing list
>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> > http://www.sleuthkit.org
>>
>>

Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2

[Jon S. <JSt...@St...>]

That would be nice, but TSK_FS_ATTR.id is a uint16_t. I'm fine with recompiling, but that might break things for others.


Jon

> -----Original Message-----
> From: Simson Garfinkel [mailto:si...@gm...] On Behalf Of Simson
> Garfinkel
> Sent: Tuesday, March 29, 2016 5:08 PM
> To: Jon Stewart
> Cc: Brian Carrier; sleuthkit-users
> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
> 
> I like byte offset from the beginning of the drive as a nice organic unique ID.
> It can be the byte offset of the metadata....
> 
> > On Mar 29, 2016, at 5:03 PM, Jon Stewart <JSt...@St...>
> wrote:
> >
> > A unique ID would be very helpful. My use case is that I'm trying to map out
> which ranges of the disk are associated with given (inode, attribute) pairs.
> Without a unique attribute ID, I can't trust that process.
> >
> > When there isn't a nice organic attribute ID from the filesystem itself (as
> with NTFS), I'd be happy with a simple per-inode counter serving as the ID.
> >
> >
> > Jon
> >
> >> -----Original Message-----
> >> From: Brian Carrier [mailto:ca...@sl...]
> >> Sent: Monday, March 28, 2016 9:58 PM
> >> To: Jon Stewart
> >> Cc: sleuthkit-users
> >> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
> >>
> >> Hey Jon,
> >>
> >> Those docs should certainly be updated.  There is another comment
> about:
> >>
> >> #define TSK_FS_ATTR_ID_DEFAULT  0       ///< Default Data ID used if file
> >> system does not assign one.
> >>
> >> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the
> easiest
> >> thing is to update the docs as you suggested. Do you have a use case
> where
> >> having an ID would be useful?  It would probably not be much work to
> make
> >> that happen if it is important.
> >>
> >> thanks,
> >> brian
> >>
> >>
> >>> On Mar 28, 2016, at 3:57 PM, Jon Stewart
> <JSt...@St...>
> >> wrote:
> >>>
> >>> The docs say:
> >>>
> >>> "Each attribute has a type and an ID. The types are defined in the
> >> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is
> unique
> >> to the file. A file can have multiple attributes with the same type, but it
> can
> >> have only one attribute with a given id."
> >>>
> >>> But I have an ext2 filesystem, some simple test evidence, where many
> files
> >> have two different attributes with id == 0. The docs also say that "TSK
> stores
> >> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
> >> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
> >> presumably such attributes contain the pointers for indirect blocks. It
> looks
> >> like these types of attributes also do not respect the uniqueness of
> attribute
> >> IDs.
> >>>
> >>> My guess is that the docs should be updated to reflect that attribute ID is
> >> unique only for given types, although it sure would be convenient to have
> a
> >> unique attribute ID regardless of type.
> >>>
> >>> Example:
> >>>
> >>> "attrs":[
> >>> {
> >>> "flags":"In Use, Non resident",
> >>> "id":0,
> >>> "name":"",
> >>> "size":348576,
> >>> "type":1,
> >>> "rd_buf_size":0,
> >>> "nrd_allocsize":352256,
> >>> "nrd_compsize":0,
> >>> "nrd_initsize":348576,
> >>> "nrd_skiplen":0,
> >>> "nrd_runs":[
> >>>     {"addr":34009,"flags":"","len":12,"offset":0},
> >>>     {"addr":34022,"flags":"","len":74,"offset":12},
> >>>     {"addr":0,"flags":"Sparse","len":950,"offset":86}
> >>> ]
> >>> },
> >>> {
> >>> "flags":"In Use, Non-resident",
> >>> "id":0,
> >>> "name":"",
> >>> "size":4096,
> >>> "type":4097,
> >>> "rd_buf_size":0,
> >>> "nrd_allocsize":4096,
> >>> "nrd_compsize":0,
> >>> "nrd_initsize":4096,
> >>> "nrd_skiplen":0,
> >>> "nrd_runs":[
> >>>     {"addr":34021,"flags":"","len":1,"offset":0}
> >>> ]
> >>> }]
> >>>
> >>>
> >>> Jon Stewart
> >>> Development Manager
> >>>
> >>> STROZ FRIEDBERG
> >>> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
> >>>
> >>> T: +1 202.534.3290
> >>> M: +1 202.492.4412
> >>> F: +1 202.534.5700
> >>> JSt...@St...   www.strozfriedberg.com
> >>>
> >>> This message and/or its attachments may contain information that is
> >> confidential and/or protected by privilege from disclosure. If you have
> >> reason to believe you are not the intended recipient, please immediately
> >> notify the sender by reply e-mail or by telephone, then delete this
> message
> >> (and any attachments), as well as all copies, including any printed copies.
> >> Thank you.
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> 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=278785471&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=278785471&iu=/4140
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org

Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2

[Simson G. <si...@ac...>]

I like byte offset from the beginning of the drive as a nice organic unique ID. It can be the byte offset of the metadata....

> On Mar 29, 2016, at 5:03 PM, Jon Stewart <JSt...@St...> wrote:
> 
> A unique ID would be very helpful. My use case is that I'm trying to map out which ranges of the disk are associated with given (inode, attribute) pairs. Without a unique attribute ID, I can't trust that process.
> 
> When there isn't a nice organic attribute ID from the filesystem itself (as with NTFS), I'd be happy with a simple per-inode counter serving as the ID.
> 
> 
> Jon
> 
>> -----Original Message-----
>> From: Brian Carrier [mailto:ca...@sl...]
>> Sent: Monday, March 28, 2016 9:58 PM
>> To: Jon Stewart
>> Cc: sleuthkit-users
>> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
>> 
>> Hey Jon,
>> 
>> Those docs should certainly be updated.  There is another comment about:
>> 
>> #define TSK_FS_ATTR_ID_DEFAULT  0       ///< Default Data ID used if file
>> system does not assign one.
>> 
>> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest
>> thing is to update the docs as you suggested. Do you have a use case where
>> having an ID would be useful?  It would probably not be much work to make
>> that happen if it is important.
>> 
>> thanks,
>> brian
>> 
>> 
>>> On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...>
>> wrote:
>>> 
>>> The docs say:
>>> 
>>> "Each attribute has a type and an ID. The types are defined in the
>> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique
>> to the file. A file can have multiple attributes with the same type, but it can
>> have only one attribute with a given id."
>>> 
>>> But I have an ext2 filesystem, some simple test evidence, where many files
>> have two different attributes with id == 0. The docs also say that "TSK stores
>> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
>> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
>> presumably such attributes contain the pointers for indirect blocks. It looks
>> like these types of attributes also do not respect the uniqueness of attribute
>> IDs.
>>> 
>>> My guess is that the docs should be updated to reflect that attribute ID is
>> unique only for given types, although it sure would be convenient to have a
>> unique attribute ID regardless of type.
>>> 
>>> Example:
>>> 
>>> "attrs":[
>>> {
>>> "flags":"In Use, Non resident",
>>> "id":0,
>>> "name":"",
>>> "size":348576,
>>> "type":1,
>>> "rd_buf_size":0,
>>> "nrd_allocsize":352256,
>>> "nrd_compsize":0,
>>> "nrd_initsize":348576,
>>> "nrd_skiplen":0,
>>> "nrd_runs":[
>>>     {"addr":34009,"flags":"","len":12,"offset":0},
>>>     {"addr":34022,"flags":"","len":74,"offset":12},
>>>     {"addr":0,"flags":"Sparse","len":950,"offset":86}
>>> ]
>>> },
>>> {
>>> "flags":"In Use, Non-resident",
>>> "id":0,
>>> "name":"",
>>> "size":4096,
>>> "type":4097,
>>> "rd_buf_size":0,
>>> "nrd_allocsize":4096,
>>> "nrd_compsize":0,
>>> "nrd_initsize":4096,
>>> "nrd_skiplen":0,
>>> "nrd_runs":[
>>>     {"addr":34021,"flags":"","len":1,"offset":0}
>>> ]
>>> }]
>>> 
>>> 
>>> Jon Stewart
>>> Development Manager
>>> 
>>> STROZ FRIEDBERG
>>> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
>>> 
>>> T: +1 202.534.3290
>>> M: +1 202.492.4412
>>> F: +1 202.534.5700
>>> JSt...@St...   www.strozfriedberg.com
>>> 
>>> This message and/or its attachments may contain information that is
>> confidential and/or protected by privilege from disclosure. If you have
>> reason to believe you are not the intended recipient, please immediately
>> notify the sender by reply e-mail or by telephone, then delete this message
>> (and any attachments), as well as all copies, including any printed copies.
>> Thank you.
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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=278785471&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=278785471&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2

[Jon S. <JSt...@St...>]

A unique ID would be very helpful. My use case is that I'm trying to map out which ranges of the disk are associated with given (inode, attribute) pairs. Without a unique attribute ID, I can't trust that process.

When there isn't a nice organic attribute ID from the filesystem itself (as with NTFS), I'd be happy with a simple per-inode counter serving as the ID.


Jon

> -----Original Message-----
> From: Brian Carrier [mailto:ca...@sl...]
> Sent: Monday, March 28, 2016 9:58 PM
> To: Jon Stewart
> Cc: sleuthkit-users
> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
>
> Hey Jon,
>
> Those docs should certainly be updated.  There is another comment about:
>
> #define TSK_FS_ATTR_ID_DEFAULT  0       ///< Default Data ID used if file
> system does not assign one.
>
> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest
> thing is to update the docs as you suggested. Do you have a use case where
> having an ID would be useful?  It would probably not be much work to make
> that happen if it is important.
>
> thanks,
> brian
>
>
> > On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...>
> wrote:
> >
> > The docs say:
> >
> > "Each attribute has a type and an ID. The types are defined in the
> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique
> to the file. A file can have multiple attributes with the same type, but it can
> have only one attribute with a given id."
> >
> > But I have an ext2 filesystem, some simple test evidence, where many files
> have two different attributes with id == 0. The docs also say that "TSK stores
> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
> presumably such attributes contain the pointers for indirect blocks. It looks
> like these types of attributes also do not respect the uniqueness of attribute
> IDs.
> >
> > My guess is that the docs should be updated to reflect that attribute ID is
> unique only for given types, although it sure would be convenient to have a
> unique attribute ID regardless of type.
> >
> > Example:
> >
> > "attrs":[
> > {
> >  "flags":"In Use, Non resident",
> >  "id":0,
> >  "name":"",
> >  "size":348576,
> >  "type":1,
> >  "rd_buf_size":0,
> >  "nrd_allocsize":352256,
> >  "nrd_compsize":0,
> >  "nrd_initsize":348576,
> >  "nrd_skiplen":0,
> >  "nrd_runs":[
> >      {"addr":34009,"flags":"","len":12,"offset":0},
> >      {"addr":34022,"flags":"","len":74,"offset":12},
> >      {"addr":0,"flags":"Sparse","len":950,"offset":86}
> >  ]
> > },
> > {
> >  "flags":"In Use, Non-resident",
> >  "id":0,
> >  "name":"",
> >  "size":4096,
> >  "type":4097,
> >  "rd_buf_size":0,
> >  "nrd_allocsize":4096,
> >  "nrd_compsize":0,
> >  "nrd_initsize":4096,
> >  "nrd_skiplen":0,
> >  "nrd_runs":[
> >      {"addr":34021,"flags":"","len":1,"offset":0}
> >  ]
> > }]
> >
> >
> > Jon Stewart
> > Development Manager
> >
> > STROZ FRIEDBERG
> > 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
> >
> > T: +1 202.534.3290
> > M: +1 202.492.4412
> > F: +1 202.534.5700
> > JSt...@St...   www.strozfriedberg.com
> >
> > This message and/or its attachments may contain information that is
> confidential and/or protected by privilege from disclosure. If you have
> reason to believe you are not the intended recipient, please immediately
> notify the sender by reply e-mail or by telephone, then delete this message
> (and any attachments), as well as all copies, including any printed copies.
> Thank you.
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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=278785471&iu=/4140
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org

Re: [sleuthkit-users] Failed to connect to Solr server

[Karl M. <kmo...@ba...>]

Which version of Autopsy are you using?

Are you using Multi-user cases? If so, you must use a UNC path for the
"Base Directory" (the output folder), or Solr won't be able to find the
folder to write to it.

If you have that right, the next thing to check is the IP and port of your
Solr server in Multi-user Settings. It sounds to me like they are not
right, or your Solr service isn't up and running. If you click the Test
button next to Solr Settings, do you get a green check mark or a red dash?

Sincerely,
  Karl



On Tue, Mar 29, 2016 at 1:49 PM, Frank _ <ffr...@ho...> wrote:

> Hi guys,
>
> For an unknown reason, I cannot run the keyword search module anymore.
> Everytime I open or create a new case, I have the same error message which
> is "Failed to connect to Solr server".
>
> I'm running on Win7 64bits.
>
> The log shows this line which I'm not sure is related to my problem:
>
> WARNING [org.netbeans.ProxyClassLoader]: Will not load class
> org.apache.commons.logging.impl.Log4JLogger arbitrarily from one of
> ModuleCL@51c015f1[org.sleuthkit.autopsy.corelibs] and ModuleCL@4c8c6565[org.sleuthkit.autopsy.keywordsearch]
> starting from SystemClassLoader[63 modules]; see
> http://wiki.netbeans.org/DevFaqModuleCCE
>
> It's driving me nuts! I've tried everything and nothing worked. The
> keyword module worked for the first time in weeks yesterday and it's not
> working anymore today... and I've done nothing since yesterday, not even
> shutting down the computer.
>
> Thanks!
>
>
>
>
> ------------------------------------------------------------------------------
> 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=278785471&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] Failed to connect to Solr server

[Frank _ <ffr...@ho...>]

Hi guys,

For an unknown reason, I cannot run the keyword search module anymore. Everytime I open or create a new case, I have the same error message which is "Failed to connect to Solr server".

I'm running on Win7 64bits.

The log shows this line which I'm not sure is related to my problem:

WARNING [org.netbeans.ProxyClassLoader]: Will not load class org.apache.commons.logging.impl.Log4JLogger arbitrarily from one of ModuleCL@51c015f1[org.sleuthkit.autopsy.corelibs] and ModuleCL@4c8c6565[org.sleuthkit.autopsy.keywordsearch] starting from SystemClassLoader[63 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE

It's driving me nuts! I've tried everything and nothing worked. The keyword module worked for the first time in weeks yesterday and it's not working anymore today... and I've done nothing since yesterday, not even shutting down the computer. 

Thanks!


 		 	   		  

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

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

MFT Entry Header Values:
Entry: 24765        Sequence: 514
$LogFile Sequence Number: 18426169393
Allocated Directory
Links: 2

$STANDARD_INFORMATION Attribute Values:
Flags: 
Owner ID: 0
Security ID: 1915  (S-1-5-21-1420377728-1435070833-5377028-1000)
Last User Journal Update Sequence Number: 3021062824
Created:	2014-01-21 22:25:14.139789800 (HorFile Modified:	2014-03-10 13:56:09.287806600 (Hora oficial do Brasil)
MFT Modified:	2014-03-23 16:48:56.241901700 (Hora oficial do Brasil)
Accessed:	2014-03-10 13:56:09.287806600 (Hora oficial do Brasil)

$FILE_NAME Attribute Values:
Flags: Directory
Name: 2001 FI
Parent MFT Entry: 260633 	Sequence: 2
Allocated Size: 0   	Actual Size: 0
Created:	2014-01-21 22:25:14.139789800 (HorFile Modified:	2014-03-10 13:56:09.287806600 (Hora oficial do Brasil)
MFT Modified:	2014-03-10 13:56:09.287806600 (Hora oficial do Brasil)
Accessed:	2014-03-10 13:56:09.287806600 (Hora oficial do Brasil)

$OBJECT_ID Attribute Values:
Object Id: abdbf634-2b90-34a7-11e3-88342f05a13b

Attributes: 
Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72
Type: $FILE_NAME (48-13)   Name: N/A   Resident   size: 80
Type: $FILE_NAME (48-14)   Name: N/A   Resident   size: 82
Type: $OBJECT_ID (64-10)   Name: N/A   Resident   size: 16
Type: $INDEX_ROOT (144-9)   Name: $I30   Resident   size: 176
Type: $INDEX_ALLOCATION (160-7)   Name: $I30   Non-Resident   size: 12288  init_size: 12288
1037942 1037943 1037944 
Type: $BITMAP (176-8)   Name: $I30   Resident   size: 8

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

Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2

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

Hey Jon,

Those docs should certainly be updated.  There is another comment about:

#define TSK_FS_ATTR_ID_DEFAULT  0       ///< Default Data ID used if file system does not assign one.

And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest thing is to update the docs as you suggested. Do you have a use case where having an ID would be useful?  It would probably not be much work to make that happen if it is important.

thanks,
brian
 

> On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...> wrote:
> 
> The docs say:
> 
> "Each attribute has a type and an ID. The types are defined in the TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique to the file. A file can have multiple attributes with the same type, but it can have only one attribute with a given id."
> 
> But I have an ext2 filesystem, some simple test evidence, where many files have two different attributes with id == 0. The docs also say that "TSK stores UFS and ExtX indirect blocks in separate attribute. [sic]" With these files there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so presumably such attributes contain the pointers for indirect blocks. It looks like these types of attributes also do not respect the uniqueness of attribute IDs.
> 
> My guess is that the docs should be updated to reflect that attribute ID is unique only for given types, although it sure would be convenient to have a unique attribute ID regardless of type.
> 
> Example:
> 
> "attrs":[
> {
>  "flags":"In Use, Non resident",
>  "id":0,
>  "name":"",
>  "size":348576,
>  "type":1,
>  "rd_buf_size":0,
>  "nrd_allocsize":352256,
>  "nrd_compsize":0,
>  "nrd_initsize":348576,
>  "nrd_skiplen":0, 
>  "nrd_runs":[
>      {"addr":34009,"flags":"","len":12,"offset":0}, 
>      {"addr":34022,"flags":"","len":74,"offset":12}, 
>      {"addr":0,"flags":"Sparse","len":950,"offset":86}
>  ]
> }, 
> {
>  "flags":"In Use, Non-resident",
>  "id":0,
>  "name":"",
>  "size":4096,
>  "type":4097,
>  "rd_buf_size":0,
>  "nrd_allocsize":4096,
>  "nrd_compsize":0,
>  "nrd_initsize":4096,
>  "nrd_skiplen":0, 
>  "nrd_runs":[
>      {"addr":34021,"flags":"","len":1,"offset":0}
>  ]
> }]
> 
> 
> Jon Stewart
> Development Manager
> 
> STROZ FRIEDBERG
> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
> 
> T: +1 202.534.3290
> M: +1 202.492.4412
> F: +1 202.534.5700
> JSt...@St...   www.strozfriedberg.com
> 
> This message and/or its attachments may contain information that is confidential and/or protected by privilege from disclosure. If you have reason to believe you are not the intended recipient, please immediately notify the sender by reply e-mail or by telephone, then delete this message (and any attachments), as well as all copies, including any printed copies. Thank you.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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=278785471&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2

[Jon S. <JSt...@St...>]

The docs say:

"Each attribute has a type and an ID. The types are defined in the TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique to the file. A file can have multiple attributes with the same type, but it can have only one attribute with a given id."

But I have an ext2 filesystem, some simple test evidence, where many files have two different attributes with id == 0. The docs also say that "TSK stores UFS and ExtX indirect blocks in separate attribute. [sic]" With these files there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so presumably such attributes contain the pointers for indirect blocks. It looks like these types of attributes also do not respect the uniqueness of attribute IDs.

My guess is that the docs should be updated to reflect that attribute ID is unique only for given types, although it sure would be convenient to have a unique attribute ID regardless of type.

Example:

"attrs":[
{
  "flags":"In Use, Non resident",
  "id":0,
  "name":"",
  "size":348576,
  "type":1,
  "rd_buf_size":0,
  "nrd_allocsize":352256,
  "nrd_compsize":0,
  "nrd_initsize":348576,
  "nrd_skiplen":0, 
  "nrd_runs":[
      {"addr":34009,"flags":"","len":12,"offset":0}, 
      {"addr":34022,"flags":"","len":74,"offset":12}, 
      {"addr":0,"flags":"Sparse","len":950,"offset":86}
  ]
}, 
{
  "flags":"In Use, Non-resident",
  "id":0,
  "name":"",
  "size":4096,
  "type":4097,
  "rd_buf_size":0,
  "nrd_allocsize":4096,
  "nrd_compsize":0,
  "nrd_initsize":4096,
  "nrd_skiplen":0, 
  "nrd_runs":[
      {"addr":34021,"flags":"","len":1,"offset":0}
  ]
}]


Jon Stewart
Development Manager

STROZ FRIEDBERG
1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036

T: +1 202.534.3290
M: +1 202.492.4412
F: +1 202.534.5700
JSt...@St...   www.strozfriedberg.com

This message and/or its attachments may contain information that is confidential and/or protected by privilege from disclosure. If you have reason to believe you are not the intended recipient, please immediately notify the sender by reply e-mail or by telephone, then delete this message (and any attachments), as well as all copies, including any printed copies. Thank you.

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

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

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

[Luís F. N. <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
>
>

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

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

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

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

[Alex N. <ajn...@cs...>]

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

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

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

[Simson G. <si...@ac...>]

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