You are on page 1of 26

Acquiring Hardware RAID

configuration data from disks


Cybercrime and Forensics Project
Universiteit van Amsterdam
System and Network Engineering (MSc)

Sebastian Carlier (sebastian.carlier@os3.nl)


January, 2014

Abstract
This report describes what kind of hardware RAID configuration data can be
obtained from a single hard drive in a forensically sound manner. The research
tests the LSI SAS 1068E controller, the PERC H200 Adapter with 6Gbps SAS
Controller and the 3ware 9650SE-24M8 RAID controller. The purpose of this
research is to speed up the process of obtaining data from a virtual drive by helping in its reassembly.
Due to the nature of hardware RAID the findings are vendor specific. The
results show that we can obtain the harddrive serial numbers of all the disks
that belong to an array and the controllers brand. This knowledge satisfies the
requirements of rebuilding a RAID volume, by attaching the correct drives to a
specific controller.

Contents
1 Introduction

2 The process of identifying data written to the disk by the RAID


controller
6
2.1 The process of locating data and data extraction . . . . . . . . .
6
2.2 The process of analysing the data . . . . . . . . . . . . . . . . . .
7
3 Data analysis
3.1 SAS 6/iR adapter with LSI SAS 1068E controller . . . . . . . . .
3.2 PERC H200 Adapter with 6Gbps SAS Controller . . . . . . . . .
3.3 3ware 9650SE-24M8 RAID controller . . . . . . . . . . . . . . . .

8
8
12
15

4 Conclusions

20

5 Appendices

23

HW RAID forensics
1 Introduction

Introduction

Software and hardware RAID solutions are a popular way of storing data on
servers. They provide storage and/or hardware failure redundancy, but can
hinder forensic investigations if physically disassembled (i.e. pulled from the
server). Usually1 data cannot be retrieved until we find which disks belonged
to the array as it is fragmented and spread over the disks that form the RAID
volume[2].
With this knowledge the forensics investigator can take the following approaches:
Manually study the blocks of each drive to determine how the data is
fragmented. With this knowledge an algorithm can be applied to copy
the fragments and reassemble them on a separate device creating a disk
image[1]. This however can be a time consuming process requiring experience in data analysis and a good understanding of RAID algorithms.
Acquire the RAID configuration and reassemble the volume by using the
same RAID algorithm that created the array.
The latter approach is used in this research. However hardware RAID algorithms are proprietary and vendor specific. Reverse engineering those algorithms can be time consuming and does not seem like a viable solution. Instead
to reassemble the RAID volume we can use the same controller that created the
volume, as the algorithm resides in the RAID controller. To perform this task
the correct harddrives need to be obtained as well as the brand of the controller.
We work on the premise that a RAID controller recognizes a RAID volume
that was configured on another RAID controller of the same model. Furthermore it can be assumed that hardware RAID configuration data is written to a
disk.
This paper focuses on obtaining RAID configuration data from hard drives
that belonged to a RAID set, but for some reason were pulled from the server.
The main goal is to find configuration data that can help identify which controller was used and which disks were part of an array.
The first challenge when trying to obtain data from a RAID set stems from
how RAID works. If one wants to obtain data from an array of disks, some
configuration information needs to be known to either reassemble the array and
copy the data or to copy the data blocks from the disks in a specified order (as
presented to the OS by a RAID controller). This paper helps to achieve the
former approach.
Hardware RAID solutions use proprietary algorithms to configure an array
and do not conform to a unified standard. This poses the problem of knowing
on what controller the RAID array should be reassembled. An array assembled
on a different controller will usually not be recognized.
It is assumed that the reader has basic knowledge of RAID, hexadecimal
numbers and Linux tools used for comparing data.
1 This

is not true for RAID1

HW RAID forensics
1 Introduction

Scope
The scope of this paper includes:
The partly automated process of collecting the configuration that a RAID
controller saves on a disk. For the purpose of mapping that configuration
layout to a controller.
The partly automated forensics process of identifying (and obtaining) the
RAID configuration found on a disk.
The research is carried out by testing several RAID controller models. The
SAS 6/iR adapter[3] with LSI SAS 1068E controller[4], the PERC H200 Adapter
with 6Gbps SAS controller[5] and the 3ware 9650SE-24M8 RAID[6] controller
were selected for this project. They were chosen for several reasons. Firstly
they are usually used in different server models which vary in size and quality
(from 1 unit to 4 rack units). Each has a different capacity for disks (from 2 to
24 disks). Moreover two of the controllers are from the same brand, although
all of them use an LSI chip. For a detailed technical specification of the servers
please refer to the following:
Dell R2002
Dell R510 with 12x3.5 SAS/SATA ports3
Supermicro Superchassis with 24x3.5 SAS/SATA ports4

Research Question
Can RAID configuration data be acquired from a block device?
Can the acquired data be useful for reassembling a RAID array?
It is crucial to note that any data that might be considered as RAID configuration data can be circumstantial, and does not provide certainty as to its
meaning. However it can still be used to help reassemble a virtual drive. If a
RAID volume is recognized and a working partitioning scheme can be observed
on it5 , then the configuration is proven to be valid beyond reasonable doubt.

2 http://www.dell.com/us/dfb/p/poweredge-r200/pd
3 http://www.dell.com/us/business/p/poweredge-r510/pd
4 http://www.supermicro.nl/products/chassis/4U/846/SC846BE16-R1K28.cfm
5 with

meaningful data on those partitions

HW RAID forensics
2 The process of identifying data written to the disk by the RAID controller

The process of identifying data written to the


disk by the RAID controller

The goal of the research is to identify what data the controller leaves on the
disks. This can be broken down into the following problems. That is locating
the correct data and analysing the obtained data.

2.1

The process of locating data and data extraction

The first problem is to identify where the controller writes the configuration
data. We can assume that it is written on the disk, because when the disks
are connected to another controller (of the same model) the RAID array is
recognized. To establish where the data is written we apply the following steps:
1. Connect the disks to a SATA or SAS port and zero out all of the sectors.
This is achieved by performing # dd if=/dev/zero of=/dev/sdX , where sdX
is the disk we are targeting.
2. Check for blocks that contain non zero values to ensure the success of the
previous step. This step is not timely feasible without automation.
3. Connect the drives to the RAID controller and boot into the RAID BIOS
to setup the RAID array.
4. Boot a live OS on the server to ensure that the RAID disk has been
created.
5. Connect the disks to a SATA/SAS port and copy all sectors that contain
non zero values (including their offset). This step also requires automation.
As mentioned the steps above are not feasible without a certain amount of
automation. For this purpose we create a script5 that checks every block of the
disk starting at sector zero, if any data is found in a 512 byte block a dump of
that block is copied to the host machine with the sector number6 . If the next
512 byte block also contains non-zero values it is appended to that file. The
dumps created in this process are later used for the next step of this research.

