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

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

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

Hi,

The recent changes (from commit a725989 to 0432598) resolved the bug for my
2 problematic images and for my colleague's image, thank you all very much!
But with another image, the changes are causing a few files to be
discarded, returning the following message: "Error: Database Error
(TskDbSqlite::findParObjId: Error selecting file id by meta_addr: unknown
error (result code 101)"

For some reason the sql query did not find some parents in the database...
I don't know why (maybe the parents are not there?) Might those lost files
go into Orphan dir?

Thanks,
Luis

2016-06-06 18:09 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:

> Hi,
>
> It is not related directly to this issue, but I discovered, based on
> Microsoft docs (
> https://msdn.microsoft.com/en-us/library/bb470124(v=vs.85).aspx), that
> the sequence number is incremented when the file record is freed and not
> when it is reused. I think that may affect the relationship between deleted
> children and their parent, but I do not tried to confirm it.
>
> Best,
> Luis
>
> 2016-05-02 15:19 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>
>> Hi,
>>
>> I applied the patch locally and it resolved the problem. Tested with one
>> of my cases.
>>
>> Thank you very much for all the attention!
>> Luis
>>
>>
>> 2016-05-02 9:20 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>>
>>> Hi Brian,
>>>
>>> I will gladly build and test the db_cache_uses_path branch and post
>>> results here.
>>>
>>> Thank you,
>>> Luis
>>>
>>> 2016-05-01 21:32 GMT-03:00 Brian Carrier <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
>>>>
>>>>
>>>
>>
>

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

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

hi Ronaldo,

I think you are seeing the same bug that “SuperGod” reported (https://github.com/sleuthkit/sleuthkit/issues/651) and gave a patch for. The fix is in the release-4.3.0 branch.  If you are not compiling from source, I can send you a windows binary to test it out to make sure it fixes your problems.  Please let me know.

thanks,
brian

> On Jun 8, 2016, at 10:17 AM, PCF Ronaldo R. Costa <ron...@dp...> wrote:
> 
> Hi Brian,
> 
> I am not sure, but it seems to be a exFat or at least Fat. It doesn´t look like NTFS. Curiously, there are files typical of Mac OS or Apple Timemachine device (Fsevend, spotlight, timemachine). This device is an external drive of 2TB. I have attached some pictures of file system folders/files (I had to blur some parts, because are sensitive).
> 
> Dump of sector 64 is attached too.
> 
> Thanks,
> 
> -- 
> Ronaldo Rosenau da Costa
> Perito Criminal Federal
> Setor Técnico Científico (SETEC)
> Departamento de Polícia Federal - Paraná
> Tel: (41) 3251-7651
> Voip: 4 4100-7651
> 
> On 07/06/2016 15:56, Brian Carrier wrote:
>> From the verbose log, these seem to be the relevant lines:
>> 
>> fsopen: Auto detection mode at offset 32768
>> ntfs_open: invalid sector size: 0
>> fatxxfs_open: Invalid sector size (0)
>> exfatfs_get_fs_layout: Invalid root directory sector address (122880)
>> ….
>> 
>> So, both ExFAT and NTFS are unhappy because sector size is 0 and ExFAT is also unhappy because it doesn’t like the starting root directory address. Can you tell from FTK / EnCase what the file system is?  Usually NTFS has more $ files in the root folder.   If you could send me the raw contents of sector 64 (or a picture of the  hex dump) that would be useful too to debug this.
>> 
>> thanks
>> brian
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jun 6, 2016, at 3:48 PM, PCF Ronaldo R. Costa <ron...@dp...> wrote:
>>> 
>>> Hi,
>>> 
>>> tsk_loaddb.exe aborted with message below:
>>> Error: Cannot determine file system type (Sector offset: 64, Partition
>>> Type: NTFS / exFAT (0x07))
>>> 
>>> I can open this image with FTK and Encase, without any problem.
>>> 
>>> Full verbose log is attached.
>>> 
>>> Any suggestion?
>>> 
>>> Regards,
>>> 
>>> --
>>> Ronaldo Rosenau da Costa
>>> Perito Criminal Federal
>>> Setor Técnico Científico (SETEC)
>>> Departamento de Polícia Federal - Paraná
>>> Tel: (41) 3251-7651
>>> Voip: 4 4100-7651
>>> 
>>> <report_item0906.txt>------------------------------------------------------------------------------
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>> 
>> 
> 
> <dump_sector_64><file_system.jpg><file_system2.jpg>

Re: [sleuthkit-users] [sleuthkit-developers] Upgrade to Visual Studio 2015

[Michael C. <scu...@gm...>]

Hi Brian,
Just as an FYI, pytsk uses VS 9.0 since that is the only supported compiler
for python 2.7. But we do not use any of the project files since python has
its own build system.

https://wiki.python.org/moin/WindowsCompilers

It would be good to keep the code itself compilable under this old version
which does not support later c standards.

Thanks
Michael.

On 9 Jun 2016 08:46, "Brian Carrier" <ca...@sl...> wrote:

> If you compile TSK with Visual Studio, you have to have use 2010, which
> has become dated and is a pain to get 64-bit builds out of. We’re thinking
> about moving to VS 2015 (still the free version).  Does this impact
> anyone?   Anyone building for source on Windows and want it to remain in
> 2010?
>
> brian
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

[sleuthkit-users] Upgrade to Visual Studio 2015

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

If you compile TSK with Visual Studio, you have to have use 2010, which has become dated and is a pain to get 64-bit builds out of. We’re thinking about moving to VS 2015 (still the free version).  Does this impact anyone?   Anyone building for source on Windows and want it to remain in 2010?

brian

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

[PCF R. R. C. <ron...@dp...>]

Hi Brian,

I am not sure, but it seems to be a exFat or at least Fat. It doesn´t 
look like NTFS. Curiously, there are files typical of Mac OS or Apple 
Timemachine device (Fsevend, spotlight, timemachine). This device is an 
external drive of 2TB. I have attached some pictures of file system 
folders/files (I had to blur some parts, because are sensitive).

Dump of sector 64 is attached too.

Thanks,

-- 
Ronaldo Rosenau da Costa
Perito Criminal Federal
Setor Técnico Científico (SETEC)
Departamento de Polícia Federal - Paraná
Tel: (41) 3251-7651
Voip: 4 4100-7651

On 07/06/2016 15:56, Brian Carrier wrote:
>  From the verbose log, these seem to be the relevant lines:
>
> fsopen: Auto detection mode at offset 32768
> ntfs_open: invalid sector size: 0
> fatxxfs_open: Invalid sector size (0)
> exfatfs_get_fs_layout: Invalid root directory sector address (122880)
> ….
>
> So, both ExFAT and NTFS are unhappy because sector size is 0 and ExFAT is also unhappy because it doesn’t like the starting root directory address. Can you tell from FTK / EnCase what the file system is?  Usually NTFS has more $ files in the root folder.   If you could send me the raw contents of sector 64 (or a picture of the  hex dump) that would be useful too to debug this.
>
> thanks
> brian
>
>
>
>
>
>
>
>> On Jun 6, 2016, at 3:48 PM, PCF Ronaldo R. Costa <ron...@dp...> wrote:
>>
>> Hi,
>>
>> tsk_loaddb.exe aborted with message below:
>> Error: Cannot determine file system type (Sector offset: 64, Partition
>> Type: NTFS / exFAT (0x07))
>>
>> I can open this image with FTK and Encase, without any problem.
>>
>> Full verbose log is attached.
>>
>> Any suggestion?
>>
>> Regards,
>>
>> --
>> Ronaldo Rosenau da Costa
>> Perito Criminal Federal
>> Setor Técnico Científico (SETEC)
>> Departamento de Polícia Federal - Paraná
>> Tel: (41) 3251-7651
>> Voip: 4 4100-7651
>>
>> <report_item0906.txt>------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
>

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

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

From the verbose log, these seem to be the relevant lines:

fsopen: Auto detection mode at offset 32768
ntfs_open: invalid sector size: 0
fatxxfs_open: Invalid sector size (0)
exfatfs_get_fs_layout: Invalid root directory sector address (122880)
….

So, both ExFAT and NTFS are unhappy because sector size is 0 and ExFAT is also unhappy because it doesn’t like the starting root directory address. Can you tell from FTK / EnCase what the file system is?  Usually NTFS has more $ files in the root folder.   If you could send me the raw contents of sector 64 (or a picture of the  hex dump) that would be useful too to debug this.

thanks
brian







> On Jun 6, 2016, at 3:48 PM, PCF Ronaldo R. Costa <ron...@dp...> wrote:
> 
> Hi,
> 
> tsk_loaddb.exe aborted with message below:
> Error: Cannot determine file system type (Sector offset: 64, Partition
> Type: NTFS / exFAT (0x07))
> 
> I can open this image with FTK and Encase, without any problem.
> 
> Full verbose log is attached.
> 
> Any suggestion?
> 
> Regards,
> 
> --
> Ronaldo Rosenau da Costa
> Perito Criminal Federal
> Setor Técnico Científico (SETEC)
> Departamento de Polícia Federal - Paraná
> Tel: (41) 3251-7651
> Voip: 4 4100-7651
> 
> <report_item0906.txt>------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] Account Number Searching

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

As part of our work with DHS S&T, we’re starting an effort to reduce false positives associated with searching for credit card numbers and other account numbers that are simply a series of numbers. We want to have a group of people that we can work with to bounce ideas off of. If you are interested in helping out and have experience with this problem in your cases, please let me know.

thanks,
brian

[sleuthkit-users] New software announcement

[Stuart M. <st...@ap...>]

For anyone who

(a) dabbles in Java,

(b) dabbles in the use of Virtual Machines and

(c) dabbles in disk-based forensics, as I am sure many do on this list,

you might find useful some code I have finally managed to get to a state 
worthy of an upload to github.  It's Java-based code to make virtual 
machine disk content available to host-based software, such as Sleuthkit.

Please see

https://github.com/UW-APL-EIS/vmvols-java/

Cheers

Stuart

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

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

Thank you, Ronaldo. I asked it to try to help tsk developers with deeper
tsk knowledge (not me unfortunatelly) to solve the problem.

Luis Nassif

2016-06-06 18:28 GMT-03:00 PCF Ronaldo R. Costa <ron...@dp...>:

> Hi Nassif,
>
> It seems to be what tsk_loaddb detected, a partition NTFS with a volume
> exFat.
>
> Follow mmls result and encase details about the problematic partition:
>
> === mmls ===
> DOS Partition Table
> Offset Sector: 0
> Units are in 512-byte sectors
>
>       Slot      Start        End          Length       Description
> 000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
> 001:  -------   0000000000   0000000063   0000000064   Unallocated
> 002:  000:000   0000000064   3907024128   3907024065   NTFS / exFAT (0x07)
> 003:  -------   3907024129   3907029167   0000005039   Unallocated
>
>
> ===== Encase ==========
> Serial Number    56D4-47DC
> Driver Information    exFAT 1.0     Used: 10%
>     Volume
> File System    exFat
> Sectors per cluster    256
> Bytes per sector    512
> Total Sectors    3.907.024.065
> Total Capacity    2.000.396.222.464 Bytes (1,8 TB)
> Total Clusters    15.261.812
> Unallocated    1.794.455.240.704 Bytes (1,6 TB)
> Free Clusters    13.690.607
> Allocated    205.940.981.760 Bytes (191,8 GB)
> Volume Offset    64
> Drive Type    Fixed
>     Partition
> Id    07
> Type    NTFS
> Start Sector    64
> Total Sectors    3.907.024.065
>
> --
> Ronaldo Rosenau da Costa
> Perito Criminal Federal
> Setor Técnico Científico (SETEC)
> Departamento de Polícia Federal - Paraná
> Tel: (41) 3251-7651
> Voip: 4 4100-7651
>
> --
> Ronaldo Rosenau da Costa
> Perito Criminal Federal
> Setor Técnico Científico (SETEC)
> Departamento de Polícia Federal - Paraná
> Tel: (41) 3251-7651
> Voip: 4 4100-7651
>
> On 06/06/2016 17:26, Luís Filipe Nassif wrote:
>
> Hi Ronaldo,
>
> Do you know what is the true file system type?
>
> Regards,
> Luis Nassif
>
> 2016-06-06 16:48 GMT-03:00 PCF Ronaldo R. Costa <ron...@dp...>:
>
>> Hi,
>>
>> tsk_loaddb.exe aborted with message below:
>> Error: Cannot determine file system type (Sector offset: 64, Partition
>> Type: NTFS / exFAT (0x07))
>>
>> I can open this image with FTK and Encase, without any problem.
>>
>> Full verbose log is attached.
>>
>> Any suggestion?
>>
>> Regards,
>>
>> --
>> Ronaldo Rosenau da Costa
>> Perito Criminal Federal
>> Setor Técnico Científico (SETEC)
>> Departamento de Polícia Federal - Paraná
>> Tel: (41) 3251-7651
>> Voip: 4 4100-7651
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports.
>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

[PCF R. R. C. <ron...@dp...>]

Hi Nassif,

It seems to be what tsk_loaddb detected, a partition NTFS with a volume 
exFat.

Follow mmls result and encase details about the problematic partition:

=== mmls ===
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

       Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000000063   0000000064   Unallocated
002:  000:000   0000000064   3907024128   3907024065   NTFS / exFAT (0x07)
003:  -------   3907024129   3907029167   0000005039   Unallocated


===== Encase ==========
Serial Number    56D4-47DC
Driver Information    exFAT 1.0     Used: 10%
     Volume
File System    exFat
Sectors per cluster    256
Bytes per sector    512
Total Sectors    3.907.024.065
Total Capacity    2.000.396.222.464 Bytes (1,8 TB)
Total Clusters    15.261.812
Unallocated    1.794.455.240.704 Bytes (1,6 TB)
Free Clusters    13.690.607
Allocated    205.940.981.760 Bytes (191,8 GB)
Volume Offset    64
Drive Type    Fixed
     Partition
Id    07
Type    NTFS
Start Sector    64
Total Sectors    3.907.024.065

-- 
Ronaldo Rosenau da Costa
Perito Criminal Federal
Setor Técnico Científico (SETEC)
Departamento de Polícia Federal - Paraná
Tel: (41) 3251-7651
Voip: 4 4100-7651

-- 
Ronaldo Rosenau da Costa
Perito Criminal Federal
Setor Técnico Científico (SETEC)
Departamento de Polícia Federal - Paraná
Tel: (41) 3251-7651
Voip: 4 4100-7651

On 06/06/2016 17:26, Luís Filipe Nassif wrote:
> Hi Ronaldo,
>
> Do you know what is the true file system type?
>
> Regards,
> Luis Nassif
>
> 2016-06-06 16:48 GMT-03:00 PCF Ronaldo R. Costa 
> <ron...@dp... <mailto:ron...@dp...>>:
>
>     Hi,
>
>     tsk_loaddb.exe aborted with message below:
>     Error: Cannot determine file system type (Sector offset: 64,
>     Partition Type: NTFS / exFAT (0x07))
>
>     I can open this image with FTK and Encase, without any problem.
>
>     Full verbose log is attached.
>
>     Any suggestion?
>
>     Regards,
>
>     -- 
>     Ronaldo Rosenau da Costa
>     Perito Criminal Federal
>     Setor Técnico Científico (SETEC)
>     Departamento de Polícia Federal - Paraná
>     Tel: (41) 3251-7651 <tel:%2841%29%203251-7651>
>     Voip: 4 4100-7651
>
>
>     ------------------------------------------------------------------------------
>     What NetFlow Analyzer can do for you? Monitors network bandwidth
>     and traffic
>     patterns at an interface-level. Reveals which users, apps, and
>     protocols are
>     consuming the most bandwidth. Provides multi-vendor support for
>     NetFlow,
>     J-Flow, sFlow and other flows. Make informed decisions using capacity
>     planning reports.
>     https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>     _______________________________________________
>     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,

It is not related directly to this issue, but I discovered, based on
Microsoft docs (
https://msdn.microsoft.com/en-us/library/bb470124(v=vs.85).aspx), that the
sequence number is incremented when the file record is freed and not when
it is reused. I think that may affect the relationship between deleted
children and their parent, but I do not tried to confirm it.

Best,
Luis

2016-05-02 15:19 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:

> Hi,
>
> I applied the patch locally and it resolved the problem. Tested with one
> of my cases.
>
> Thank you very much for all the attention!
> Luis
>
>
> 2016-05-02 9:20 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>
>> Hi Brian,
>>
>> I will gladly build and test the db_cache_uses_path branch and post
>> results here.
>>
>> Thank you,
>> Luis
>>
>> 2016-05-01 21:32 GMT-03:00 Brian Carrier <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
>>>
>>>
>>
>

Re: [sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

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

Hi Ronaldo,

Do you know what is the true file system type?

Regards,
Luis Nassif

2016-06-06 16:48 GMT-03:00 PCF Ronaldo R. Costa <ron...@dp...>:

> Hi,
>
> tsk_loaddb.exe aborted with message below:
> Error: Cannot determine file system type (Sector offset: 64, Partition
> Type: NTFS / exFAT (0x07))
>
> I can open this image with FTK and Encase, without any problem.
>
> Full verbose log is attached.
>
> Any suggestion?
>
> Regards,
>
> --
> Ronaldo Rosenau da Costa
> Perito Criminal Federal
> Setor Técnico Científico (SETEC)
> Departamento de Polícia Federal - Paraná
> Tel: (41) 3251-7651
> Voip: 4 4100-7651
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] tsk_loaddb: Cannot determine file system type (Sector offset: 64, Partition Type: NTFS / exFAT (0x07))

[PCF R. R. C. <ron...@dp...>]

Hi,

tsk_loaddb.exe aborted with message below:
Error: Cannot determine file system type (Sector offset: 64, Partition 
Type: NTFS / exFAT (0x07))

I can open this image with FTK and Encase, without any problem.

Full verbose log is attached.

Any suggestion?

Regards,

-- 
Ronaldo Rosenau da Costa
Perito Criminal Federal
Setor Técnico Científico (SETEC)
Departamento de Polícia Federal - Paraná
Tel: (41) 3251-7651
Voip: 4 4100-7651

[sleuthkit-users] OSDFCon CFP Reminder (now even if you can't attend)

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

The Call for Presentations for the Open Source Digital Forensics Conference (OSDFCon) ends on June 1 and we’ve just decided to have one presentation this year from someone who cannot physically attend the event.  If you have a talk that you want to give about a tool you’ve developed or used, but don’t have the budget to travel to Virginia, then you can still submit. This is a test to see if we can open the event to more people. 

All we need for the submission is an abstract about your software, use cases, or experiences.  Feel free to submit topics that were submitted in past years, but not chosen from the crowd sourcing. 

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

We’re also looking for more hands-on workshops.  A lot of attendees last year requested more hands on sessions, so if you can give a 3-hour workshop the day before, it would be a great way to get awareness for your software. 

thanks,
brian

[sleuthkit-users] Autopsy Meetup in Cambridge, MA

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

For those in the Boston area, we’re going to host a New England Autopsy User’s Meetup at the Basis Technology office in Cambridge, MA on June 8. There will be some talks on Autopsy and you can meet fellow users and developers (in addition to free food and drinks).     Please RSVP so that we can get an accurate headcount. 

    http://www.meetup.com/Autopsy-User-Group/

thanks,
brian

[sleuthkit-users] Autopsy 4 on GNU/Linux, Mac OS X

[Hoyt H. <hoy...@gm...>]

I know the subject line probably provokes groans and "not this again"
sentiments, so I apologize in advance. I'm looking for anyone actively
working to port Autopsy 4 fully to GNU/Linux and OS X distros. I want to
work with you to develop supported deb and rpm packages, as well as OS X
binaries, that keep up with the mainstream development cycle for Windows.

I'm convinced that there are enough of us with a definite interest in this
to make this happen. I started a new thread on the forum here:

http://forum.sleuthkit.org/viewtopic.php?f=8&t=2759

[sleuthkit-users] OSDFCon CFP 2 week Reminder

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

There are two weeks left to submit your presentation idea to the 7th Annual Open Source Digital Forensics conference (OSDFCon).  Attendees at the conference want to hear about:

	• How you are using open source tools
	• A new incident response or forensics tool that you've developed
	• Updates to an established tool

OSDFCon is a unique event where you can present your work to over 400 attendees who are interested in open source digital forensics tools.  

Abstract submissions are due by June 1.  Further CFP details are available here:

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


Autopsy Module Competition

The deadline for the Autopsy module competition is October 10, so you still have plenty of time to write a Python or Java module and compete for cash prizes.  Details, including a set of tutorials, are available here:

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


About OSDFCon 

OSDFCon is an annual one-day event that brings together practitioners and developers to talk about open source digital forensics tools.  This years event will be on October 26, 2016 in Herndon, VA and 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.  The event is free for government employees. 

Re: [sleuthkit-users] Wrong results when reading System Volume Shadow Files

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

Thank you Brian for the great explanation. I posted my comments at github
issue too.

Luis

2016-05-11 11:03 GMT-03:00 Brian Carrier <ca...@sl...>:

> I posted my comments on the github issue to have a central place for this:
>
> https://github.com/sleuthkit/sleuthkit/issues/466
>
> Basic take away is that the data is available right now if you use ‘icat
> -s’ to look at slack space (at least it was on my system).  Autopsy does
> not let you view this though, so this could bump that feature up in
> priority.   The suggested patch as it stands is too broad and would get rid
> of the idea of VDL slack for all files, which would be confusing. It should
> be restricted to just VSS files (as was already suggested), but then it
> could cause confusion between tools if those tools are reporting the
> initialized size as 0.
>
>
>
>
> > On May 3, 2016, at 12:27 PM, Luís Filipe Nassif <lfc...@gm...>
> wrote:
> >
> > Any chance of reviewing and committing Gabriel's patch before the next
> release?
> >
> > Luis
> >
> > 2016-01-25 23:06 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
> > Could a NTFS expert kindly take a look at Gabriel's patch? I think it is
> important to have a fix, so VSS files could be properly hashed, indexed,
> carved, etc.
> >
> > Luis
> >
> > 2016-01-18 9:11 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
> > Hum, maybe testing the file name for the presence of
> {3808876b-c176-4e48-b7ae-04046e6cc752} can restrict the patch only to VSS
> files?
> >
> > Luis
> >
> > 2016-01-16 20:16 GMT-02:00 Gabriel Francisco <gab...@gm...
> >:
> > Hi,
> >
> > I'm having problems too with Volume Shadow files at the TSK (icat,
> > istat), including TSK 4.2 (same behaviour indicated by Nassif). The
> > problem with this type of file is caused by the attribute "initialized
> > stream size" or "Valid Data Length size" (VDL size). Apparently,
> > Microsoft has forced it's value to zero to make these files
> > "invisible" to the normal Windows Backup process
> > (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/).
> >
> > I don't have much familiarity with the TSK code, but I wrote one
> > possible solution to this problem, altering the "tsk/fs/ntfs.c" file,
> > at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to
> > "ssize" when "initsize" it's equal to zero. But I don't know if this
> > solution will cause problems with other types of files (like sparse or
> > virtual files) in NTFS. I didn't find a way to limit this test only to
> > the Volume Shadow Files, but it worked properly in my few test images.
> >
> > I'm sending the patch attached only to illustrate my message, because
> > I think that other users or TSK developers could implement a better
> > solution to this problem.
> >
> > Other references related to this problem:
> > https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume
> > Shadow Copy Files incorrectly decoded]
> > http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ -
> > ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack
> > bug)
> > https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ -
> > [VDL Slack in NTFS – David G Ferguson]
> >
> > Gabriel
> >
> >
> > On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...>
> wrote:
> > > Did someone have time to look at the istat output? It is attached
> again.
> > >
> > > Thank you,
> > > Luis
> > >
> > >
> ------------------------------------------------------------------------------
> > > Dive into the World of Parallel Programming! The Go Parallel Website,
> > > sponsored by Intel and developed in partnership with Slashdot Media,
> is your
> > > hub for all things parallel software development, from weekly thought
> > > leadership blogs to news, videos, case studies, tutorials and more.
> Take a
> > > look and join the conversation now. http://goparallel.sourceforge.net
> > > _______________________________________________
> > > 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
>
>

Re: [sleuthkit-users] Wrong results when reading System Volume Shadow Files

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

I posted my comments on the github issue to have a central place for this:

https://github.com/sleuthkit/sleuthkit/issues/466

Basic take away is that the data is available right now if you use ‘icat -s’ to look at slack space (at least it was on my system).  Autopsy does not let you view this though, so this could bump that feature up in priority.   The suggested patch as it stands is too broad and would get rid of the idea of VDL slack for all files, which would be confusing. It should be restricted to just VSS files (as was already suggested), but then it could cause confusion between tools if those tools are reporting the initialized size as 0.




> On May 3, 2016, at 12:27 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
> 
> Any chance of reviewing and committing Gabriel's patch before the next release?
> 
> Luis
> 
> 2016-01-25 23:06 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
> Could a NTFS expert kindly take a look at Gabriel's patch? I think it is important to have a fix, so VSS files could be properly hashed, indexed, carved, etc.
> 
> Luis
> 
> 2016-01-18 9:11 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
> Hum, maybe testing the file name for the presence of {3808876b-c176-4e48-b7ae-04046e6cc752} can restrict the patch only to VSS files?
> 
> Luis
> 
> 2016-01-16 20:16 GMT-02:00 Gabriel Francisco <gab...@gm...>:
> Hi,
> 
> I'm having problems too with Volume Shadow files at the TSK (icat,
> istat), including TSK 4.2 (same behaviour indicated by Nassif). The
> problem with this type of file is caused by the attribute "initialized
> stream size" or "Valid Data Length size" (VDL size). Apparently,
> Microsoft has forced it's value to zero to make these files
> "invisible" to the normal Windows Backup process
> (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/).
> 
> I don't have much familiarity with the TSK code, but I wrote one
> possible solution to this problem, altering the "tsk/fs/ntfs.c" file,
> at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to
> "ssize" when "initsize" it's equal to zero. But I don't know if this
> solution will cause problems with other types of files (like sparse or
> virtual files) in NTFS. I didn't find a way to limit this test only to
> the Volume Shadow Files, but it worked properly in my few test images.
> 
> I'm sending the patch attached only to illustrate my message, because
> I think that other users or TSK developers could implement a better
> solution to this problem.
> 
> Other references related to this problem:
> https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume
> Shadow Copy Files incorrectly decoded]
> http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ -
> ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack
> bug)
> https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ -
> [VDL Slack in NTFS – David G Ferguson]
> 
> Gabriel
> 
> 
> On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...> wrote:
> > Did someone have time to look at the istat output? It is attached again.
> >
> > Thank you,
> > Luis
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > 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

