RAID and NAS Acquisition

NAS devices are typically connected via ethernet cable and have folders shared for access over the internet. Sometimes one can place security on the folders. So if you are capturing over a LAN your capture is subject to limitations due to security and only the data currently under a shared folder. Sure if you have the admin rights to the NAS box, you can change what is shared and who has access but then you are tampering with the evidence.

If you capture each 1TB disk, then after capturing, you can boot up the NAS device and connect to it's management. If the entire disk available is 4TB, then your RAID is a simple stripe or span. If it is 2TB you have a mirror situation. 3TB means you have RAID5.

Encase has some scripts for analyzing multiple disks in a RAID and rebuilding the RAID. I have used RAID Reconstructor and it can do the job. If the file system on the RAID is familiar to you (realize that some NAS devices may have an NTFS, FAT32, Zetera or some other Nix type file system) then you can look to rebuild the RAID yourself by matching up the beginning sectors on the disks until they come together for the appropriate file system.

I've been playing with rebuilding RAID 5 a lot recently, and while Raid Reconstructor, EnCase, and XWays Forensics are alright, they're really constrained in terms of the stripe maps that they will handle. HP and Compaq RAIDs I've done had really weird data layouts that those programs couldn't deal with.

Try looking at a free forensic suite called PyFlag; it's flexible enough to handle any possible stripe arrangement, at the cost of having to do a little [eok, maybe a lot] more work yourself. With PyFlag, a good hex editor, and a little ingenuity I've made short work of stuff that Raid Reconstructor couldn't make heads or tails of.

Or you could just image the RAID from behind the controller card, and thus getting a single continuous volume, but where's the fun in that?

EDIT This is all assuming that the drives are in fact in a RAID 5 and not some other RAID level. Make sure to do what gkelley said to figure out what you're dealing with.

Greetings,

I may have misunderstood your post, but you seem to be suggesting that you cannot manually tell RAID Reconstructor what stripe arrangement to use. If you don't like its analysis, you have two options

1) You can enter your own parameters.
2) You can send the analysis output from RAID Reconstructor to the vendor and they will determine the correct parameters for you for $300. If they cannot figure out the parameters, you don't pay anything.

PyFlag is great if you have the time and skills, but RAID Reconstructor (possibly + $300) will also get the job done.

-David

Speaking of "weird data layouts" you have to take into consideration that some RAIDs, specifically those from Dell PERC controllers, do not start the RAID at sector 0.

Unless I'm mistaken, RAID Reconstructor can only figure out a "direction of rotation," which implies that it can only handle RAID 5's with a period equal to the number of disks in the array. I've seen two HP RAIDs with 3 disks and periods of 48. If RAID Reconstructor can in fact handle these, please prove it because that means less work for me )

Lots of hardware RAIDs don't start at sector zero because they have headers or whatnot, and software RAIDs obviously don't because there's a partition table and unallocated space (or maybe other partitions) before the RAID-ed volume. Copying out the "RAID part" with dd isn't really hard; with hardware RAID, you can find it using a hex editor in about a minute, and with a software RAID just use mmls from the Sleuthkit.

RAID Reconstructor will determine stripe size, order, direction and start sector (that surprised me). http//www.runtime.org/raid.htm

It works on RAID 5 and RAID 0.

Realize though that the less you know, the more permutations it has to go through and the longer it takes.

I knew about block size, disk order, direction of rotation, and start sector. My question is whether or not it can handle periods larger than the number of disks.

Go here, scroll to the end where sample maps are described, and look at the HP/Compaq map to see what I'm talking about. In the example, the parity block is in the same place for 4 consecutive stripes before it rotates; in the field I've seen the same thing except it's 16 consecutive stripes. This is a period of 48 rather than 3 like it normally is with RAID 5.

Admittedly, I haven't used RAID Reconstructor very much so there may very well be a way to configure it to deal with this but I haven't seen it.

Go here, scroll to the end where sample maps are described, and look at the HP/Compaq map to see what I'm talking about. In the example, the parity block is in the same place for 4 consecutive stripes before it rotates; in the field I've seen the same thing except it's 16 consecutive stripes. This is a period of 48 rather than 3 like it normally is with RAID 5.

I see what you are talking about. Admittedly, I haven't used RR in a while because I can usually rebuild the disks by looking at the beginning of each disk. What is described in the link you provided would screw up Encase's ability to build the RAID when you enter in the configuration, it can't handle that type of striping.

I see what you are talking about. Admittedly, I haven't used RR in a while because I can usually rebuild the disks by looking at the beginning of each disk. What is described in the link you provided would screw up Encase's ability to build the RAID when you enter in the configuration, it can't handle that type of striping.

Believe me I know. I just use PyFlag to get all the settings figured out and then use a Perl script to rebuild the thing into one logical image, then feed it into EnCase or FTK or whatever.

PyFlag cannot, however, handle having one disk missing from the RAID. I keep meaning to get into the source and add that but I'm a singularly lazy person.