Re: [sleuthkit-users] Views area of Autopsy Question
Brought to you by:
carrier
From: Umit K. <umi...@gm...> - 2016-11-07 17:19:01
|
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 > |