[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sleuthkit-developers
Subject:    Re: [sleuthkit-developers] stop-gap capabilities...
From:       Brian Carrier <carrier () cerias ! purdue ! edu>
Date:       2004-04-10 18:13:12
Message-ID: BAB859AC-8B1A-11D8-98A0-0003936CD9A6 () cerias ! purdue ! edu
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 1)  what's the status of integrating utf8 support for both FAT and 
> NTFS filesystems?
>
> 2)  what's the status of the io subsystem patch?  that sounded very 
> promising, but i haven't seen much chatter about it in the past few 
> weeks on the list.

Both of these are targeted to be added to v2.  v2 will include a 
cleanup of some of the flags and output and new features. I'm still not 
sure if the full impact of adding UTF8 into the code, so I need to 
fully examine that before I just remove the filters.

> (This last one is more a request for the group to ponder...I really do 
> want to hear something back, so don't ponder indefinitely.)
>
> 3)  don't you suppose it's better to offer OS-specific (LKM-based) 
> filesystem access as a stop-gap measure than to leave the capability 
> out completely?  The code seems to be structured in a fairly modular 
> way to allow you to "drop in" fileystem drivers...Why not give folks 
> the option of pointing your code at the existing (be they OSX and/or 
> *nix) hfs+ and ufs2 drivers??  It gives them more flexibility, and 
> allows them to use sleuthkit for those cases NOW, while you coordinate 
> coding of your own cross-platform drivers.

It is a good idea, but there are several reasons why it probably won't 
happen.

- - It would be a lot of work to integrate them in because the design of 
TSK is different than what is given from file system LKMs.  I would 
rather spend the time working on more long-term things (which is 
currently the problem with adding new features).

- - It wouldn't really give you much.  From the little that I have looked 
into it, the only features that would be useful for the forensics part 
is the ability to list allocated file names.  I don't think you would 
be able to map a cluster to an inode to a file, see deleted file names, 
or extract unallocated blocks etc.  So, you get the same functionality 
as mounting the image in loopback.  It would be really clumsy in 
Autopsy because so many of the features would have to be disabled.

- - I don't really feel comfortable having output from "The Sleuth Kit" 
from code that I didn't package with it.  While it maybe more 
convenient and faster to deploy new support, I'm not sure if it is good 
for forensic tools and knowing where the code came from. I would rather 
take the module code and work it into libraries or some other code like 
existing TSK files where everyone who uses a given version of TSK is 
using the same code and it does not depend on what platform and patch 
version you have on your local system.


> IMO, folks will not shy away from a case because sleuthkit doesn't 
> support the filesystem...They'll just use something else.  I 
> understand that you're not directly profiting from use of your product 
> to conduct examinations, but there is definitely a lot of potential 
> here...

Maybe, but I am more interested in finding more people who are willing 
to help develop code to do it the right way (or develop a better GUI) 
instead of focusing on short-term patches.

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAeDk8kllA35nbwSURAuRSAJ0fPK004f0WcNA2sXdu1bFm7crhZwCfVfwA
2OtMexpcQFX1/oIGWmWutQ4=
=7wl3
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
sleuthkit-developers mailing list
sleuthkit-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
[prev in list] [next in list] [prev in thread] [next in thread]