Re: [sleuthkit-users] Timeline, Image Gallery, and ?

[Robert P. <rj...@gm...>]

Hi SleuthKit users...    Is there a way currently to do a Preview of an E01
or Live drive within SleuthKit without Creating a New Case, no ingest work
etc? ..   Just straight to the drives contents.  I find that because of the
size of the drives today I am doing a lot of previewing and working off of
a write blocker in-lieu of a full image.  I would like a quick way to get
in there and determine if the drive is worth imaging without jumping
through any hoops...

Thanks for your time and effort with TSK..

Rob


On Sun, May 1, 2016 at 8:51 PM, Brian Carrier <ca...@sl...> wrote:

> Hey All,
>
> As many of you know, the timeline, Image Gallery, and STIX modules in
> Autopsy have been funded by DHS Science and Technology (
> https://www.dhs.gov/science-and-technology/csd-forensics) with the idea
> of providing new functionality to the community (especially law
> enforcement) as part of a free, open source package.
>
> I’m emailing to ask for:
> - Feedback on these modules for things you want added or changed.
> - Success stories from law enforcement from using these modules.
> - Other modules and features that law enforcement would like to see
> included in Autopsy.
>
> You can send them directly to me.  Having this info helps to ensure we can
> continue to have these advanced features in Autopsy for free.
>
> You may have all noticed that we are WAY behind on Autopsy releases. It’s
> been over 6 months since our last one. We have lots of Timeline and Image
> Gallery changes in the new release (which should be out mid-May).
>
> thanks,
> brian
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [sleuthkit-users] Java bindings

[Stuart M. <st...@ap...>]

Just wondering if the user enquiring about use of Java for Sleuthkit
operations had any luck trying out tsk4j?  I made it available for
exactly that use case.

Cheers

Stuart

Re: [sleuthkit-users] Wrong results when reading System Volume Shadow Files

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

Any chance of reviewing and committing Gabriel's patch before the next
release?

Luis

2016-01-25 23:06 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:

> Could a NTFS expert kindly take a look at Gabriel's patch? I think it is
> important to have a fix, so VSS files could be properly hashed, indexed,
> carved, etc.
>
> Luis
>
> 2016-01-18 9:11 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
>
>> Hum, maybe testing the file name for the presence of
>> {3808876b-c176-4e48-b7ae-04046e6cc752} can restrict the patch only to VSS
>> files?
>>
>> Luis
>>
>> 2016-01-16 20:16 GMT-02:00 Gabriel Francisco <gab...@gm...>
>> :
>>
>>> Hi,
>>>
>>> I'm having problems too with Volume Shadow files at the TSK (icat,
>>> istat), including TSK 4.2 (same behaviour indicated by Nassif). The
>>> problem with this type of file is caused by the attribute "initialized
>>> stream size" or "Valid Data Length size" (VDL size). Apparently,
>>> Microsoft has forced it's value to zero to make these files
>>> "invisible" to the normal Windows Backup process
>>> (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/).
>>>
>>> I don't have much familiarity with the TSK code, but I wrote one
>>> possible solution to this problem, altering the "tsk/fs/ntfs.c" file,
>>> at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to
>>> "ssize" when "initsize" it's equal to zero. But I don't know if this
>>> solution will cause problems with other types of files (like sparse or
>>> virtual files) in NTFS. I didn't find a way to limit this test only to
>>> the Volume Shadow Files, but it worked properly in my few test images.
>>>
>>> I'm sending the patch attached only to illustrate my message, because
>>> I think that other users or TSK developers could implement a better
>>> solution to this problem.
>>>
>>> Other references related to this problem:
>>> https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume
>>> Shadow Copy Files incorrectly decoded]
>>> http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ -
>>> ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack
>>> bug)
>>> https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ -
>>> [VDL Slack in NTFS – David G Ferguson]
>>>
>>> Gabriel
>>>
>>>
>>> On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...>
>>> wrote:
>>> > Did someone have time to look at the istat output? It is attached
>>> again.
>>> >
>>> > Thank you,
>>> > Luis
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Dive into the World of Parallel Programming! The Go Parallel Website,
>>> > sponsored by Intel and developed in partnership with Slashdot Media,
>>> is your
>>> > hub for all things parallel software development, from weekly thought
>>> > leadership blogs to news, videos, case studies, tutorials and more.
>>> Take a
>>> > look and join the conversation now. http://goparallel.sourceforge.net
>>> > _______________________________________________
>>> > 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,