6 counting

from 0 from the beginning of the disk

HW RAID forensics
2 The process of identifying data written to the disk by the RAID controller

2.2

The process of analysing the data

The problem that follows is identifying what the data represents. This is done by
repeating the steps above and adjusting the state of an array or its configuration.
The following changes are made in the tests to help interpret the data:
using different disks in the array
replacing a disk on a previously created array
creating a different level of RAID
configuring a hotspare to a RAID array
The goal is to identify which model of controller created the array which
is crucial to the RAIDs volume reassembly. Another necessary objective is to
identify the disks that the array consisted of and their position. When this data
is presented to a forensics investigator he can obtain a model of the controller
and identify the correct disks by the serial numbers present on their casings.

HW RAID forensics
3 Data analysis

Data analysis

This part of the paper presents the results of the tests that were previously
described. It shows what data was collected and interprets the data where
possible. The data is presented as hexadecimal dumps generated with hexdump.
The commands used to generate the output are also present for completion. The
directories are named after the setup and the files after the sector number of
the disk where the data was found. A certain understanding of hexdump7 is
required from the reader to comprehend the output. Due to the volume of the
collected data only the parts relevant to the findings are presented in this paper.
All of the files generated by our script can be obtained from ftp.scarlier.nl/
raid_research/.

3.1

SAS 6/iR adapter with LSI SAS 1068E controller

The following RAID setups were conducted on a SAS 6/iR adapter[3] equipped
with the LSI SAS 1068E controller[4] in a Dell r200 server. The RAID controller
supports RAID0 and RAID1 setups8 . The LSI Corp Config Utility For Dell SAS
6 v6.22.03.00 (2008.08.06) was used to configure the drives.
RAID0, 2 x 80GB SATA HDDs
RAID0, 2 x 160GB SATA HDDs
RAID1, 2 x 80GB SATA HDDs
RAID1, 2 x 160GB SATA HDDs
Data Structure
The script5 for collecting the data from disks generated the files listed in the
code block below.
ls -l r200_raid0_80gb/port0/
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier 512 Feb

9 17:52 sector_156252335
9 17:52 sector_156301487

ls -l r200_raid1_160gb/port0/
-rw-r--r-- 1 scarlier scarlier 7680 Feb 10 04:18 sector_312532655
-rw-r--r-- 1 scarlier scarlier 512 Feb 10 04:18 sector_312581807

The first two listed files were generated from an 80GB harddrive connected
to port 0 and configured in RAID0. The last 2 files were generated from a
160GB disk connected to port 0 and configured in RAID1. In each setup the
collected data is located at the same sector offset, counting from the end of the
disk. This is apparent when we take into account the total amount of sectors
on each disk. The data also spans the same amount of sectors. The byte offset
where the first chunk of data is found can be calculated in the following way:

7 http://manpages.debian.org/cgi-bin/man.cgi?query=hexdump
8 http://www.dell.com/learn/us/en/04/campaigns/dell-raid-controllers

HW RAID forensics
3 Data analysis

of f set = (last sector number data sector number) sector size, where:
last sector number = sector count 19 ,
data sector number is generated by the script5,
sector size is 512 bytes
The above formula gives us the byte offset from the end of the disk. The
offsets for our tests are calculated below. The disk information was collected
with fdisk and is shown in the appendix5.

For a 80GB disk:


last sector number = 312581808 1
of f set = (312581807 312532655) 512
of f set = 25165824bytes
For a 160GB disk:
last sector number = 156301488 1
of f set = (156301487 156252335) 512
of f set = 25165824bytes
Offset in megabytes:
of f set = 25165824bytes/(1024 1024)
of f set = 24megabytes
From the above we can assume that the offset is 24 Megabytes from the end of
the disk and is consistent for varying disk sizes10 .
The second chunk of data is located in the last sector of each disk.
Data Analysis
The data is interpreted by comparing the files generated by the script. In this
section only the interpreted differences are shown. The data blocks shown below
are taken from disks that belong to the same array. The bytes at offset 0xA11
translate to the serial number of the disk from which the data was collected. It
is preceded by ATA and 5 spaces, this most likely refers to the ATA Standard[7].

9 sectors

are counted from 0


assumption is also enforced when testing the PERC H200 Adapter with the 6Gbps
SAS Controller)
10 This

HW RAID forensics
3 Data analysis

hexdump -n 36 -s 0xA00 -C r200_raid0_80gb/port0/sector_156252335


---00000a00 33 33 33 33 50 2f b0 b6 41 54 41 20 20 20 20 20 |3333P/..ATA
|
00000a10 20 57 44 2d 57 4d 41 56 33 43 30 38 39 37 35 38 | WD-WMAV3C089758|
00000a20 06 50 b9 c2
|.P..|
00000a24
hexdump -n 36 -s 0xA00 -C r200_raid0_80gb/port1/sector_156252335
---00000a00 33 33 33 33 4a 6b 83 dc 41 54 41 20 20 20 20 20 |3333Jk..ATA
|
00000a10 20 57 44 2d 57 4d 41 56 33 41 38 38 38 35 36 33 | WD-WMAV3A888563|
00000a20 f4 0d 6f 22
|..o"|
00000a24
hexdump -n 36 -s 0xA00 -C r200_raid1_80gb/port0/sector_156252335
---00000a00 33 33 33 33 08 b1 df 3d 41 54 41 20 20 20 20 20 |3333...=ATA
|
00000a10 20 57 44 2d 57 43 41 56 33 35 38 33 36 37 39 36 | WD-WCAV35836796|
00000a20 c3 f3 fb 44
|...D|
00000a24
hexdump -n 36 -s 0xA00 -C r200_raid1_80gb/port1/sector_156252335
---00000a00 33 33 33 33 18 4d b7 65 41 54 41 20 20 20 20 20 |3333.M.eATA
|
00000a10 20 57 44 2d 57 43 41 56 33 37 31 33 34 31 34 33 | WD-WCAV37134143|
|..Mh|
00000a20 f0 18 4d 68
00000a24

The extracts below show that the bytes at offset 0xA04 and 0xA20 remain
the same for the same disk throughout different tests. It is unknown what this
data represents however we can assume that it is related to the disk. Moreover
it seems to be uniquely related as it is different for the same disk models.
hexdump -n 36 -C -s 0xA00 r200_raid0_160gb/port0/sector_312532655
---00000a00 33 33 33 33 32 27 62 a5 41 54 41 20 20 20 20 20 |33332b.ATA
|
00000a10 20 57 44 2d 57 4d 41 56 32 45 41 38 34 37 37 31 | WD-WMAV2EA84771|
|M..$|
00000a20 4d ae 09 24
00000a24
hexdump -n 36 -C -s 0xA00 r200_raid1_160gb/port0/sector_312532655
---|
00000a00 33 33 33 33 32 27 62 a5 41 54 41 20 20 20 20 20 |33332b.ATA
00000a10 20 57 44 2d 57 4d 41 56 32 45 41 38 34 37 37 31 | WD-WMAV2EA84771|
00000a20 4d ae 09 24
|M..$|
00000a24

