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.