[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forensics
Subject:    Re: The imaging process and RAID
From:       "Ryan B. Lynch" <rlynch () strozllc ! com>
Date:       2004-03-03 15:41:17
Message-ID: 200403031541.19672.rlynch () strozllc ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Trevor,

On Wednesday 03 March 2004 12:18 pm, Trevor O'Donnal wrote:
> For a RAID 1 system, I would simply image each drive seperately
> since the idea with RAID 1 is for each drive to be a copy of the
> other.

While this is _mostly_ correct, there are circumstances where 
different drives in a RAID 1 array could have different contents:
	- If one of the drives has been marked as "failed" and removed from 
the array by the controller, no writes will have occurred on it since 
the failure.  Controllers sometimes fail drives that still work, so 
you might have a "fossilized" image of the volume sitting on such a 
disk.
	- If the array doesn't use the entirety of one or more disks, the 
unused disk areas will not necessarily be identical.  Many IDE RAID 
controllers have a "gigabyte boundary" feature (may go by other names 
on various devices) that allows you to round the used portion on the 
drive down to the next lowest even GB's worth of data, to allow 
replacement drives from different manufacturers to coexist peacefully 
(different drive makers may have differently-sized "40 GB" hard 
drives, right?).  Any data that pre-dated the construction of the 
array (or the addition of a particular drive to the array) will still 
be present in that area.

> This is the most simple solution in my mind. However, if I 
> am confronted with a RAID 0 or RAID 5 system, or even a RAID 1+0
> system, the problem isn't quite so easy to solve.  

I assume that your concern here is that you don't get individual disk 
images if you image the volume through the RAID controller instead of 
imaging the disks individually and reconstructing the array.  This is 
a valid concern, but I think it can be answered by examining the 
state of the array and the state of the disks (most hardware 
controllers have some kind of BIOS utility that 
builds/maintains/reports on the arrays).  Check for unused space, 
failed disks, etc.  If you find any disk area that's not part of the 
array volume, you can pull the individual disk and image that portion 
separately, into a separate file.  Since those areas aren't part of 
the array, you should be able to examine them without having to worry 
about RAID at all.  Then, image the RAID volume through the 
controller as normal.  This isn't quite as neat, but it is a 
complete, qualified forensic image.

> Encase could do 
> the job if you run it while the system is booted into Windows, but
> then I would be limited to Encase's image format. Also, what if
> it's a Netware server or a Linux system? In this case, I have been
> successful in obtaining images of RAID 0 and 5 arrays by booting to
> a DOS based imaging program like Safeback. Usually the software
> will recognize the RAID array as a single large drive that can be
> copied to a blank drive.

If I'm not mistaken, I think that the RAID controller itself is 
presenting the array to the OS as a single disk device.  That is, 
unless Safeback has somewhat more advanced software RAID capabilities 
than Linux does.  So you can use either DOS or Linux (or even 
Windows, if you saw fit), as long as you have a driver for that type 
of RAID controller on the OS platform that you choose.

> The problem here is that occassionaly you 
> may run into an array that is large enough as to not fit on a
> single blank hard drive. In this case, you would need some sort of
> alternative storage such as a tape backup unit or some other type
> of storage that is large enough to hold the data, and at the same
> time be accessible from whatever imaging program you are using.
> Safeback and many other utilities have the ability to break up the
> data into chunks of a specified size, but this is not always
> allowable depending on the case. I recently had a case where the
> client required that all the hard drives be copied to other hard
> drives. I was not allowed to create image files.

Client needs aside, it's easy to break raw image files into chunks 
using 'dd' and 'split', or by passing the "skip" paramter to 'dd'.

On a side note, what's the difference between creating image files and 
copying drive-to-drive, other than the practical considerations?  Was 
their objections a legal issue, or did they not trust the evidence 
file format as a valid forensic copy?

> Another theory which I have never tried, would be to image each
> member of the array seperately to another drive using a new drive
> for each member, then purchasing a RAID controller that matches the
> one in the subject system, and use it to rebuild the array in the
> lab later. Has anyone tested this? I'm not sure it would work
> unless the copy drives are the exact same brand and model as the
> originals.

Linux's software RAID subsystem (which has matured astonishingly in 
the past few years) has the ability to rebuild arrays that were 
originally formed by certain hardware controllers.  You may be able 
to loopback-mount your individual disk images, write a conf file, and 
restart the array on an examination machine.  The specifics are too 
big for this forum--check the Linux Software RAID HOWTO document, and 
then ask around on the linux-raid listserv.  This method has the 
advantage that it doesn't care about the original disks, either in 
terms of size or model.  Make sure you try it out on a couple of 
testbeds before you use it in the field, though.

- -Ryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFARfydKQgTRJGqPXQRApg8AJ40farejwZlZG2cN7be98aG5kGwTQCfQJYP
Fd180N0otlDTlx3E+Qsi2To=
=uPFw
-----END PGP SIGNATURE-----

-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


[prev in list] [next in list] [prev in thread] [next in thread]