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

[David B. <to...@so...>]

* Brian Carrier (ca...@sl...) wrote:

[snip]

> It would be nice if each entry had a static size, so that we could jump 
> around the text file of the database easily.  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.

Yes it is a good idea to map applications type to an integer; I even
think that the OS field should be an integer too. It shouldn't be a pain
to manage them if the import tools make the task easier. (the problem
then is to develop proper import tools ;))

> 
> >Application entry:
> >- remote management

Thinking about this category, perhaps it is included in the server
daemons category (for the servers) and network category (for the
clients)

> >- office tools
> 
> Would adobe acrobat reader and calendars fit into this category?

Yes, and even a mail client.

> 
> >- database
> >- desktop
> 
> What are examples of this category?  games?

Proper examples for this category would be games, IM, screensavers,
iconsets, wallpapers... but perhaps this category should be merged with
the multimedia category ¿?

> 
> >- server daemons
> >- web
> 
> A general name like network may scale better.  Would email tools fit in 
> here too?

I prefer network too, but take into account that also all the web
scripts (CGI, php, perl, ...) should fit in this category.

> >- 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...

I would split perhaps this category in two other categories:
security(whitehat) and malware(exploits, rootkits, ...) I know that
malware is not the right word for them, but it is the name that gather
more different types of such files. Other approach is to include only
the 'whitehat' security tools in this category and the 'blackhat' tools
in the next category (known-bad)

> >- 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.

Both known-bad and known-good could be a 'wrapper' for other categories.

> >- 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.

According to the above, it should fit in both malware (replace this word
with other more suitable) and known-bad.

> >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.

Then we'd add OpenBSD, FreeBSD and NetBSD, and delete OSX. SunOS is
included in the Solaris category.

[snip]

> >Did we miss important fields ?
> 
> 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.

I have never used SHA-2 nor CRC32. If SHA-2 is being currently
used, we should definitely add it.

> Is the file size needed?  I'm trying to think of a scenario where that 
> would be needed.

Hmm not sure about that, but what happens when an application has
several files with the same name in different directories (and
different hashes)?. In addition, we should specify the application
language in some field, because for instance the nt.dll file is
different for Windows 2000 English version and Windows 2000 Spanish
version, both with the same patches applied.