I applied the patch locally and it resolved the problem. Tested with one of
my cases.

Thank you very much for all the attention!
Luis

2016-05-02 9:20 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:

> Hi Brian,
>
> I will gladly build and test the db_cache_uses_path branch and post
> results here.
>
> Thank you,
> Luis
>
> 2016-05-01 21:32 GMT-03:00 Brian Carrier <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
>>
>>
>

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

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

Hi Brian,

I will gladly build and test the db_cache_uses_path branch and post results
here.

Thank you,
Luis

2016-05-01 21:32 GMT-03:00 Brian Carrier <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] Timeline, Image Gallery, and ?

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

Hey All,

As many of you know, the timeline, Image Gallery, and STIX modules in Autopsy have been funded by DHS Science and Technology (https://www.dhs.gov/science-and-technology/csd-forensics) with the idea of providing new functionality to the community (especially law enforcement) as part of a free, open source package. 

I’m emailing to ask for:
- Feedback on these modules for things you want added or changed.
- Success stories from law enforcement from using these modules.
- Other modules and features that law enforcement would like to see included in Autopsy.

You can send them directly to me.  Having this info helps to ensure we can continue to have these advanced features in Autopsy for free.

You may have all noticed that we are WAY behind on Autopsy releases. It’s been over 6 months since our last one. We have lots of Timeline and Image Gallery changes in the new release (which should be out mid-May).

thanks,
brian