sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy

[sleuthkit-developers] versioning

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

On 08/13/2015 10:13 AM,
sle...@li... wrote:
>
> Message: 2
> Date: Tue, 28 Jul 2015 09:41:15 -0400
> From: Brian Carrier <ca...@sl...>
> Subject: Re: [sleuthkit-developers] whither 4.2?
> To: Jon Stewart <JSt...@St...>
> Cc: "sle...@li..."
> 	<sle...@li...>
> Message-ID: <A21...@sl...>
> Content-Type: text/plain; charset=utf-8
>
> Hi Jon,
>
> Yea, I?m sorry about that. Whenever we do an Autopsy release, I always mean to do a TSK release too, but it falls off the list. 
>
> I?ll try to get a 4.2 release out this week.  In the early Fall, there will be new big releases of Autopsy and TSK that add collaboration features.  For TSK, that means support for PostgreSQL databases in addition to SQLite.  We?ll have to decide then if that means it is 4.3 or 4.2.1. 
>
> brian
>


Hi Brian, all,

I don't want to make trouble for you in versioning, but have you
considered following the idiom of semantic versioning
(http://semver.org)?  Though TSK has command line tools, it is also a
library (and thus an API) that users, myself included, write code
against.  Semver suggests that if a new release of the API breaks
compatibility with respect to existing code, its major number needs
changing etc.

What I like about semver is that if I know you are adhering to it, and I
see a Sleuthkit version 5.0 out, and my apps were coded against 4.3, I
KNOW to be wary of trying to link against 5.0, since I EXPECT api
incompatibilities.  I also EXPECT that linking against say 4.4 should be
fine for me, since all the functionality of 4.3 is preserved and that I
might want to look at the new features added to 4.4 from 4.3.

This all sounds very easy in theory and I can fully appreciated it's
never that easy in practice, but I thought it worth mentioning semver in
this arena.

Regards

Stuart

PS My own Java bindings for TSK, which have taken me 2 years to get
github-ready, are about to be put up on github.

Re: [sleuthkit-developers] Millions of orphan files found with sleuthkit develop branch

[Stefan P. <ste...@gm...>]

Hi Luis,

Could the NTFS image you're looking at be trimmed down and provided as
sample input to reproduce the problem ?

Best Regards,
Stefan

On Thu, Aug 13, 2015 at 8:05 PM, Luís Filipe Nassif <lfc...@gm...>
wrote:

> This error have happened again with a colleague's NTFS image, using the
> develop branch compiled about 1 month ago. Thousands of huge corrupted
> orphans were added by loaddb, which caused our processing application (and
> probably Autopsy too) to process indefinitely the evidence.
>
> Any help will be appreciated.
>
> Regards,
> Luis Nassif
>
>
> 2014-09-30 21:00 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>
>> This problem still happens with 4.2.0 branch. If I can help with some
>> more information, please let me know.
>>
>> Thanks
>> Luis
>>
>> 2014-07-24 9:21 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>>
>>> Another information: the sum of the millions of file sizes resulted in
>>> 1,1 petabyte, while the image has only 250 GB.
>>>
>>>
>>> 2014-07-23 22:21 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>>>
>>>> We tested loaddb of both the released 4.1.3 version and the develop
>>>> branch of sleuthkit on a NTFS image of a hard disk with a lot of bad
>>>> blocks, many of them at the beginning of the disk.
>>>>
>>>> The 4.1.3 version found ~400.000 allocated files more ~100.000 orphan
>>>> files, about the same found by other forensic tools. The develop branch
>>>> found the same ~400.000 allocated files more ~2.500.000 orphan files! Most
>>>> of these millions of orphans have corrupted names or the name
>>>> OrphanFile-xxxxxxx and have lengths ranging from 0 to 4.294.967.296 bytes.
>>>> We think the recent changes to NTFS code are causing this large number of
>>>> corrupted orphans to be added to the case. Maybe it should be investigated
>>>> before the final 4.2 release.
>>>>
>>>> Luis
>>>>
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>
>

Re: [sleuthkit-developers] Millions of orphan files found with sleuthkit develop branch

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

This error have happened again with a colleague's NTFS image, using the
develop branch compiled about 1 month ago. Thousands of huge corrupted
orphans were added by loaddb, which caused our processing application (and
probably Autopsy too) to process indefinitely the evidence.

Any help will be appreciated.

Regards,
Luis Nassif

2014-09-30 21:00 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:

> This problem still happens with 4.2.0 branch. If I can help with some more
> information, please let me know.
>
> Thanks
> Luis
>
> 2014-07-24 9:21 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>
>> Another information: the sum of the millions of file sizes resulted in
>> 1,1 petabyte, while the image has only 250 GB.
>>
>>
>> 2014-07-23 22:21 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>:
>>
>>> We tested loaddb of both the released 4.1.3 version and the develop
>>> branch of sleuthkit on a NTFS image of a hard disk with a lot of bad
>>> blocks, many of them at the beginning of the disk.
>>>
>>> The 4.1.3 version found ~400.000 allocated files more ~100.000 orphan
>>> files, about the same found by other forensic tools. The develop branch
>>> found the same ~400.000 allocated files more ~2.500.000 orphan files! Most
>>> of these millions of orphans have corrupted names or the name
>>> OrphanFile-xxxxxxx and have lengths ranging from 0 to 4.294.967.296 bytes.
>>> We think the recent changes to NTFS code are causing this large number of
>>> corrupted orphans to be added to the case. Maybe it should be investigated
>>> before the final 4.2 release.
>>>
>>> Luis
>>>
>>
>>
>

Re: [sleuthkit-developers] whither 4.2?

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

Thanks for the clarification, Brian. I don't mean to rush you on having a release, just want to get a sense of the near-term future.


Jon

> -----Original Message-----
> From: Brian Carrier [mailto:ca...@sl...]
> Sent: Tuesday, July 28, 2015 9:41 AM
> To: Jon Stewart
> Cc: sle...@li...
> Subject: Re: [sleuthkit-developers] whither 4.2?
> 
> Hi Jon,
> 
> Yea, I’m sorry about that. Whenever we do an Autopsy release, I always
> mean to do a TSK release too, but it falls off the list.
> 
> I’ll try to get a 4.2 release out this week.  In the early Fall, there will be new
> big releases of Autopsy and TSK that add collaboration features.  For TSK,
> that means support for PostgreSQL databases in addition to SQLite.  We’ll
> have to decide then if that means it is 4.3 or 4.2.1.
> 
> brian
> 
> 
> 
> 
> > On Jul 22, 2015, at 3:38 PM, Jon Stewart <JSt...@St...>
> wrote:
> >
> > Sleuthkit v4.1.3 was released 2014/01/26. Github has a release-4.2.0 branch
> that last saw commits on 2014/08/14. There are a number of open issues
> listed on Github related to correct filesystem handling (e.g., #471, #466, #462,
> #402, #401, #393).
> >
> > Like other organizations, TSK is a critical component for my group. We're
> contributing pull requests as we find issues that we can fix, but we lack the
> expertise to fix low-level errors in filesystem handling. Will there be a 4.2.0
> release sometime soonish?
> >
> >
> > Jon
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > sleuthkit-developers mailing list
> > sle...@li...
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] whither 4.2?

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

Hi Jon,

Yea, I’m sorry about that. Whenever we do an Autopsy release, I always mean to do a TSK release too, but it falls off the list. 

I’ll try to get a 4.2 release out this week.  In the early Fall, there will be new big releases of Autopsy and TSK that add collaboration features.  For TSK, that means support for PostgreSQL databases in addition to SQLite.  We’ll have to decide then if that means it is 4.3 or 4.2.1. 

brian




> On Jul 22, 2015, at 3:38 PM, Jon Stewart <JSt...@St...> wrote:
> 
> Sleuthkit v4.1.3 was released 2014/01/26. Github has a release-4.2.0 branch that last saw commits on 2014/08/14. There are a number of open issues listed on Github related to correct filesystem handling (e.g., #471, #466, #462, #402, #401, #393).
> 
> Like other organizations, TSK is a critical component for my group. We're contributing pull requests as we find issues that we can fix, but we lack the expertise to fix low-level errors in filesystem handling. Will there be a 4.2.0 release sometime soonish?
> 
> 
> Jon
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] whither 4.2?

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

Sleuthkit v4.1.3 was released 2014/01/26. Github has a release-4.2.0 branch that last saw commits on 2014/08/14. There are a number of open issues listed on Github related to correct filesystem handling (e.g., #471, #466, #462, #402, #401, #393).

Like other organizations, TSK is a critical component for my group. We're contributing pull requests as we find issues that we can fix, but we lack the expertise to fix low-level errors in filesystem handling. Will there be a 4.2.0 release sometime soonish?


Jon

[sleuthkit-developers] How to use TSK API in JAVA Developement

[Karthikeyan P. <blu...@gm...>]

Hai,
         Anyone knows how to integrate TSK on windows for development
perspective.
i'm try to integrate TSK API in my JAVA program. please anyone guide me.. i
cant figure it out.  Thanks

[sleuthkit-developers] Tutorial #1 on writing Python Modules

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

We posted the first of three tutorials on writing Python modules for Autopsy.   

    http://www.basistech.com/python-autopsy-module-tutorial-1-the-file-ingest-module/

This one focuses on basic file ingest modules.  You have plenty of time to start working on a module for the OSDFCon competition (http://www.basistech.com/osdfcon-2015/osdfcon-contest/).   If you have any problems or questions, send an e-mail to the developers list.

thanks,
brian

[sleuthkit-developers] Request_for_tsk_java_binding_configuration_on_windows

[Karthikeyan P. <blu...@gm...>]

Hai,

          I’m new to Sleuth kit. How to configure TSK java binding on
windows platform. How can i use TSK Library for my java application. Any
one guide for me. Thanks.


*System Requirement :*

*OS : Windows 7*

*JAVA : 1.7.0_45*

*JRE : 1.8.0_45*


*Regards,*
*Karthikeyan Panaiyadiyan.*

[sleuthkit-developers] New Python Example Modules

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

Based on some questions on and off list, I updated the sample Python modules this past weekend.  If any of you are playing with them, you might want to refer to them. 

https://github.com/sleuthkit/autopsy/tree/develop/pythonExamples

Changes include:
- There are now separate modules for file versus data source ingest modules.  It is more common to have a module that is only one or the other, so this should be easier to start from.
- Both have the sample code to read file content.
- All now have logging code in there to help with debugging
- All have “TODO” entries to figure out what needs to change
- The documentation no longer points you to the (more complex) ingest module with a configuration GUI.

The next release of Autopsy (we expect it to be around June 8) will also make run-time errors in Python easier for you to detect because you’ll have pop-up windows with the errors.  It will also have Python 2.7 (which Jython has now released). 

Let us know if you have any other questions.

  

Re: [sleuthkit-developers] JDK Version

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

+1 from me!

Luis

2015-03-20 15:08 GMT-03:00 Brian Carrier <ca...@sl...>:

> Does anyone using the Java bindings need it to remain JDK 6 compatible?
> There are some features of JDK 7 that we want to use and don't want to
> support a version that is no longer supported by Oracle if we don't need to.
>
> brian
>
>
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

[sleuthkit-developers] JDK Version

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

Does anyone using the Java bindings need it to remain JDK 6 compatible?  There are some features of JDK 7 that we want to use and don't want to support a version that is no longer supported by Oracle if we don't need to.

brian

[sleuthkit-developers] TSK_FS_META_FLAG_COMP vs TSK_FS_ATTR_COMP

[Jon S. <jo...@li...>]

I just noticed this on an NTFS compressed file.
TSK_FS_FILE->meta->flags has TSK_FS_META_FLAG_COMP set on it, but the
non-resident data attribute of the runs does _not_ have
TSK_FS_ATTR_COMP set on it. Other NTFS compressed files on the same
image have both flags set, respectively.

How could it happen that the primary non-resident data attribute of a
compressed file not have the compressed flag (TSK_FS_ATTR_COMP) set on
it? Is it because the meta structure is unallocated?


Jon
-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

[sleuthkit-developers] TSK_FS_ATTR.nrd.skip_len

[Jon S. <jo...@li...>]

Can someone describe a filesystem and associated condition wherein a
file could have a data attribute with nrd.skip_len that's non-zero? I
would love to create some test evidence where this value is non-zero,
but I don't know how.

Does TSK_FS_ATTR_RUN.offset take skip_len into account? If skip_len >
0, it would seem likely that the associated TSK_FS_ATTR_RUN.offset
values could be erroneous.

Thanks,

Jon
-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

Re: [sleuthkit-developers] TSK_FS_NAME.type

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

Yup.  You are correct.


On Jan 28, 2015, at 4:18 PM, Jon Stewart <jo...@li...> wrote:

> The type field on TSK_FS_NAME is an enum. Am I correct that it will
> always be a single enum value? i.e., not a bit field?
> 
> Thanks
> 
> Jon
> 
> ------------------------------------------------------------------------------
> 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-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] TSK_FS_NAME.type

[Jon S. <jo...@li...>]

The type field on TSK_FS_NAME is an enum. Am I correct that it will
always be a single enum value? i.e., not a bit field?

Thanks

Jon

Re: [sleuthkit-developers] Python in Autopsy

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

Hi Wiktor,

As reported on the dev page:

http://sleuthkit.org/autopsy/docs/api-docs/3.1/mod_dev_py_page.html


> Distribution
> 
> To distribute and share your Python module, ZIP up the folder and send it around. Other users of the module should expand the ZIP file and drop the folder into their Autopsy Python folder.

Users can find their Autopsy Python folder from the menu option under Tools. 

brian


On Jan 2, 2015, at 1:18 PM, Wiktor Sypniewski <wik...@gm...> wrote:

> Hi Guys,
> 
> My module requires python to be installed on the machine to run. It is
> command line tool requiring Python 2.7. How do I go about deploying
> it. I know I have to create NBM file etc. But is there a way that
> Autopsy can install Python on the machine while installing itself? Or
> maybe I could package Python in NBM?
> 
> Second question is: Can I add file to the folder in the module?
> 
> For example. In development I have release/mytool/settings
> 
> I want to be able to upload settings file into release/mytool/settings
> directory from within Autopsy.
> 
> 
> Vic
> -----------------------------------------------
> www.bluegreenblack.com
> www.thisfeelsgreat.blogspot.com
> https://github.com/Vic152
> 
> For sensitive information please use encryption.
> 
> Public key available at: http://pgp.mit.edu/
> Figerprint: 3D8C 48ED 42BD 4004 D23C  C455 8D80 7FB4 2C4D 7801
> 
> ------------------------------------------------------------------------------
> 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-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Python in Autopsy

[Wiktor S. <wik...@gm...>]

Hi Guys,

My module requires python to be installed on the machine to run. It is
command line tool requiring Python 2.7. How do I go about deploying
it. I know I have to create NBM file etc. But is there a way that
Autopsy can install Python on the machine while installing itself? Or
maybe I could package Python in NBM?

Second question is: Can I add file to the folder in the module?

For example. In development I have release/mytool/settings

I want to be able to upload settings file into release/mytool/settings
directory from within Autopsy.


Vic
-----------------------------------------------
www.bluegreenblack.com
www.thisfeelsgreat.blogspot.com
https://github.com/Vic152

For sensitive information please use encryption.

Public key available at: http://pgp.mit.edu/
Figerprint: 3D8C 48ED 42BD 4004 D23C  C455 8D80 7FB4 2C4D 7801

[sleuthkit-developers] How many classes does the Autopsy have?

[Wiktor S. <wik...@gm...>]

How many classes does the Autopsy have?

Vic
-----------------------------------------------
www.bluegreenblack.com
www.thisfeelsgreat.blogspot.com
https://github.com/Vic152

For sensitive information please use encryption.

Public key available at: http://pgp.mit.edu/
Figerprint: 3D8C 48ED 42BD 4004 D23C  C455 8D80 7FB4 2C4D 7801

Re: [sleuthkit-developers] sleuthkit HFS+ decmpfs bug fix patch

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

Thanks.  I just pushed this into the develop branch.


On Dec 4, 2014, at 3:53 AM, Hin-Tak Leung <ht...@us...> wrote:

> Seeing as I didn't get any response from either the main author
> or the person whose contribution I fixed, I am hoping
> posting to the dev list will get this bug fix committed... 
> 
> --- On Sat, 29/11/14, Hin-Tak Leung <ht...@us...> wrote:
> 
>> From: Hin-Tak Leung <ht...@us...>
>> Subject: sleuthkit HFS+ decmpfs bug fix patch
>> To: "Matt Stillerman" <ma...@at...>, "Brian Carrier" <ca...@sl...>, "Brian Carrier" <ca...@di...>
>> Date: Saturday, 29 November, 2014, 7:42
>> Hi,
>> 
>> I have had problems with using sleuthkit to get at the Mac
>> OS X
>> fonts for a few years (since decmpfs isn't supported by the
>> Linux
>> HFS+ driver yet). At first I thought a few font files were
>> corrupted,
>> especially as the affected fonts are both Korean (and rare),
>> but then
>> the files always comes out okay if I copy over a network
>> from a live
>> machine.
>> 
>> It turns out that it is a bug in the zlib related code in
>> sleuthkit for com.apple.decmpfs.
>> Here is the patch, and the rather more detailed explanation
>> inside.
>> This is against the "develop" branch, though I expect you
>> should be able to
>> just git-apply it to other branches too, since the
>> surrounding
>> code hasn't been changed for years.
>> 
>> Thanks for the good work.
>> 
>> Hin-Tak
> <0001-Z_BUF_ERROR-is-not-fatal.patch>------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] shut down method

[Richard C. <rco...@ba...>]

Hi Vic,

Here is the documentation of the shutdown() method as it appears in the
source code:

   /**
     * Invoked by Autopsy when an ingest job is completed (either because
the
     * data has been analyzed or because the job was canceled - check
     * IngestJobContext.isJobCancelled()), before the ingest module
instance is
     * discarded. The module should respond by doing things like releasing
     * private resources, submitting final results, and posting a final
ingest
     * message.
     */
    void shutDown();


You might notice the javadocs comment, here is where this appears on the
wiki:

http://www.sleuthkit.org/autopsy/docs/api-docs/3.1/interfaceorg_1_1sleuthkit_1_1autopsy_1_1ingest_1_1_file_ingest_module.html

It's perfectly fine top have a do-nothing shut down method for a file level
ingest module.

Note that data source level modules do not have a shutdown() method. The
reason for this is that the process() method is only called once, so shut
down activities can be completed in the process() method; file level ingest
module need a separate shut down because their process() methods are called
once per file.

Best,
Richard



On Fri, Dec 5, 2014 at 2:58 PM, Wiktor Sypniewski <
wik...@gm...> wrote:

> Hi Richard,
>
> One more question. What would be the proffered content of the shut
> down method? Hoe should module shut down?
> By the way this is my code so far:
> https://github.com/Vic152/VfIngestModule
>
> Vic
>
>
> -----------------------------------------------
> www.bluegreenblack.com
> www.thisfeelsgreat.blogspot.com
> https://github.com/Vic152
>
> For sensitive information please use encryption.
>
> Public key available at: http://pgp.mit.edu/
> Figerprint: 3D8C 48ED 42BD 4004 D23C  C455 8D80 7FB4 2C4D 7801
>

[sleuthkit-developers] shut down method

[Wiktor S. <wik...@gm...>]

Hi Richard,

One more question. What would be the proffered content of the shut
down method? Hoe should module shut down?
By the way this is my code so far: https://github.com/Vic152/VfIngestModule

Vic


-----------------------------------------------
www.bluegreenblack.com
www.thisfeelsgreat.blogspot.com
https://github.com/Vic152

For sensitive information please use encryption.

Public key available at: http://pgp.mit.edu/
Figerprint: 3D8C 48ED 42BD 4004 D23C  C455 8D80 7FB4 2C4D 7801

[sleuthkit-developers] Fw: sleuthkit HFS+ decmpfs bug fix patch

[Hin-Tak L. <ht...@us...>]

Seeing as I didn't get any response from either the main author
or the person whose contribution I fixed, I am hoping
posting to the dev list will get this bug fix committed... 

--- On Sat, 29/11/14, Hin-Tak Leung <ht...@us...> wrote:

> From: Hin-Tak Leung <ht...@us...>
> Subject: sleuthkit HFS+ decmpfs bug fix patch
> To: "Matt Stillerman" <ma...@at...>, "Brian Carrier" <ca...@sl...>, "Brian Carrier" <ca...@di...>
> Date: Saturday, 29 November, 2014, 7:42
> Hi,
> 
> I have had problems with using sleuthkit to get at the Mac
> OS X
> fonts for a few years (since decmpfs isn't supported by the
> Linux
> HFS+ driver yet). At first I thought a few font files were
> corrupted,
> especially as the affected fonts are both Korean (and rare),
> but then
> the files always comes out okay if I copy over a network
> from a live
> machine.
> 
> It turns out that it is a bug in the zlib related code in
> sleuthkit for com.apple.decmpfs.
> Here is the patch, and the rather more detailed explanation
> inside.
> This is against the "develop" branch, though I expect you
> should be able to
> just git-apply it to other branches too, since the
> surrounding
> code hasn't been changed for years.
> 
> Thanks for the good work.
> 
> Hin-Tak

Re: [sleuthkit-developers] Branching BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?

[Richard C. <rco...@ba...>]

Rajmund, I mentioned this conversation to Brian Carrier and learned that
the idea of adding this sort of hierarchy for interesting file hits and/or
tags via a path-based mechanism has been discussed before, so it is "on the
radar screen" so to speak. However, it is still true that this feature has
not been allocated to any upcoming release at this point.

Uploads to the wiki are outside of my purview, so I am explicitly adding
Brian Carrier to this conversation for further comment.

On Tue, Dec 2, 2014 at 4:33 AM, Rajmund <ra...@4e...> wrote:

> Dear Richard,
>
>
>
> Thank you for your long response. The solution you described seems more
> suited to the end-user perspective and not for the output of a File Ingest
> Module. Since in API 3.1 TSK_TAG_FILE became deprecated and the behaviour
> for display changed I was looking for a new Artifact type to use for
> allowing the user to view a grouping of files using the Thumbnail result
> viewer.
>
>
>
> So far TSK_INTERESTING_FILE_HIT seems the most suitable for what I want to
> do but does not allow for the hierarchical “tagging” I was looking for.
> Your screenshot does however show nicely where some of the other artifact
> types will be displayed inside Autopsy, Thank you.
>
>
>
> In the end I may have to play around with creating a custom Artifact in
> combination with the standard ones and look into how easy it is to
> implement a result viewer module.
>
>
>
> Do you know if the Sleuthkit wiki can be opened up for uploads so I can
> add some screenshots documenting some of the usage for Artifacts which may
> benefit other developers looking for the right one.
>
>
>
> Thank you
>
>
>
> Rajmund
>
>
>
> *From:* Richard Cordovano [mailto:rco...@ba...]
> *Sent:* 01 December 2014 15:19
> *To:* Rajmund
>
> *Subject:* Re: [sleuthkit-developers] Branching
> BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?
>
>
>
> Rajmund, there are currently no plans to support hierarchical interesting
> file set definitions.
>
>
>
> Are you aware of Autopsy's tagging capability? Tagging may help you to
> highlight folders of interest. You can apply named tags to files (including
> folders) and artifacts. There is one predefined "Bookmark" tag. An
> individual tag can have a comment associated with it.
>
>
>
>  To apply a tag, select one or more items in the tabular view (results
> viewer) and right-click to bring up the context (right-click) menu.
>
>
>
> I have attached a screen shot of the tagging menu items and the way tags
> appear in the tree. In the screen shot, you will see that I have selected a
> volume in the tree and have selected two folders at the root of that volume
> to tag. In the lower left corner of the screen shot, notice that tagged
> items are accessed in the tree under Results/Tags and are sorted by tag
> name, then by tag type (file or artifact). In this screenshot, five items
> have been tagged with the "Bookmark" tag - two files and three artifacts.
>
>
>
> Currently, tagging does not work in the tree itself. The work around is as
> described described above - use the tree to drill down until what you want
> to tag appears in the tabular view.
>
>
>
> Richard Cordovano
>
> Principal Software Engineer
>
> Basis Technology
>
>
>
> On Sun, Nov 30, 2014 at 4:34 PM, Rajmund <ra...@4e...> wrote:
>
> Thanks Richard,
>
>
>
> Do you know if there are plans to allow grouping of results in this
> fashion?
>
>
>
> What are other common artifact types used by developers here to highlight
> files found/analysed?
>
>
>
> If I want to highlight certain folders in the navigation tree what have
> you found to be a good way to do so?
>
>
>
> Thanks
>
>
>
> Rajmund
>
>
>
> *From:* Richard Cordovano [mailto:rco...@ba...]
> *Sent:* 28 November 2014 14:38
> *To:* Rajmund
> *Cc:* Autopsy Developers
> *Subject:* Re: [sleuthkit-developers] Branching
> BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?
>
>
>
> Sorry, Rajmund, there is currently no way to create the sort of hierarchy
> of interesting file set definitions you are envisioning.
>
>
>
> The code that shows interesting file hits in the "Interesting Items" tree
> groups the file hit results (artifacts) by file set name, and every file
> hit artifact has a single set name attribute. You could add separators to
> your set names, but that would only define new set names - the set names
> are not parsed to discover additional structure.
>
>
>
> On Fri, Nov 28, 2014 at 2:56 AM, Rajmund <ra...@4e...> wrote:
>
> Hi Team,
>
>
>
> I was wondering if there is a way to branch/create child items for the BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT
> in order to group them together?
>
>
>
> The goal would be that it would be shown in Autopsy as:
>
>
>
> Interesting Items
>
>               SetNameA
>
>                              SetNameAB
>
>                              SetNameAC
>
>               SetNameB
>
>
>
> Is there a separator to be used in TSK_SET_NAME? Or do I somehow have to
> add the children to the parent artifact?
>
>
>
> Is there another artefact type which allows the above if this one does not?
>
>
>
> Thanks
>
>
>
> Rajmund
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>
>
>
>
>

Re: [sleuthkit-developers] Branching BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?

[Rajmund <ra...@4e...>]

Dear Richard,

 

Thank you for your long response. The solution you described seems more suited to the end-user perspective and not for the output of a File Ingest Module. Since in API 3.1 TSK_TAG_FILE became deprecated and the behaviour for display changed I was looking for a new Artifact type to use for allowing the user to view a grouping of files using the Thumbnail result viewer.

 

So far TSK_INTERESTING_FILE_HIT seems the most suitable for what I want to do but does not allow for the hierarchical “tagging” I was looking for. Your screenshot does however show nicely where some of the other artifact types will be displayed inside Autopsy, Thank you.

 

In the end I may have to play around with creating a custom Artifact in combination with the standard ones and look into how easy it is to implement a result viewer module.

 

Do you know if the Sleuthkit wiki can be opened up for uploads so I can add some screenshots documenting some of the usage for Artifacts which may benefit other developers looking for the right one.

 

Thank you

 

Rajmund

 

From: Richard Cordovano [mailto:rco...@ba...] 
Sent: 01 December 2014 15:19
To: Rajmund
Subject: Re: [sleuthkit-developers] Branching BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?

 

Rajmund, there are currently no plans to support hierarchical interesting file set definitions.

 

Are you aware of Autopsy's tagging capability? Tagging may help you to highlight folders of interest. You can apply named tags to files (including folders) and artifacts. There is one predefined "Bookmark" tag. An individual tag can have a comment associated with it.

 

 To apply a tag, select one or more items in the tabular view (results viewer) and right-click to bring up the context (right-click) menu. 

 

I have attached a screen shot of the tagging menu items and the way tags appear in the tree. In the screen shot, you will see that I have selected a volume in the tree and have selected two folders at the root of that volume to tag. In the lower left corner of the screen shot, notice that tagged items are accessed in the tree under Results/Tags and are sorted by tag name, then by tag type (file or artifact). In this screenshot, five items have been tagged with the "Bookmark" tag - two files and three artifacts.

 

Currently, tagging does not work in the tree itself. The work around is as described described above - use the tree to drill down until what you want to tag appears in the tabular view. 

 

Richard Cordovano

Principal Software Engineer

Basis Technology

 

On Sun, Nov 30, 2014 at 4:34 PM, Rajmund <ra...@4e... <mailto:ra...@4e...> > wrote:

Thanks Richard,

 

Do you know if there are plans to allow grouping of results in this fashion?

 

What are other common artifact types used by developers here to highlight files found/analysed?

 

If I want to highlight certain folders in the navigation tree what have you found to be a good way to do so?

 

Thanks

 

Rajmund

 

From: Richard Cordovano [mailto:rco...@ba... <mailto:rco...@ba...> ] 
Sent: 28 November 2014 14:38
To: Rajmund
Cc: Autopsy Developers
Subject: Re: [sleuthkit-developers] Branching BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT?

 

Sorry, Rajmund, there is currently no way to create the sort of hierarchy of interesting file set definitions you are envisioning. 

 

The code that shows interesting file hits in the "Interesting Items" tree groups the file hit results (artifacts) by file set name, and every file hit artifact has a single set name attribute. You could add separators to your set names, but that would only define new set names - the set names are not parsed to discover additional structure.    

 

On Fri, Nov 28, 2014 at 2:56 AM, Rajmund <ra...@4e... <mailto:ra...@4e...> > wrote:

Hi Team,

 

I was wondering if there is a way to branch/create child items for the BlackboardArtifact.ARTIFACT_TYPE.TSK_INTERESTING_FILE_HIT in order to group them together?

 

The goal would be that it would be shown in Autopsy as:

 

Interesting Items

              SetNameA

                             SetNameAB

                             SetNameAC

              SetNameB

 

Is there a separator to be used in TSK_SET_NAME? Or do I somehow have to add the children to the parent artifact?

 

Is there another artefact type which allows the above if this one does not?

 

Thanks

 

Rajmund


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751 <http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
sleuthkit-developers mailing list
sle...@li... <mailto:sle...@li...> 
https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers