Re: [sleuthkit-users] Views area of Autopsy Question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

More granular is the better. I vote for 2.

Thanks,

*Umit Karabiyik*

On Mon, Nov 7, 2016 at 10:54 AM, Brian Carrier <ca...@sl...>
wrote:

> Votes sent to me in private show overwhelming support for 2 trees (one
> based on extension and another based on signature).
>
> Now the question is how people want to see the tree based on signature
> organized.   Please vote.
>
> 1) Nodes for images, videos, executables, documents, etc.  Each node would
> have one or more MIME types in it. For example, Images would have all of
> the JPG, GIF, BMP, etc. MIME types.
>
> 2) Nodes for each MIME type.  This would give a full taxonomy of the
> system. For example:
>
> application
> + exe
> + msword
> + x-msdownload
>
> audio
> + aiff
>
> image
> + bmp
> + jpeg
> ...
>
> text
> + html
> + plain
> ...
>
> #1 is easier to find general types of data, #2 allows you more fine
> grained access.  Preference?
>
>
>
>
>
>
>
>
>
> > On Nov 4, 2016, at 12:08 PM, Brian Carrier <ca...@sl...>
> wrote:
> >
> > Fair points.
> >
> > Let’s get some votes, otherwise we’ll stay with status quo.  There are
> three options on the table.
> >
> > 1) We intermix extensions and MIME type in the current views area and
> items may come and go from nodes as ingest progresses.
> >
> > 2) We have two trees.  One is the current extension-based one is
> available immediately.  The new one is signature-based on is available
> after ingest. Files would be in both of them.
> >
> > 3) We do nothing and the tree stays extension-based.  If you care about
> getting all pictures (regardless of extension), then use the Image Gallery.
> If you want other MIME types, you can use “File Search By Attribute”.
> >
> > Please send me your votes (or to the list) with 1, 2, or 3 so that we
> can get this into the next release.
> >
> > thanks,
> > brian
> >
> >
> >
> >
> >
> >> On Nov 3, 2016, at 6:04 PM, noxdafox <nox...@gm...> wrote:
> >>
> >> The MIME type and possible subcategories (dll, com etc) are indeed
> >> relevant information but relying on them to infer the file type might be
> >> error prone.
> >>
> >> There are lots and lots of corner cases to take into account:
> >>
> >> * When opening a file, Windows (not sure about MAC OS) merely relies
> >> on the file extension. This has led to several cases in which malware
> >> would not execute if the extension was not the correct one. Most recent
> >> case I stumbled upon was a document file which would execute only if the
> >> extension was .rtf. Extensions such as .doc, .docx or .docm would not
> >> show the real behaviour of the sample.
> >> * Current trend is to rely on scripts. Locky ransomware has been
> >> spread as .js, (JScript a Microsoft javascript "dialect"), .jse, .vbs
> >> and .wsf. It's very hard to programmatically detect the language type
> >> with good accuracy (think about how many javascript dialects are out
> >> there). User would probably see lots of text files and might loose the
> >> relevant ones.
> >> * How to deal with encrypted/packed/obfuscated files?
> >>
> >> It is true that file extensions might be abused to make investigation
> >> harder but in several cases the file extension is a very important piece
> >> of information. Only point of mine in here is not to treat it as second
> >> class citizen during investigations.
> >>
> >> On 03/11/16 16:11, Brian Carrier wrote:
> >>> Another effort we have underway is to incorporate file type signatures
> into the Views area of Autopsy and not rely only on extension.  This is a
> frequent request. But like many things, it gets complicated and potentially
> confusing to the user.
> >>>
> >>> Based on Autopsy’s philosophy of providing data as quickly as
> possible, the basic idea is to use a file’s extension if its MIME type is
> not yet known.  When its MIME type becomes known, then ignore the extension
> and rely on the file type.
> >>>
> >>> A couple of things we’d like feedback on:
> >>>
> >>> - When the image is being ingested, we are constantly learning about
> file types.  If we update the set of files under each type (JPEGs for
> example), then it would be frequently changing and this could get confusing
> and resource intensive.  Would you prefer that it is only updated after
> ingest is completed or at some periodic interval (say 5 minutes)?
> >>>
> >>> - We currently break down executables in the tree into .exe, dll,
> .com, etc nodes.  However, their MIME type is usually the same.  Do people
> use the detailed breakdown of executables or would it be good enough to
> have a single executable node in the tree?   How are people using these
> nodes?
> >>>
> >>> - We currently have a node in the tree for “.txt” files.  If we put
> all files of type “text/plain” in this node, it would have TONS of files.
> It would almost seem to make this node useless and impossible to find stuff
> in.  Do people ever use this node and, if so, would you like it to stay as
> just extension-based?
> >>>
> >>> Put another way, the current tree was easy to implement and understand
> when it was only extension-based.  It’s not as easy when it is
> signature-based and we want to know how much of the current tree to keep.
> What types of files do you want to be able to find from the tree?
> >>>
> >>> brian
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> Developer Access Program for Intel Xeon Phi Processors
> >>> Access to Intel Xeon Phi processor-based developer platforms.
> >>> With one year of Intel Parallel Studio XE.
> >>> Training and support from Colfax.
> >>> Order your platform today. http://sdm.link/xeonphi
> >>> _______________________________________________
> >>> sleuthkit-users mailing list
> >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> >>> http://www.sleuthkit.org
> >>
> >>
> >> ------------------------------------------------------------
> ------------------
> >> Developer Access Program for Intel Xeon Phi Processors
> >> Access to Intel Xeon Phi processor-based developer platforms.
> >> With one year of Intel Parallel Studio XE.
> >> Training and support from Colfax.
> >> Order your platform today. http://sdm.link/xeonphi
> >> _______________________________________________
> >> sleuthkit-users mailing list
> >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> >> http://www.sleuthkit.org
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>