The data block below shows the serial numbers of the disks from the array,
at offset 0x249 and 0x289. Those numbers match the serial numbers from the
casings of the inserted disks. The disks are listed in a reversed order, to elaborate
the disk from port 1 is listed as the first and the disk from port 0 is listed as
the second. The data at offset 0x268 and 0x2A8 is the SAS address11 of the
disk[8]. It is derived from the controllers SAS address which can be found in
the RAID BIOS of the controller. It can be identified as such, by comparing
the BIOS information with the data shown below. Lastly it remains the same
through every test on the same RAID controller.
hexdump -n 112 -s 0x240 -C r200_raid0_80gb/port0/sector_156252335
---WD-WMAV|
00000240 41 54 41 20 20 20 20 20 20 57 44 2d 57 4d 41 56 |ATA
00000250 33 41 38 38 38 35 36 33 f4 0d 6f 22 00 02 00 01 |3A888563..o"....|
00000260 00 00 00 00 09 40 f8 af 50 02 6b 90 58 2e b6 01 |.....@..P.k.X...|
00000270 ff ff ff ff ff ff ff ff 01 ff ff ff ff ff ff ff |................|
WD-WMAV|
00000280 41 54 41 20 20 20 20 20 20 57 44 2d 57 4d 41 56 |ATA
00000290 33 43 30 38 39 37 35 38 06 50 b9 c2 00 02 00 01 |3C089758.P......|
000002a0 00 00 00 00 09 40 f8 af 50 02 6b 90 58 2e b6 00 |.....@..P.k.X...|
000002b0

10

HW RAID forensics
3 Data analysis

Figure 1: A screenshot of the RAID adapter BIOS showing the SAS address.
The data block below shows the brand of the controller repeated multiple
times throughout the configuration. The controller is originally produced by
LSI, but re-branded to Dell. It is unkown what the Bytes marked in green
mean, however they are always present after the company name. The Bytes
marked in red can be identified as the SAS address of the controller in reversed
order.
hexdump -C r200_raid0_80gb/port0/sector_156252335
00000000 31 90 71 57 7b 63 53 dd 44 65 6c 6c 20
00000010 10 00 00 58 10 28 1f 0e 05 f1 f8 e3 19
*
00000640 44 65 6c 6c 20 20 20 20 10 00 00 58 10
00000650 05 f1 f8 e3 c8 78 e1 c1 00 00 ff ff 00
*
00000c00 ad 11 11 11 27 98 06 25 4c 53 49 4c 4f
00000c10 20 20 20 20 20 20 20 20 00 b6 2e 58 90
00000c20 10 00 00 58 10 28 1f 0e ff ff ff ff ff
*
00000e00 ee ee ee ee 90 2c 27 a7 44 65 6c 6c 20
00000e10 10 00 00 58 10 28 1f 0e 05 f1 f8 e3 c8
*
00001200 ff ff ff ff 00 00 00 00 44 65 6c 6c 20
00001210 10 00 00 58 10 28 1f 0e 05 f1 f8 e3 c8

20 20 20
c1 59 79

