Re: [sleuthkit-developers] First Draft - Layout Hash Database

[Matthias H. <mat...@mh...>]

Brian Carrier said:
[...]
> I thought about what software I have on my systems and tried to fit it
> in, so there are some questions about what goes where.  Could you maybe
> provide requirements for software to fit into each category?

Ok, I'll fill the categories with descriptions.

> It would be nice if each entry had a static size, so that we could jump
> around the text file of the database easily.

How about this: we use fields with dynamic length in the database and use
an export tool for exporting with static sizes ? We could set the maximal
length with datatypes like "varchar(40)".

> Therefore, there would be
> an index that correlates an application type to an integer.  I would
> think that doing integer comparisons would be faster than string
> comparisons though when looking entries up.  That maybe a pain to
> manage though.

Sure, we need integer identifiers for performance. I deliberatley didn't
mention them because I think we first have to agree on the data model.
Things like primary keys, foreign keys, indices etc. should follow when
we find a good data model.

>> Application entry:
>> - remote management
>> - office tools
>
> Would adobe acrobat reader and calendars fit into this category?

I would place adobe acrobat and calendars in the desktop category.

>> - database
>> - desktop
>
> What are examples of this category?  games?
>
>> - server daemons
>> - web
>
> A general name like network may scale better.  Would email tools fit in
> here too?
>
>> - multimedia
>> - drivers
>> - development
>> - sysutils
>> - security
>
> Would this include tools that are frequently called "hacker" tools too?
>   This category could be difficult and controversial to maintain, but I
> don't know of a better way to do it...

Sure, the problem we have is with tools like nmap,nemesis, hping etc. (to=
ols
both used for good and bad things).
I like Matt McMillon's idea to search categories both as knowngood and
knownbad. So everybody can decide for himself during search-time how
to handle this.
I think, operation system categories should be per default known-good.
Each application categories should get an individual default setting for
knowngood/knownbad.

>> - known-bad
>
> Should there be a known-good too?  I can imagine a situation where
> someone hashes his /bin/, /sbin/, /usr/local/bin ... directories and
> doesn't want to have to identify the category of each file.

Known-bad was kind of a catch-all for all possible known-bad files.
Problem is, if we segment known-bad, we'll get dozens of subcategories.
While this is no problem in the database, it will be difficult to handle
for autopsy.


>> - other
>
> Where would child-porn fit into this?  known-bad?  That seems to be one
> of the biggest categories of hashes and may warrant its own category.

Yes, I thought it should be known-bad. During my forensic analyses, my
main objectives so far were hacking-related, not child-porn. So it may be
that I have kind of a blind spot for this problem.
Ok, let's add a separate category "child-porn" with "known-bad" as defaul=
t.

>
>> Operation system entry:
>> - Linux
>> - Windows
>> - BSD
>> - Mac
>> - MacOSX
>> - Solaris
>> - DOS
>> - Handheld OS
>> - AIX
>> - HP-UX
>> - Other
>
> MacOS probably shouldn't get a separate category from OSX unless Win
> '98 is also separated from Win XP.  The specific types in BSD should be
> defined (since OS X is actually a variant of BSD).  The Solaris
> category should also include SunOS.

Ok, so BSD would include: (Free|Open|Net-BSD|BSD/OS|OS X)
What about IRIX,TRUE64 etc ? Did we forget a category with many entries ?
Problem is, we should hold the number of OS's low for a better
usability of the search interface. Out of the box I find about three doze=
n
operation systems and probably forgetting some other dozen.


> SHA-2 maynot be a bad idea.  I recall threads in the past on other
> lists about using SHA-2, so we may want to make a field for it (even
> though the public DB don't use it  yet).  It can take the place of
> CRC32.

Good point here.

> This looks good.  I think more requirements for each app category would
> be useful though.

I'll compile a new draft with some more flesh to each category. This
should help us for a more detailed discussion of the categories.

Regards,

Matthias