RE: [sleuthkit-developers] Re: IO Subsystem patch for fstools

[Paul B. <ba...@fo...>]

Hi Michael....

This sounds very good and cool.... (I haven't looked at yours patch yet =
though...)..

But I just wanted to indicate that the combination of your IO Subsystem =
patch for fstool and my searchtools (Indexed Searching) patch create a =
system that is very powerful.

The only thing really missing is a subsystem that makes it possible to =
"read" fileformats on the image with a specific interpreter. That would =
enable us to "read" PDF files, PST files, etc...=20

If all these 3 are in place, I think sleuthkit is a product that is more =
powerful than any of the other products I use...

Paul Bakker

-----Oorspronkelijk bericht-----
Van: Michael Cohen [mailto:mic...@ne...]
Verzonden: donderdag 19 februari 2004 9:17
Aan: Brian Carrier
CC: sle...@li...
Onderwerp: [sleuthkit-developers] Re: IO Subsystem patch for fstools


Hi Brian,
   I have started implementing the changes according to your =
suggestions, and=20
Its coming along great. I quite like the method of extending the basic=20
IO_INFO struct with more specific structs and then casting them back and =

forth. The code has a great OO feeling about it. Thanks for the =
pointers.

   Attached is an incomplete patch just to check that im on the right =
track.=20
Only the fls tool is working with the new system currently, although it=20
should compile ok. Here is a summary of the changes:

1) fls uses the -i commandline paramter to choose the subsystem to use, =
and=20
then gets an IO_INFO object by doing an:
	io=3Dio_open(io_subsys);
	If no subsystem is specified, it uses "standard" which is the current=20
default.

2) options are parsed into the io object by calling: =09
	io_parse_options(io,argv[optind++]);

	(options are option=3Dvalue format or else if they do not contain =
'=3D', we take=20
it as a filename).

3) Once we parse all of the options, we create an fs object using the io =

object:
	fs =3D fs_open(io, fstype);

	This will initialise a fs->io paramter with the io subsystem object.=20

4) All filesystem code uses the io object to actually do the reading. =
e.g.:
	ext2fs->fs_info.io->read_random(ext2fs->fs_info.io, (FS_INFO *) =
ext2fs,(char=20
*) gd, sizeof(ext2fs_gd),offs, "group descriptor");

	the io object has a number of methods. For example:
	io->constructor
	io->read_random
	io->read_block
	This has a cool object oriented feel about it.

5) There is an array in fs_io.c which acts like a class and is =
initialised to=20
produce new objects of all IO_INFO derived types. (i.e. all new io =
objects=20
are basically copies of this struct with extra stuff appended) Eg.

static IO_INFO subsystems[] =3D{
  { "standard","Standard Sleuthkit IO Subsystem", sizeof(IO_INFO_STD),=20
&io_constructor, &free, &std_help, &std_initialiser,  &std_read_block, =20
&std_read_random,  &std_open,  &std_close},

	Note that IO_INFO_STD is a derived object of IO_INFO:
	struct IO_INFO_STD {
 		 IO_INFO io;
		 char *name;
  		int fd;
	};

	i.e. it has the same methods like IO_INFO, but extra attributes. All =
the=20
other subsystems use this method to add extra attributes to the basic =
IO_INFO=20
pointer which is carried around the place as an IO_INFO (cast from=20
IO_INFO_ADV etc).

From a user perspective we can now do this:

- Read in a simple dd partition (compatibility with old fls):
fls -r -f linux-ext2 honeypot.hda5.dd

- Read in a partition file from a hdd dd image. (i.e. use an offset):
fls -r -i advanced offset=3D100 honeypot.hda5.dd

-Read in a split dd file (after splitting with split):
fls -r -i advanced /tmp/xa*
Or (same thing just to emphesize the fact that multiple files can be =
specified=20
on the same command line):
fls -r -i advanced /tmp/xaa /tmp/xab /tmp/xac /tmp/xad

-Read in an sgziped file:
fls -i sgzip -r -f linux-ext2 honeypot.hda5.dd.sgz

- List files in directory inode 62446:
fls -i sgzip -r -f linux-ext2 honeypot.hda5.dd.sgz 62446

Whats left to do:
As I mentioned, this is only an intermediate patch to check that im on =
the=20
right track. These are the things that need to be finished:

1) Add a config file parser option to allow options to be passed from a =
config=20
file, ie:
fls -r -c config -i advanced honeypot.hda5.dd

where config is just a files with lines like:
offset=3D1024

2) Change offset to be in blocks (and add a blocks keyword to override =
the fs=20
default).

3) Update all the other tools other than fls to support the new syntax.

4) I also have been working on an expert witness subsystem. Expert =
witness is=20
the format used by encase, ftk etc. I have a filter working atm to =
convert=20
these files to straight dd, but i want to implement a subsystem so we =
can=20
work on these files directly in sleuthkit. This is coming very soon, =
maybe=20
this weekend. This will obviously require lots of tender loving testing=20
because i only have encase ver 3 to play with.

Please let me know what you think about this. Also let me know if there =
are=20
other things that need to be completed still regards this patch.

  Michael.