|1.qW{cS.Dell
|
|...X.(........Yy|

28 1f 0e
00 00 00

|Dell
...X.(..|
|.....x..........|

47 49 43
6b 02 50
ff ff ff

|......%LSILOGIC|
|
...X.k.P|
|...X.(..........|

20 20 20
78 e1 c1

|.....,.Dell
|
|...X.(.......x..|

20 20 20
78 e1 c1

|........Dell
|
|...X.(.......x..|

Further differences were observed between different configurations however


they do not seem relevant in achieving the ultimate goal of collecting data from
the virtual drive.

11 http://en.wikipedia.org/wiki/Serial

attached SCSI#Identification and addressing

11

HW RAID forensics
3 Data analysis

3.2

PERC H200 Adapter with 6Gbps SAS Controller

A RAID10 comprising of 4x80GB HDDs was setup on the PERC H200 adapter
in a Dell r510 server. The RAID controller supports RAID0, RAID1 and
RAID10 setups. The LSI Corp Config Utility For Dell SAS Ctrl v7.11.10.00
(2011.06.02) was used to configure the array. To observe the changes in configuration one of the disks was removed from the array and replaced.
Data Structure
Preliminary tests showed that the collected data bears a high resemblance to
the one from the LSI SAS 1068E controller. The size of the generated files is the
same. The offset from the end of the disk is the same. In the following test the
replacement disk is of a slightly different size to enforce this assumption. The
output of fdisk and smartctl found in the appendix5 shows the technical details
of the two different types of used disks. The relevant parts are the highlighted
disk size difference, sector count and the sector numbers where the configuration
data starts. The formula found in the previous section3.1 gives the same offset
of 24 Megabytes.

For the 80GB Maxtor disk:


last sector number = 156250000 1
of f set = (156249999 156200847) 512
of f set = 25165824bytes
For the 80GB Western Digital disk:
last sector number = 156301488 1
of f set = (156301487 156252335) 512
of f set = 25165824bytes
Offset in megabytes:
of f set = 25165824bytes/(1024 1024)
of f set = 24megabytes

The files holding the configuration data found on each disk can be obtained
from the following location ftp.scarlier.nl/raid_research/, all of the disks
hold the data at the same offset, regardless of disk size or port number.
Data Analysis
The differences in the configuration data found on each disk are highlighted in
the code block below. The parts highlighted in blue represent the serial number
of the disk the data was found on. The meaning of the parts highlighted in red
is unknown however it is likely they relate to the disk, as they remain the same
for a specific disk. The remainder of the configuration is identical on each disk.
hexdump -C -s 0xA00 -n 36 r510test/port0/sector_156252335
00000a00 33 33 33 33 67 8d ad e6 41 54 41 20 20 20 20 20
00000a10 20 57 44 2d 57 4d 41 56 33 43 30 38 39 37 35 38
00000a20 06 50 b9 c2
----

|3333g...ATA
|
| WD-WMAV3C089758|
|.P..|

12

HW RAID forensics
3 Data analysis

hexdump -C -s 0xA00 -n 36 r510test/port1/sector_156252335


00000a00 33 33 33 33 3f 13 c2 6d 41 54 41 20 20 20 20 20 |3333?..mATA
|
00000a10 20 57 44 2d 57 43 41 56 33 35 38 33 36 37 39 36 | WD-WCAV35836796|
00000a20 c3 f3 fb 44
|...D|
---hexdump -C -s 0xA00 -n 36 r510test/port2/sector_156252335
00000a00 33 33 33 33 7d c9 9e 8c 41 54 41 20 20 20 20 20 |3333}...ATA
|
00000a10 20 57 44 2d 57 4d 41 56 33 41 38 38 38 35 36 33 | WD-WMAV3A888563|
00000a20 f4 0d 6f 22
|..o"|
---hexdump -C -s 0xA00 -n 36 r510test/replacement_port3/sector_156200847
00000a00 33 33 33 33 86 2c 1b 71 41 54 41 20 59 32 34 33 |3333.,.qATA Y243|
00000a10 41 35 44 43 20 20 20 20 20 20 20 20 20 20 20 20 |A5DC
|
00000a20 9f fe 1a f8
|....|

When a disk is replaced we can observe some changes in the configuration.


Most of them are hard to identify, however the relevant part - the serial number
of the new disk is human readable. The serial number of the disk that was
pulled is substituted by the new one padded with spaces. This means that the
configuration will hold only the disks that were last used in the array. most
importantly the Serial Numbers of pulled disks are removed only upon substitution and rebuilding the array with the new disk. Therefore even if a RAID
array was physically disassembled the data on the pulled disk proves that the
configuration can still be found. Provided that the RAID array was not rebuild with a different disk, this configuration data can yield a rebuild of the
array when the other disks are obtained. The changes can be observed in the
code block below. The full list of changes can be found in the appendix5. The
changes are highlighted in red and the serial numbers in blue.
hexdump -C r510test/replacement_port3/sector_156200847
00000240 41 54 41 20 59 32 34 33 41 35 44 43 20 20 20
00000250 20 20 20 20 20 20 20 20 9f fe 1a f8 00 02 00
*
00000a00 33 33 33 33 86 2c 1b 71 41 54 41 20 59 32 34
00000a10 41 35 44 43 20 20 20 20 20 20 20 20 20 20 20
00000a20 9f fe 1a f8 00 00 ff ff ff ff ff ff ff ff ff
---hexdump -C r510test/pulled_port3/sector_156252335
00000240 41 54 41 20 20 20 20 20 20 57 44 2d 57 43 41
00000250 33 37 31 33 34 31 34 33 f0 18 4d 68 00 02 00
*
00000a00 33 33 33 33 2f ef aa 35 41 54 41 20 20 20 20
00000a10 20 57 44 2d 57 43 41 56 33 37 31 33 34 31 34
00000a20 f0 18 4d 68 00 00 ff ff ff ff ff ff ff ff ff

20
04

|ATA Y243A5DC
|
|
........|

33
20
ff

|3333.,.qATA Y243|
|A5DC
|
|................|

56
01

|ATA
WD-WCAV|
|37134143..Mh....|

20
33
ff

|3333/..5ATA
|
| WD-WCAV37134143|
|..Mh............|

The configuration found on the disks attached to this controller is similar


to the one found on the SAS 6/iR adapter with the LSI SAS 1068E controller.
The brand of the controller is found at the same offsets as well as the reversed
SAS address of the controller. This can help in identifying the controller used
for creating the array.
hexdump -C r510test/port0/sector_156252335
00000000 31 90 71 58 f3 92 02 a3 44 65 6c
00000010 10 00 00 72 10 28 1f 1e 02 ec 62
*
00000640 44 65 6c 6c 20 20 20 20 10 00 00
*
00000c00 ad 11 11 11 76 bd 29 8f 4c 53 49
00000c10 20 20 20 20 20 20 20 20 00 5b b7
*
00000e00 ff ff ff ff 00 00 00 00 44 65 6c
00000e10 10 00 00 72 10 28 1f 1e 02 ec 62
*
00001200 ee ee ee ee 5c f5 a3 0d 44 65 6c
00001210 10 00 00 72 10 28 1f 1e 02 ec 62
*

6c 20 20 20 20
38 b8 74 7c 43

|1.qX....Dell
|
|...r.(....b8.t|C|

72 10 28 1f 1e

|Dell

4c 4f 47 49 43
55 b0 b2 42 58

|....v.).LSILOGIC|
|
.[.U..BX|

6c 20 20 20 20
38 55 0c 0d e9

|........Dell
|
|...r.(....b8U...|

6c 20 20 20 20
38 55 0c 0d e9

|....
...Dell
|...r.(....b8U...|

...r.(..|

13

HW RAID forensics
3 Data analysis

Figure 2: A screenshot of the RAID adapter BIOS showing the SAS address.

14

HW RAID forensics
3 Data analysis

3.3

3ware 9650SE-24M8 RAID controller

The following tests were performed on a 3ware 9650SE-24M8 RAID controller:


RAID1, 2 x 80GB SATA HDDs
RAID5, 2 x 80GB SATA HDDs
The controller is capable of RAID0, RAID1, RAID5, RAID6, RAID10 and
RAID50, its technical specifications can be found on the manufacturers website12 .

Figure 3: The controllers information from the BIOS.

Data Structure
The code block below shows the data structure of the configuration found on an
80GB HDD attached to port 0 in RAID1 and an 80GB HDD attached to port
0 in RAID5.
supermicro_raid1_80gb/port0$ ls -l
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 16896
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 16896

Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb

12
12
12
12
12
12
12
12

04:53
04:53
04:53
04:53
04:53
04:53
04:53
04:53

sector_156291252
sector_156291256
sector_156291268
sector_156291270
sector_156300468
sector_156300472
sector_156300484
sector_156300486

supermicro_raid5_80gb/port0$ ls -l
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 17408
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 17408

Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb

12
12
12
12
12
12
12
12

05:31
05:31
05:31
05:31
05:31
05:31
05:31
05:31

sector_156291252
sector_156291256
sector_156291268
sector_156291270
sector_156300468
sector_156300472
sector_156300484
sector_156300486

The files of the same size found on the same disk are identical. They are
at a different offset. This is proven in the code block below. Since the data is
repeated it is most likely done for redundancy or compatibility. Only two files
12 http://store.lsi.com/index.cfm/Clearance/SATA-II-PCI-Express-with-RAID-6/
9650SE-24M8/

15

HW RAID forensics
3 Data analysis

are different when comparing data from different disks that belong to the same
array. This is shown below.
supermicro_raid1_80gb$ diff port0/sector_156291252 port1/sector_156291252
Binary files port0/sector_156291252 and port1/sector_156291252 differ
supermicro_raid1_80gb$ diff port0/sector_156291256 port1/sector_156291256
supermicro_raid1_80gb$ diff port0/sector_156291268 port1/sector_156291268
supermicro_raid1_80gb$ diff port0/sector_156291270 port1/sector_156291270
supermicro_raid1_80gb$ diff port0/sector_156300468 port1/sector_156300468
Binary files port0/sector_156300468 and port1/sector_156300468 differ
supermicro_raid1_80gb$ diff port0/sector_156300472 port1/sector_156300472
supermicro_raid1_80gb$ diff port0/sector_156300484 port1/sector_156300484
supermicro_raid1_80gb$ diff port0/sector_156300486 port1/sector_156300486

Those two files are however the same when compared with each other.
supermicro_raid1_80gb$ diff port0/sector_156291252 port0/sector_156300468
supermicro_raid1_80gb$ diff port1/sector_156291252 port1/sector_156300468

The configuration data is found at the same offset for both tests. More tests
should be performed to ensure with a higher certainty that the offset remains
the same for varying disk sizes and different configurations. For our tests the
location of the data remains as shown below.
of f set = (last sector number data sector number) sector size
For the first chunk of data:
of f set = (156301487 156291252) 512Bytes
of f set = 5240320Bytes
of f set = 5117.5KBytes
For the second, repeated chunk of data:
of f set = (156301487 156300468) 512Bytes
of f set = 521728Bytes
of f set = 509.5KBytes
Lastly for the remainder of this section we shall assume that there are two
sets of data found on each disk, with the division shown below13 . Those sets
are identical to each other. Each of them starting 5240320 Bytes from the end
of the disk and repeated 521728 Bytes from the end of the disk. Each of them
spans over 52 sectors or 26624 Bytes (or 26Kbytes).
It is probable that the information is repeated for redundancy.
supermicro_raid5_80gb/port0 ls -l
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 17408
-rw-rw-r-- 1 scarlier scarlier 1536
-rw-rw-r-- 1 scarlier scarlier 1024
-rw-rw-r-- 1 scarlier scarlier
512
-rw-rw-r-- 1 scarlier scarlier 17408

Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb

12
12
12
12
12
12
12
12

05:31
05:31
05:31
05:31
05:31
05:31
05:31
05:31

sector_156291252
sector_156291256
sector_156291268
sector_156291270
sector_156300468
sector_156300472
sector_156300484
sector_156300486

Data Analisys
Since the data resides twice on every drive the following analysis applies to the
data starting at 5240320 Bytes and 521728 Bytes from the end of the disk. The
13 8

separate files are a result of the script used to collect the data. the source can be found
in the appendix

16

HW RAID forensics
3 Data analysis

only difference between the data collected from disks that belong to the same
array is highlighted below in red. The byte at offset 0x1A correlates with the
port number the disk is attached to. This is true for all the tests. Not much
can be said for the byte at 0x2 apart from the fact that it increments by 0x1
as the port number increases. The bytes marked in blue represent the brand of
the controller (at 0x8) and the serial numbers of all the disks that belong to the
array (at 0x23E and 0x253).
hexdump -C supermicro_raid1_80gb/port0/sector_156300468
00000000 44 69 e4 b5 00 00 00 00 33 57 61 72 65 44 43 42
00000010 00 00 00 00 01 00 00 00 06 90 00 4e 28 0a 0f 00

|Di......3WareDCB|
|...........N(...|

hexdump -C supermicro_raid1_80gb/port1/sector_156300468
00000000 44 69 e5 b5 00 00 00 00 33 57 61 72 65 44 43 42
00000010 00 00 00 00 01 00 00 00 06 90 01 4e 28 0a 0f 00

|Di......3WareDCB|
|...........N(...|

hexdump -C supermicro_raid1_80gb/port0/sector_156300468
00000230 2a 00 00 00 a6 ca 00 00 65 20 20 20 20 20 57
00000240 2d 57 43 41 56 33 37 31 33 34 31 34 33 65 20
00000250 20 20 20 57 44 2d 57 4d 41 56 33 41 38 38 38
00000260 36 33 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000510 00 00 00 00 00 00 00 00 2a 00 00 00 a6 ca 00
00000520 65 20 20 20 20 20 57 44 2d 57 43 41 56 33 37
00000530 33 34 31 34 33 65 20 20 20 20 20 57 44 2d 57
00000540 41 56 33 41 38 38 38 35 36 33 00 00 00 00 00
00000550 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000600

44
20
35
00

|*.......e
WD|
|-WCAV37134143e |
|
WD-WMAV3A8885|
|63..............|

00
31
4d
00
00

|........*.......|
|e
WD-WCAV371|
|34143e
WD-WM|
|AV3A888563......|
|................|

The data below shows a part of the configuration form a RAID 5 array from
the disk attached at port 0. It starts at sector 156291252. The structure appears
to be similar to the one of RAID1. here we can also find the serial numbers of
each used disk, however the serial number of the configured hotspare disk is not
present.
hexdump -C supermicro_raid5_80gb/port0/sector_156291252
00000000 44 69 e4 b5 00 00 00 00 33 57 61 72 65 44 43
*
00000230 3f 00 00 00 0b 7d 00 00 63 20 20 20 20 20 57
00000240 2d 57 43 41 56 33 35 38 33 36 37 39 36 65 20
00000250 20 20 20 57 44 2d 57 43 41 56 33 37 31 33 34
00000260 34 33 65 20 20 20 20 20 57 44 2d 57 4d 41 56
00000270 41 38 38 38 35 36 33 00 00 00 00 00 00 00 00
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000510 00 00 00 00 00 00 00 00 3f 00 00 00 0b 7d 00
00000520 63 20 20 20 20 20 57 44 2d 57 43 41 56 33 35
00000530 33 36 37 39 36 65 20 20 20 20 20 57 44 2d 57
00000540 41 56 33 37 31 33 34 31 34 33 65 20 20 20 20
00000550 57 44 2d 57 4d 41 56 33 41 38 38 38 35 36 33
00000560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000600

42

|Di......3WareDCB|

44
20
31
33
00
00

|?....}..c
WD|
|-WCAV35836796e |
|
WD-WCAV371341|
|43e
WD-WMAV3|
|A888563.........|
|................|

00
38
43
20
00
00

|........?....}..|
|c
WD-WCAV358|
|36796e
WD-WC|
|AV37134143e
|
|WD-WMAV3A888563.|
|................|

17

HW RAID forensics
3 Data analysis

Figure 4: The controllers BIOS showing the SN of the disk attached to port 0.

Figure 5: The controllers BIOS showing the SN of the disk attached to port 1.
At offset 0x1F (starting at sector 156291256) we can find the array name, which
is a value that can be set in the BIOS.
hexdump -C supermicro_raid1_80gb/port0_afterreplacement/sector_156291256
00000000 29 6e d0 85 02 00 00 00 03 40 00 00 22 22 a0 00 |)n.......@..""..|
00000010 98 00 08 00 00 03 0e 01 00 01 00 03 11 15 00 46 |...............F|
00000020 6f 72 65 6e 73 69 63 73 00 00 00 00 00 00 00 00 |orensics........|
00000030 00 00 00 00 00 03 12 14 00 33 37 31 33 34 31 34 |.........3713414|
00000040 33 30 30 30 32 30 33 30 30 31 46 45 43 00 03 15 |3000203001FEC...|

18

HW RAID forensics
3 Data analysis

Figure 6: The array name of the RAID1 configuration.


There are various small differences between the RAID1 and RAID5 configuration data, however due to the sample size of the tests, illegibility of the data
and no apparent relation to the controller information presented they are omitted from the chapter. The data found in this section is relevant for both levels of RAID. For reference and completeness the data can be obtained from
ftp.scarlier.nl/raid_research/.
Lastly there is one block of data that is shared between the RAID5 configuration
and a hotspare disk in slot3. A hotspare was only configured for the RAID5
and is not present in the RAID1 configuration.
cmp -s supermicro_raid5_80gb/port0/sector_156300486 supermicro_raid5_80gb/port3_hotspare/sector_156300486 0x4200 0x4200
hexdump -s 0x4200 -C supermicro_raid5_80gb/port3_hotspare/sector_156300486
00004200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00004380 00 00 00 00 c5 27 26 0f b6 4f 5a 83 f9 01 0f 85 |.....&..OZ.....|
00004390 fc 01 83 c3 58 bf 79 28 e8 f8 e5 b9 00 00 0f 84 |....X.y(........|
000043a0 ec 01 26 8b 5f 06 2e 89 1e db 58 26 8b 7f 06 26 |..&._.....X&...&|
000043b0 80 7f 0c 02 75 09 26 80 7d 02 0f 0f 84 eb 01 26 |....u.&.}......&|
000043c0 8b 47 09 83 e0 02 d1 e8 26 a3 36 28 26 a3 34 28 |.G......&.6(&.4(|
000043d0 26 a3 78 28 26 8b 47 09 83 e0 10 c1 e8 04 26 a3 |&.x(&.G.......&.|
000043e0 06 28 26 a3 08 28 26 8b 47 09 25 00 08 c1 e8 0b |.(&..(&.G.%.....|
000043f0 26 a3 02 28 26 a3 04 28 26 8a 47 0b f6 d0 24 06 |&..(&..(&.G...$.|
00004400

We believe that this is done to bind a hotspare with a RAID array for the
following reasons:
It is present both in RAID5s configuration and in the hotspares configuration.
It is the biggest seemingly random chunk of data shared between them.
It is entirely absent in the RAID1 configuration which does not have a
hotspare. Making this configuration 512 Bytes shorter.
However this is an assumption that requires further testing. It was not tested
further due to the lack of value of the data found. The hotspare was tested to
see if it includes the Serial Numbers of the RAID5 array. Those were not found.
Lastly a hotspare does not actively participate in a RAID until another disk
fails14 .

14 http://en.wikipedia.org/wiki/Hot_spare#Computer_usage

19

HW RAID forensics
4 Conclusions

Conclusions

This section summarizes the findings of the project and answers the research
questions formulated in the introduction1.
Can RAID configuration data be acquired from a block device?
Yes, the raw RAID configuration data can be acquired from a block device
as it is stored on the disks on readable sectors. Our research shows that this
data seems be stored at a fixed offset15 . This is a reasonable claim considering
that a different controller of the same model is required to correctly identify the
RAID configuration. The offset can be different for different controllers:
The SAS 6/iR adapter with LSI SAS 1068E controller holds the data 24
Megabytes from the end of the disks,
The PERC H200 Adapter with 6Gbps SAS Controller holds the data 24
Megabytes from the end of the disk,
The 3ware 9650SE-24M8 RAID controller holds identical data 5117.5 Kilobytes and 509.5 Kilobytes from the end of the disk.
In the case of the first two controllers the location of the data and its structure is identical. Therefore it is safe to assume that they use the same algorithm
to store and read the configuration, also considering that both come from the
same company and have similar capabilities.
Furthermore the configuration data is stored on all of the disks, and only on
those disks, that belong to the RAID array. The configuration remains on the
disks after the disks are physically removed.
The described process can help in data acquisition in a forensically sound manner as it does not manipulate the acquired evidence. It is crucial to note that
the above does not prove with certainty that the acquired information will result
in a successful RAID disk reassembly. However it gives the investigator a clue
or guideline as to which disks and what controller to use to reassemble a RAID
disk. If the virtual disk is reassembled successfully the final goal is reached and
in turn it proves the hypothesis that the collected configuration data was correct.
The prerequisite to obtaining the configuration data is that the forensics
investigator needs to know at what offset the data is stored and the size of the
data. As this paper shows the data structure of the configuration is vendor specific. In an ideal case a forensics investigator should document the configuration
structure and location for as many controllers as possible following the guidelines
of this paper. This adds initial overhead to a forensics investigation. However
when configuration mappings for each controller are known then collected data
can be compared to those mappings. This process can be automated.

Can the acquired data be useful for reassembling a RAID array?


15 for

the controllers that were tested

20

HW RAID forensics
4 Conclusions

As mentioned before a RAID controller of the same model (and possibly


other models that use the same firmware) will identify a previously constructed
RAID volume. The volume can be reassembled if all of the originally used
disks16 are present. Therefore only two specific values need to be acquired,
namely a unique identifier of each used disk and the RAID controllers type.
From each disk that was part of a RAID volume we can acquire the following
data:
Serial Numbers of each disk that belong to a RAID volume. This helps
identify which disks to use for reassembly.
Position of the disk in an array - provides information on which port the
disk should be connected to.
SAS address of the controller - can help identify the specific controller if
the forensics investigator holds a database of SAS addresses.
Brand of the controller - can help identify which model of controller should
be used for reassembly.
Furthermore based on the data structure of the configuration, the investigator can guess what controller should be used for reassembly, as the structure
differs greatly when a controller of a different brand is used. In other words
it is possible to deduct the type of controller from the location and structure
of the configuration. This approach requires documenting the configuration of
multiple different models of controllers, which can initially add overhead to data
acquisition.
Lastly all of the acquired data can be of course manipulated or overwritten
by the user before the seizure of the disks. This however destroys the RAID
volume resulting in loss of data, therefore the user would need to anticipate the
seizure. If this happens a forensics investigator would need to use the manual
approach mentioned in the introduction1.

Future research
Since some RAID controllers use internal memory we propose to research if
that data is retained and if it can be acquired directly from the controller. A
comparison of such data to the configuration data found on the disks might
proof useful.

16 Bearing

in mind RAID redundancy

21

HW RAID forensics
References

References
[1] RAID Reassembly - A forensic Challenge
Dr Michael Cohen
http://pyflag.sourceforge.net/Documentation/articles/raid/
reconstruction.html
Published on August 18, 2005
[2] Common RAID Disk Data Format Specification
Bill Dawkins
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_
Position_v2.0.pdf
Version 2.0 Revision 19
Published on March 27, 2009
[3] SAS IR Product Brief
http://www.lsi.com/downloads/Public/SAS%20ICs/SAS%20ICs%
20Common%20Files/SCG_LSI_SAS_3Gbps_IR_PB_011408.pdf
Published on January 14, 2008
[4] LSISAS1068E Product Brief
http://www.lsi.com/downloads/Public/SAS%20ICs/LSISAS1068E/
SCG_LSISAS1068E_PB_040407.pdf
Published on February 21, 2006
[5] PERC H200 Adapter with 6Gbps SAS controller Product
Brief http://accessories.us.dell.com/sna/productdetail.aspx?c=
us&l=en&s=gen&sku=342-1597
[6] 3ware
9650SE-24M8
RAID
Controller
Product
Brief
http://store.lsi.com/index.cfm/Clearance/
SATA-II-PCI-Express-with-RAID-6/9650SE-24M8/
[7] Information Technology - AT Attachment
Peter T. McLean
http://www.t10.org/t13/project/d1321r3-ATA-ATAPI-5.pdf
Revision 3
Published on February 29, 2000
[8] Introduction to Serial Attached SCSI
http://docs.oracle.com/cd/E19494-01/820-1260-15/appendixg.
html#50548798_66057
Published by Sun Microsystems, Inc.

22

HW RAID forensics
5 Appendices

Appendices

Python script for collecting data from disks


#! / home/ s c a r l i e r / b i n / py
import o s . path , s y s , s u b p r o c e s s , r e ,

argparse

#p a r s i n g i n p u t arguments
p a r s e r = a r g p a r s e . ArgumentParser ( d e s c r i p t i o n=The s c r i p t dumps a l l
n o n z e r o b l o c k s from a d e v i c e o r f i l e )
group = p a r s e r . a d d m u t u a l l y e x c l u s i v e g r o u p ( r e q u i r e d=True )
group . add argument ( d , d i s k , h e l p= s p e c f i c y b l o c k d e v i c e t o a n a l y z e )
group . add argument ( i , image , h e l p= s p e c i f y d i s k image t o a n a l y z e )
p a r s e r . add argument ( s , s e c t o r , h e l p= s p e c i f y s t a r t i n g s e c t o r ( s i z e i s s e t t o 512 b y t e s ) ,
DEFAULT = 0 , t y p e=i n t , d e f a u l t =0)
p a r s e r . add argument ( e , e r a s e , a c t i o n= c o u n t , h e l p= e r a s e d a t a from d e v i c e , d e f a u l t =0)
p a r s e r . add argument ( r , r e t r i e v e , a c t i o n= c o u n t , h e l p= r e t r i e v e d a t a from d e v i c e , d e f a u l t =0)
args = parser . parse args ()
#The f u n t i o n b e l o w s a v e s t h e d e v i c e name and c h e c k s i t s number o f s e c t o r s
i f args . disk :
dev name = a r g s . d i s k
h d i n f o = s u b p r o c e s s . c h e c k o u t p u t ( [ hdparm , g , dev name ] ,
u n i v e r s a l n e w l i n e s=True )
m = r e . s e a r c h ( (?<= ) \ d +(?= ,) , h d i n f o )
b y t e c n t =i n t (m. group ( 0 ) ) i n t ( 5 1 2 )
else :
dev name = a r g s . image
b y t e c n t = o s . path . g e t s i z e ( dev name )
def r e t r i e v e r a i d ( dev name , s e c t o r n u m ) :
append = F a l s e
empty=b \ x00
s t a r t=s e c t o r n u m 512
d e v i c e = open ( dev name , rb )
device . seek ( s t a r t )
#t h e l o o p w a l k s t h e whole d i s k i n s e a r c h o f data ,
#s a v i n g and appending nonzero s e c t o r s
while 1 :
s e c t o r = device . read (512)
i f not s e c t o r :
device . close ()
break
i f s e c t o r != empty 5 1 2 :
i f append == F a l s e :
f i l e n a m e = s e c t o r %d%( s e c t o r n u m , )
o u t p u t = open ( f i l e n a m e , ab )
print ( d a t a fo u nd i n s e c t o r %d % s e c t o r n u m )
output . w r i t e ( s e c t o r )
output . c l o s e ( )
append = True
else :
append = F a l s e
s e c t o r n u m += 1
def z e r o o u t ( dev name , s e c t o r n u m , b y t e c n t ) :
#z e r o s o u t d a t a from t h e d i s k , s t a r t i n g a t s p e c i f i e d s e c t o r
s t a r t b y t e = s e c t o r n u m 512
empty = b \ x00
d e v i c e = open ( dev name , rb+ )
device . seek ( start byte )
print ( b y t e c n t )
t a i l = b y t e c n t % 104857600
print ( t a i l )
d e v i c e . w r i t e ( empty t a i l )
while 1 :
i f s t a r t b y t e >= b y t e c n t or 1 0 4 8 5 7 6 0 0 > b y t e c n t :
break
else :
d e v i c e . w r i t e ( empty 1 0 4 8 5 7 6 0 0 )
s t a r t b y t e += 1 0 4 8 5 7 6 0 0
print ( s t a r t b y t e )

23

HW RAID forensics
5 Appendices

device . close ()
if
if

a r g s . r e t r i e v e == 1 :
r e t r i e v e r a i d ( dev name , a r g s . s e c t o r )
a r g s . e r a s e == 1 :
z e r o o u t ( dev name , a r g s . s e c t o r , b y t e c n t )

fdisk output for the disks attached to the SAS 6/iR adapter
with LSI SAS 1068E controller
Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
---Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

fdisk and smartctl output for the disks attached to the


PERC H200 Adapter with 6Gbps SAS Controller
cat r510test/replacement_port3/smartctl.txt
Model Family:
Maxtor DiamondMax Plus 9
Device Model:
Maxtor 6Y080M0
Serial Number:
Y243A5DC
Firmware Version: YAR51HW0
80,000,000,000 bytes [80.0 GB]
User Capacity:
Sector Size:
512 bytes logical/physical
cat r510test/replacement_port3/fdisk.txt
Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders, total 156250000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
r510test/replacement_port3$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier
512 Feb
----

1 06:20 sector_156200847
1 06:20 sector_156249999

cat r510test/pulled_port3/smartctl.txt
Model Family:
Western Digital Caviar Blue Serial ATA
Device Model:
WDC WD800AAJS-00L7A0
Serial Number:
WD-WCAV37134143
LU WWN Device Id: 5 0014ee 10268cc90
Firmware Version: 01.03E01
80,026,361,856 bytes [80.0 GB]
User Capacity:
Sector Size:
512 bytes logical/physical
cat r510test/pulled_port3/fdisk.txt
Disk /dev/sdc: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
r510test/pulled_port3$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier 512 Feb

3 14:12 sector_156252335
3 14:12 sector_156301487

List of the files holding the configuration data found on


each disk on the PERC H200 Adapter with 6Gbps SAS
Controller
r510test/port0$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb

3 15:08 sector_156252335

24

HW RAID forensics
5 Appendices

-rw-r--r-- 1 scarlier scarlier

512 Feb

3 15:08 sector_156301487

r510test/port1$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier 512 Feb

3 15:59 sector_156252335
3 15:59 sector_156301487

r510test/port2$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier 512 Feb

3 16:48 sector_156252335
3 16:48 sector_156301487

r510test/replacement_port3$ ls -l
-rw-r--r-- 1 scarlier scarlier 7680 Feb
-rw-r--r-- 1 scarlier scarlier 512 Feb

1 06:20 sector_156200847
1 06:20 sector_156249999

Changes in the configuration after disk replacement on the


PERC H200 Adapter with 6Gbps SAS Controller
hexdump -C r510test/replacement_port3/sector_156200847
00000000 31 90 71 58 5d 5f 78 43 44 65 6c 6c 20 20 20
00000010 10 00 00 72 10 28 1f 1e 02 ec 62 38 b8 74 7c
00000020 30 31 2e 30 30 2e 30 30 00 00 00 11 02 ec 6c
*
00000060 00 00 00 00 09 4f 6f 8f ff ff ff ff ff ff ff
00000070 01 ff ff ff 00 00 80 00 00 00 00 00 09 4f af
*
00000200 22 22 22 22 ce cc 09 62 00 04 00 0e ff ff ff
00000210 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
00000240 41 54 41 20 59 32 34 33 41 35 44 43 20 20 20
00000250 20 20 20 20 20 20 20 20 9f fe 1a f8 00 02 00
00000260 00 00 00 00 09 40 2f 8f 58 42 b2 b0 55 b7 5b
*
00000600 dd dd dd dd 01 b3 12 db 00 01 00 02 ff ff ff
00000610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
00000640 44 65 6c 6c 20 20 20 20 10 00 00 72 10 28 1f
00000650 02 ec 62 38 55 0c 0d e9 ff ff ff ff 00 00 00
00000660 f1 00 ff ff ff ff ff ff ff ff ff ff ff ff ff
*
00000a00 33 33 33 33 86 2c 1b 71 41 54 41 20 59 32 34
00000a10 41 35 44 43 20 20 20 20 20 20 20 20 20 20 20
00000a20 9f fe 1a f8 00 00 ff ff ff ff ff ff ff ff ff
*
00000e00 ee ee ee ee f9 37 cd c9 44 65 6c 6c 20 20 20
00000e10 10 00 00 72 10 28 1f 1e 02 ec 62 38 55 0c 0d
00000e20 02 ec 6c 94 00 00 00 02 ff ff ff ff ff ff ff
*
00000fe0 09 00 01 ff 91 00 01 01 80 00 ff ff ff ff ff
00000ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00001000 c3 f3 fb 44 06 50 b9 c2 f4 0d 6f 22 9f fe 1a
*
00001220 02 ec 6c 93 00 00 00 01 ff ff ff ff ff ff ff
*
000013e0 09 00 01 ff 91 00 00 01 80 00 ff ff ff ff ff
000013f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00001400 c3 f3 fb 44 06 50 b9 c2 f4 0d 6f 22 9f fe 1a
---hexdump -C r510test/pulled_port3/sector_156252335
00000000 31 90 71 58 fa 0e ce bc 44 65 6c 6c 20 20 20
00000010 10 00 00 72 10 28 1f 1e 02 ec 62 38 b8 74 7c
00000020 30 31 2e 30 30 2e 30 30 00 00 00 07 02 ec 62
*
00000060 00 00 00 00 09 50 38 af ff ff ff ff ff ff ff
00000070 01 ff ff ff 00 00 80 00 00 00 00 00 09 50 78
*
00000200 22 22 22 22 62 d4 ce c2 00 04 00 0e ff ff ff
00000210 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
00000240 41 54 41 20 20 20 20 20 20 57 44 2d 57 43 41
00000250 33 37 31 33 34 31 34 33 f0 18 4d 68 00 02 00
00000260 00 00 00 00 09 40 f8 af 58 42 b2 b0 55 b7 5b
*
00000600 dd dd dd dd b3 9e bf 13 00 01 00 02 ff ff ff

20
43
94

|1.qX]_xCDell
|
|...r.(....b8.t|C|
|01.00.00......l.|

ff
8f

|.....Oo.........|
|.............O..|

ff
ff

|""""...b........|
|................|

20
04
00

|ATA Y243A5DC
|
|
........|
|.....@/.XB..U.[.|

ff
ff

|................|
|................|

1e
00
ff

|Dell
...r.(..|
|..b8U...........|
|................|

33
20
ff

|3333.,.qATA Y243|
|A5DC
|
|................|

20
e9
ff

|.....7..Dell
|
|...r.(....b8U...|
|..l.............|

ff
ff
f8

|................|
|................|
|...D.P....o"....|

ff

|..l.............|

ff
ff
f8

|................|
|................|
|...D.P....o"....|

20
43
38

|1.qX....Dell
|
|...r.(....b8.t|C|
|01.00.00......b8|

ff
af

|.....P8.........|
|.............Px.|

ff
ff

|""""b...........|
|................|

56
01
00

|ATA
WD-WCAV|
|37134143..Mh....|
|.....@..XB..U.[.|

ff

|................|

25

HW RAID forensics
5 Appendices

*
00000660
*
00000a00
00000a10
00000a20
*
00000e00
00000e10
00000e20
*
00000fe0
00000ff0
00001000
*
00001220
*
000013e0
000013f0
00001400

f0 00 ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

|................|

33 33 33 33 2f ef aa 35
20 57 44 2d 57 43 41 56
f0 18 4d 68 00 00 ff ff

41 54 41 20 20 20 20 20
33 37 31 33 34 31 34 33
ff ff ff ff ff ff ff ff

|3333/..5ATA
|
| WD-WCAV37134143|
|..Mh............|

ee ee ee ee ac c5 2a 58
10 00 00 72 10 28 1f 1e
02 ec 62 38 00 00 00 02

44 65 6c 6c 20 20 20 20
02 ec 62 38 55 0c 0d e9
ff ff ff ff ff ff ff ff

|......*XDell
|
|...r.(....b8U...|
|..b8............|

09 00 01 ff 91 00 00 01
ff ff ff ff ff ff ff ff
c3 f3 fb 44 06 50 b9 c2

80 00 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
f4 0d 6f 22 f0 18 4d 68

|................|
|................|
|...D.P....o"..Mh|

02 ec 62 38 00 00 00 01

ff ff ff ff ff ff ff ff

|..b8............|

09 00 01 ff 94 00 00 00
ff ff ff ff ff ff ff ff
c3 f3 fb 44 06 50 b9 c2

80 00 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
f4 0d 6f 22 f0 18 4d 68

|................|
|................|
|...D.P....o"..Mh|

26

You might also like