# RR

| Field      | Value     |
| ---------- | --------- |
| Category   | Forensics |
| Difficulty | Medium    |

### **Challenge Overview**

The challenge title **“Reusing All of Internal Disks (RAID)”** strongly hints at **RAID** through the acronym. The description mentions that *one of the drives failed* and asks for help recovering the files.

We are given three disk images:

```bash
1.img
2.img
3.img
```

Inspection shows:

```bash
1.img → ~537 MB
2.img → 0 bytes
3.img → ~537 MB
```

Since **one disk is missing/empty**, the setup perfectly matches **RAID5**, which:

* requires at least **3 disks**
* **Three disks with one failed:** The challenge provides **3 disk images**, and **one is empty (failed)**. RAID5 is designed to tolerate **exactly one disk failure** with a minimum of **three disks**.

> **Note:** **Parity** is a **redundancy value calculated from data (usually using XOR)** that is stored so the system can **reconstruct missing data if one disk fails**.

RAID5 parity rule:

```
Parity = Data1 XOR Data2
```

Therefore if one disk is missing:

```
MissingData = Data XOR Parity
```

***

### **Exploitation**

Because `2.img` was **empty**, the missing disk could be reconstructed by **XOR-ing** the other **two disks.**

I used a small **Python** script was used to **rebuild** the missing image block by block:

```python
#!/usr/bin/env python3

file1 = "1.img"
file2 = "3.img"
output = "2_recovered.img"

with open(file1, "rb") as f1, open(file2, "rb") as f2, open(output, "wb") as out:
    while True:
        b1 = f1.read(4096)
        b2 = f2.read(4096)

        if not b1:
            break

        xor_block = bytes(a ^ b for a, b in zip(b1, b2))
        out.write(xor_block)

print("Recovered image written to", output)
```

This produced:

```shellscript
2_recovered.img
```

However, RAID5 **rotates parity across stripes**, meaning that a simple XOR reconstruction will only produce **partially correct data**. Some stripes are reconstructed correctly, while others become corrupted. As a result, the filesystem inside the reconstructed image cannot be mounted properly.

Running **binwalk** on the reconstructed image revealed embedded file signatures:

```bash
binwalk 2_recovered.img
```

Among the results was a JPEG header:

```
69476352  JPEG image data, JFIF standard 1.01
```

Because the filesystem was corrupted, **file carving** was used to recover files directly from raw data. Searching specifically for common formats:

```bash
binwalk -y jpeg -y png -y gif -y pdf -y zip -y iso -y tiff -y mp3 -y wav -y rar -y bmp -y seven_z 2_recovered.img
```

After identifying the JPEG offset, the image was manually extracted using `dd`:

```bash
dd if=2_recovered.img of=image.jpg bs=1 skip=69476352 count=2*1024*1024
```

Even though some RAID stripes were corrupted, **JPEG is tolerant to partial corruption**, allowing the image to be displayed.

Opening the extracted file revealed a **partially corrupted image containing the flag**. If the RAID had been reconstructed properly, we would've obtained the entire **image**.

*made by k0d*
