sleuthkit-developers

[sleuthkit-developers] stop-gap capabilities...

[t f <dor...@ho...>]

hello, brian.

first, i wish to commend you on your excellent work with the sleuthkit.

i have a few questions:

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.


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

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

thanks for hearing me out.

-dorkus

_________________________________________________________________
Check out MSN PC Safety & Security to help ensure your PC is protected and 
safe. http://specials.msn.com/msn/security.asp

Re: [sleuthkit-developers] stop-gap capabilities...

[Michael C. <mic...@ne...>]

Hi Dorkus,

> 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.
The IO subsystems patch is pretty complete at this point and is used heavily 
in flag: http://pyflag.sourceforge.net/.  I currently support encase evidence 
files as well as a new compressed format called sgzip. (as well as split dd 
images, or images of the entire disk).

I have only converted the tools I needed to use it namely dcat,fls,icat, istat 
and dbtools (david collett's SQL tool). I never got around to do the rest of 
the tools in fstools, i dont normally use any other tools, but it would be 
nice to complete them all.

> 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.
This is an excellent idea - I previously had a look at it though and it seemed 
that the LKM approach is quite complex. Obviously the kernel modules are far 
more functional than anything we need in sk, i.e. they allow to write new 
data, or create new data etc. There are two ways i can think of making this 
work:

1) dynamic linking directly into the lkm module - this is a neat solution but 
it sounds very complex to me - i guess we need to create a kernel driver like 
interface (like the loopback driver), and allow the module to call it. (We 
need to create an environment which is familiar enough to the lkm to require 
emulating large chunks of the kernel), also we need to write specific 
filesystem wrapping stubs to link between the sk concept of a "driver" and 
the lkm. Im no kernel hacker and my assesment is that this method is far too 
complex?

2) Create a new psuedo sk filesystem driver, which rather than do its own 
reading of a dd image, simply does ioctls on the mounted filesystem files 
etc. Pros of this method is that it should be very simple to implement, Cons 
are that it only operates on a mounted filesystem, so users need to be root 
to mount the image, also iosubsystems wont work because you cant get the 
kernel to read an encase file for example (hmm i just has an idea - maybe 
iosubsystems can include a custom loop device which will allow kernel 
mounting of all image files like encase, sgzip etc - something to think 
about).

> 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...
That is something i have been thinking or lately. I needed to use iso9660 once 
for example, and missed not having that in sk. Of course i could always mount 
it and look at the image by other means, but I could not use flag or autopsy 
which was mildly annoying.

Michael.

Re: [sleuthkit-developers] stop-gap capabilities...

[Brian C. <ca...@ce...>]

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