±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35894
New Yesterday: 3 Visitors: 136

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

RAID 5

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3  Next 
  

jaclaz
Senior Member
 

Re: RAID 5

Post Posted: Apr 12, 19 12:10

- ClarkK
If a rebuild of individual drives has to occur then it would seem to me that you don't know if you did in fact get everything.


No, it is slightly different.

If you have the images of all the (single) physical disk drives you have *everything* and you can always re-build the whole array as it was (but this rebuild may take some time/effort).

If you image the disk array (as "exposed" by the RAID hardware/software) you have the thing as the server/os/whatever could see it, but not necessarily *everything* (it may depend also on the specific RAID hardware/software).

The note by athulin is more about the possibility (IMHO rare but not impossible in theory) that when you rebuild the array what is exposed is not exactly the same as what was exposed on the original machine.

Not necessarily the fastest/easiest but imaging BOTH the array as exposed AND the single drives would allow you to have the "as exposed" image to analyze and - in case of need - the possibility to rebuild from the single disks, and surely complies with *evrything* saving you from any possible critics.

It really depends on the nature of investigation and other "external" factors (that only you can know), as an example you (your organization) may have a policy that imposes 1:1 forensic copies of disks without exception for RAID arrays.

jaclaz

I
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

ClarkK
Member
 

Re: RAID 5

Post Posted: Apr 12, 19 13:10

I see. Well in our instance, the most likely scenario is that they would want to send us the individual disks. So we would not have the RAID controller. In this example, what tool(s) could be used to rebuild?  
 
  

DCS1094
Senior Member
 

Re: RAID 5

Post Posted: Apr 12, 19 16:17

You could do a live boot with WinFE boot disk and image via FTK Imager or X-Ways. Alternatively, you could use X-Ways to reconstruct the image files, if you have just been given the physical disks. I've also used UFS Explorer RAID Recovery in the past to assist with the identification/structure of the RAID and also reconstruction of the emulated drive. I had to do this when I was just given the physical HDD's with little to no information. They were stacked together and had been in storage.  
 
  

jaclaz
Senior Member
 

Re: RAID 5

Post Posted: Apr 12, 19 18:33

- ClarkK
I see. Well in our instance, the most likely scenario is that they would want to send us the individual disks. So we would not have the RAID controller. In this example, what tool(s) could be used to rebuild?

A few:
X-ways
Runtime RAID Reconstructor
Dmde

see also here:
www.forensicfocus.com/...c/t=10741/
www.forensicfocus.com/...c/t=13990/
www.forensicfocus.com/...c/t=16705/

The more info you get about the current configuration of the array, the easier will be to re-build it, there are usually no particular problems in "guessing" (actually discovering) the parameters, but directly providing the correct settings is obviously easier/faster.
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

UnallocatedClusters
Senior Member
 

Re: RAID 5

Post Posted: Apr 12, 19 21:32

Also potentially relevant:

www.osforensics.com/re...-raid.html  
 
  

athulin
Senior Member
 

Re: RAID 5

Post Posted: Apr 13, 19 05:22

- jaclaz
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.


If no information from a HW RAID controller is available, that may not matter very much.

However, if the HW configuration is available, and needs to be relied on (for instance if a similar controller will be used for imaging), the connection between what the controller calls the disks, and the actual disks themselves should be documented.

Documenting rack order assumes that that order corresponds to disk ports. If the person who installed the stuff is reasonably experienced, it usually does. But it some case, he wasn't and it doesn't, and in those cases the risk for confusion is fairly high.

(imaging a RAID should really be a kind of follow-up class to basic imaging, particularly for people who never have installed or worked with HW RAID units.)

Confusion may enter normal cases as well: if BIOS/EFI boots from disk port instead of disk ID, it may become important to document what HDD was connected to what port. At the very least, it becomes important if and when the disks are restored to the rack.  
 
  

jaclaz
Senior Member
 

Re: RAID 5

Post Posted: Apr 13, 19 11:10

- athulin
- jaclaz
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.


If no information from a HW RAID controller is available, that may not matter very much.

However, if the HW configuration is available, and needs to be relied on (for instance if a similar controller will be used for imaging), the connection between what the controller calls the disks, and the actual disks themselves should be documented.

Documenting rack order assumes that that order corresponds to disk ports. If the person who installed the stuff is reasonably experienced, it usually does. But it some case, he wasn't and it doesn't, and in those cases the risk for confusion is fairly high.

(imaging a RAID should really be a kind of follow-up class to basic imaging, particularly for people who never have installed or worked with HW RAID units.)

Confusion may enter normal cases as well: if BIOS/EFI boots from disk port instead of disk ID, it may become important to document what HDD was connected to what port. At the very least, it becomes important if and when the disks are restored to the rack.


Sure, everything is possible, but most of the time the disks are on trays with the top one being #1 and in order, they are assembled in factory like that.

And this same rule of the thumb is normally used when putting together a RAID DIY.

Of course if an incompetent (or crazy, or both) engineer has assembled himself/herself the server or has modified its internal connections, everything is possible.

And in any case, I would prefer to have a clear indication marked on the devices of which disk was which on the original hardware over a bunch of unmarked disks.

This said, we are talking of a RAID 5 made with 4 disks, it is not brain surgery or rocket science, you can blindy try all the remaining possible 23 combinations for drive order if "plain" 1-2-3-4 is doesn't work:

www.forensicfocus.com/...1/#6594761

Assuming that the RAID parameters are correct, that will take no more than 3 or 4 minutes each, or a couple of hours in the worst possible case.

(and they are really-really NOT 24 possibilities as the first disk can be identified by the presence of the MBR or of the GPT protective one+GPT partition tables), so there remains 6 of them:
1234
1243
1324
1342
1423
1432


jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 

Page 2 of 3
Page Previous  1, 2, 3  Next