Case Study 2 – Addonics HPM-XU Recovery

Recently we have dealt with an Addonics HPM-XU RAID controller. There were 4 disks of 8 TB which were combined into a RAID5:

The story started with the support request – a client complained that the RAID recovery software could not solve the case. We started working at the case, finally solved it, and now want to share our findings with you

So, as usual, all starts with the content analysis:

We see that the disks are from the same RAID set because entropy and zeros are about the same; more than that, there is parity and there are no mirrors. All this points to a normal 4-disk RAID5.

Next, launch the entropy analysis:

Get too many peaks, need to decrease the block size.

The block size is 32KB but still too many peaks; start to suspect 1-sector block size but do more tests.

There are 4 peaks for 2048-bytes block size: 2048/4=512 bytes, set 512-byte block size and get:

We see that the maximums, despite the unusual "picture", are still correctly located – they do not overlap and go one by one; based on the picture we get a disk ring: disk 3 - disk 2 - disk 5 - disk 4.

Next, look at the data on each drive one by one in the Disk Editor. Start with disk 2. Sector 0 contains a standard MBR:

Sector 1 contains a GPT header:

We see that there are typical MBR and GPT at the beginning of the disk; next use search to find the first non-zero sector and get sector 88064.

Interestingly, we see that this is a part of the loader data, which typically follows NTFS boot sector.

Now let's look at the disk 3. The sector 0:

Sector 1.

Sector 2.

We see the same MBR and GPT and then use search to get the first non-zero sector, the same sector 88064. Nothing interesting.

Now disk 4. Sector 0 with MBR.

Sector 1 – zeros.

The first non-zero sector is the same 88064.

The same procedure for disk 5. Sector 0 with MBR.

Sector 1 contains zeros.

And the first non-zero sector is 88064.

We see that sector 88064 on disk 5 holds NTFS boor sector, therefore disk 5 is the first one and then goes disk 2 (remember the second part of the loader data?). Now let's recall that according to the peak sequence of the entropy analysis the disk ring is 3-2-5-4. With our assumption about 5-2, we get 5-2-3-4.

Since the block size is 512 bytes, there is no offset and we can guess two configurations with disk 5 being the first:

Left array	Right array

By looking at the entropy analysis, we can guess a right layout but still try all the hypotheses.

Build manual configurations, check them and find out that this one works:

So our piggy bank now includes the configuration of Addonics HPM-XU: 512 byte block size, right, asynchronous layout.