
The grave-robber Data Collection Tool
--------------------------------------

The grave-robber tool is less of a tool itself than a framework for
other tools to reside in.  In the current incarnation it runs a
variety of perl modules, nearly all of them living in the "lib"
subdirectory.  It was explicitly designed to never send commands 
directly to the Unix command shell for parsing (to avoid nasty side
effects of meta characters, among other things) and it also logs all
shell commands and what time they were run at.

It has a slew of options for running various commands, saving data in
various locations, and other miscellanea - read the man page for more
information on these.

It roughly runs these tools so that data is captured according to the 
Order of Volatility; the OOV roughly says that certain data is more 
volatile or ephemeral than other types (memory vs. disk, for 
instance); generally speaking you want to capture the most volatile 
information before it goes away.  However, since any queries of the 
system risk disturbing other potentially valuable data one must be 
careful.  And while it impossible to automate this perfectly, the 
grave-robber can be a useful way of automating the process.

Before it starts doing much data collection, however, it examines some
of the tools and files that are important to the system that you might
wish to examine manually before waiting the (usually) long time it takes
for the grave-robber to finish its run.  Usually this includes files
located in the /etc directory, but also might include commonly runs
commands, such as those found in /bin, /usr/local/bin, etc.  The 
configuration file look@first is found in the "conf" subdirectory
and controls this.

Often you'll want to run the grave-robber on the entire system, and
by default it does just this.  It is recommended that you run the
grave-robber as root so that it can capture files and process information
that are not available to normal users.  To run it, simply type
"grave-robber" (or "bin/grave-robber", if TCT's "bin" directory is
not in your path.

By default, the grave-robber captures ephemeral information (process
and network state), figures out what it can about the system hardware
configuration (especially, disks and disk partitions), and searches
the file system for critical files (configuration files, log files,
other critical files).

However, the grave-robber's file system scan can take several hours.
All that processing is happening with the one and only original
copy of the data.   This goes somewhat against a basic rule of
computer forensics analysis: do as little processing as possible
with the original.

If you have the luxury of being able to dd(1) the disks and of
doing an off-line file system analysis, you will want to run
grave-robber with no more than the -f flag (the "fast scan"; if the
-p option works you might turn that on as well).  This turns off the 
file system walk, and allows you to run the full-blown set of tools at 
your leisure on another system against a copy of the data (or at least 
after the original information has been saved).


Analyzing the data subdirectory
--------------------------------

With the exception of the error and command logs, all captured data is
saved in the data subdirectory.  To be precise it is actually kept in
a subdirectory of the data subdirectory, the name of the subdirectory
corresponding to the name of the system and the time that the grave-robber
tool has been run.  The grave-robber also creates a symbolic link -
"data/hostname" - to the actual data dir.  In the hostname subdirectory
there are several files and subdirectories of interest:

	command_out	A subdirectory that keeps the output of most of
			the programs that execute code under the grave-robber.
			Each file in this directory is generally named
			after the command run and its arguments.  In addition
			an MD5 (of the output file) & time stamp (of when
			the program was run) is created, saved to the same
			filename with the ".md5" extension.

        strings_log	This is the output of the strings (1) command
			on every directory the file walker found.  Doing this
			will often reveal names of deleted files.
			(Presently this data is not collected).

        body		This is the mactime database.

	body.S          This contains file attributes of all SUID
			files.  They are in the normal mactime DB
			as well, it's simply simpler to see them
			here.

	coroner.log	This contains the date and time of all programs run
			by the grave-robber program.  This is in the main
			directory.

	error.log	This contains all errors generated by the grave-robber
			program.  This is in the main directory.

	deleted_files	This directory contains all deleted files that were
			still open or running when the grave-robber
			ran.  (Done by a combination of ils & icat).

	pcat		This directory contains all the images of running
			processes that pcat recovered.  Lots of interesting
			things can be found here!  Among other things user
			shells often have their history in memory, some
			programs keep IP #'s or hostnames, etc.; a command
			such as (in SunOS the -s flag pretty prints od
			output in a nice text form, YMMV):

				od -s pid.out.date | less

			can tell you quite a bit about what was going
			on in the past!

	conf_vault	This directory is an archive of all the files that 
			the grave-robber found of interest.  Configuration
			files, critical files & directories, etc.  Mostly
			controlled by the configuration files:

				save_these_files
				coroner.cf
				grave-robber.cf
			
			In addition there is an index.html file that points
			(via HTML) to all the files in this subdirectory.

The grave-robber has a few command line options (see the man page), but
mostly it is controlled by either editing the grave-robber file and 
removing or commenting out lines that you do not wish run (e.g. placing 
a pound sign ("#") in the place of the first character of an undesired 
line) or by editing the main configuration file, "grave-robber.cf" (or
the global configuration file, "coroner.cf").  Most of the options in 
the configuration file do not need to be changed, and should be fairly well 
commented on in the configuration file itself.

