RE: [sleuthkit-users] Using splitted images in autopsy

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> -----Original Message-----
> From: sle...@li... 
> [mailto:sle...@li...] On 
> Behalf Of David Collett
> Sent: Wednesday, December 15, 2004 6:25 PM
> To: sle...@li...
> Cc: Benjamin J. Weiss
> Subject: Re: [sleuthkit-users] Using splitted images in autopsy
> 
> 
> I've just rejoined this list, so I missed the original post. 
> Assuming the filesystems etc are ok, you have a few options.
> 
> I noticed while helping someone use another linux-based 
> forensics tool that it uses the linux kernel 'raid' 
> infastructure to achieve this, basic summary is:
> 
> 1. create a loop device for each segment containing parts of 
> the desired partition, possible providing an offset if 
> required into the first section to make it start at the start 
> of the filesystem. 2. put them all together with a 'linear' 
> raid array using the linux kernels 'md' raid subsystem.
> 
> Then I presume you could point sk at the raid device (eg. 
> /dev/md0) which would represent the desired partition.

This does work - I outlined it on the linux_forensics yahoo list a few
months back.  Here's that post for anyone who missed it:

I haven't had to do this for a while, but the procedure is something like
so:

1) Create loop devices associated with your raw *volume* (not disk) chunks.

2) Create an /etc/raidtab file with something along the lines of the
following ($x indicates a variable you must supply):

raiddev /dev/md0 
    raid-level                linear 
    nr-raid-disks             $N #N being the number of chunks you've got.
    persistent-superblock   	0
    chunk-size                X # Not used for this level of RAID, so any
value is fine.

    device                    /dev/loop0 
    raid-disk                 0 
    device                    /dev/loop1
    raid-disk                 1 
    ...(snip)...
    device				/dev/loopN-1
    raid-disk			N-1

3) Initialize the raid device

root@yourbox # mkraid /dev/md0

4) If you cat /proc/mdstat you should see stats on your new raid.

5) Mount /dev/md0 @ /FORENSICS/MOUNTPOINT - read-only, of course! ;)

Again, this is pretty hazy, but I can verify and do a more complete HOWTO if
there's interest.  Disk image chunks won't work unless there is only one
volume of interest and you apply an offset when creating your loop devices
to point to the beginning of that volume.  If there are other volumes on
partitions after that one, "physical" searches of the /dev/md0 will return
data from these spaces as well.  I haven't tested against different sized
chunks and don't know enough about the innards of software raid to determine
whether it'll cause problems or not, but I'll test that as part of the
HOWTO, again, if there's interest.

-------------------------------

This was confirmed by Andy Rosen and is (I believe) more or less the method
used by SMART to perform this function, who added this:

=======================================================
> You are correct and that is (as usual) a great answer.
> I have found that the chunks must be integral
> exponents of 1024 byte blocks AND that it helps if
> loop.o is a module (as opposed to in kernel).  I use
> 
> rmmod loop
> insmod loop max_loop=255
> 
> in my init script (rc.local) to insure that I have
> plenty of available loopback devices.
> 
> Also, loop is 32 bit clean, but beyond that, the
> offset to loop appears to be 31 bits.
=======================================================

> BIG DISCLAIMER:
> I havent done this personally, it may be more complicated 
> than I just described, In particular I would think that a 
> signature of some kind might be written to the segments when 
> you create the array, this is probably an option, so be very 
> careful you know what you are doing if you choose this 
> approach. Futhermore, I personally think its a bit of a 
> dangerous choice for a forensics tool to be doing all this 
> stuff as root using the OS kernel.

Could you explain why you think this is "dangerous," absolutely or
comparatively? 

> Which leads me to another approach. pyFLAG (pyflag.sf.net) 
> uses an IO Subsystem abstraction to deal with split images 
> (as well as RAID, Encase, and other file formats). An 
> exciting new tool in flag is called 'iowrapper', it works by 
> using LD_PRELOAD to load its own file operations (read, seek, 
> etc) before libc, thus overriding them and applying the IO 
> Subsystem abstraction. It therefore allows you to use any 
> unmodified binary program on your 'reconstructed' virtual 
> image transparently. More details can be found in the pyflag 
> source, but here's an example of how might use it with 'fls':
> 
> export LD_PRELOAD=./libs/libio_hooker.so
> ./bin/iowrapper -i advanced -o 
> offset=32256,file=part1.dd,file=part2.dd,file=part3.dd 
> ./bin/fls -r foo.dd

Very very interesting stuff, I definitely be playing with this.  I haven't
had the opportunity to use PyFLAG as much as I'd like, but I really like the
direction this is going. :)

Do you feel that there are any security/other implications with overriding
the standard libc operations in this manner?  Why is this more desirable
than using preexisting kernel capabilities on a dedicated forensics station
to perform the equivalent end result?

> This is pretty new code and I cannot guarantee it will work 
> for you, if you wish to try you will need the latest pyflag 
> sources from the 'darcs' repository, details for grabing it 
> are at pyflag.sf.net. This tool is not in any actual release 
> versions of pyflag, but will be in the next release.
> 
> hope this helps,
> Dave
> 
> On Wed, 15 Dec 2004 18:57:41 -0500, Brian Carrier 
> <ca...@sl...> wrote:
> > 
> > On Dec 15, 2004, at 10:24 AM, Benjamin J. Weiss wrote:
> > > I'm working on a disk image now with damaged partition/file 
> > > allocation tables.  Any idea when the disk-image Autopsy will be 
> > > ready? :)
> > 
> > If the partition table and file system are damaged, then v2 of TSK 
> > will not help.  It only processes that data that exists.
> > 
> > brian
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real 
> > users. Discover which products truly live up to the hype. Start 
> > reading now. http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > sleuthkit-users mailing list 
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users. Discover which products truly live up to the 
> hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sleuthkit-users mailing list 
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 