Walkthrough. Investigating an SSD

I had an interesting job come in. A client wants the data off a dead SSD, and it’s a model that regular data recovery companies won’t deal with, an SK Hynix drive. It’s used extensively on many Dell laptops. The drive is NVMe which means it uses several PCIe lanes for communication.

First things first, let’s look at an identical part and work out what is onboard.

The SH88800AA controller seems to have virtually no publicly available information.

Interestingly, there is a PIC microcontroller on there, probably for power management.

The first port of call will be the power. Is this diode fine?

Then the PSU section.

We can chip-off this, but generally data on an SSD will be really hard to recover at this level.

This pin header is interesting. Lots of other controllers have a serial port which can be enabled for diagnostics. It’s a bit strange to label a serial port DO and DI, but the traces aren’t the right shape for faster interfaces such as USB.

There is also a 6 pin header. Drives often have JTAG, which can at least help you work out if the controller is alive or not. The slight marking on the pads indicates that these may be used during production, but that could just be tarnish.

Samsung and Sandisk SSD controllers are quite widely documented. There are off-the-shelf solutions that can be used to repair or recover data from these drives.

It’s likely based on a Link A Media Devices (LAMD) controller, as SK Hynix bought them a while back. Sadly doesn’t help much.

Now, let’s have a look at those three pins on the header. We’re using a Saleae Logic Pro 16 to sniff the interface.

38400 baud serial, “Perseus Bootloader : 4”. Googling that gives us nothing at all.

Now I connect up a USB serial adapter, assuming the other pin is receive. Samsung SSDs require two pins shorting to get into the recovery console… so I am not sure what we will see here.

Boom! A serial console, with Help!

There’s a full list of commands here https://pastebin.com/mBFzwWJf.

Interesting stuff. These are definitely made specifically for Dell. A full path of the build. “Perforce”, “Pegasus”, “Perseus”, “f16s_1024o4x2” – all useful terms to Google, but nothing really comes up.

The keys can be read via the serial console https://pastebin.com/546i7thm

The “n” command takes us to another series of commands for the NAND https://pastebin.com/YmiXSvXS

So I can read data…

Problem is readraw doesn’t take into account scrambling or encryption, and I can’t seem to get read to work.

The series of test pads in a row on the other side are actually for the PIC micro on it. This isn’t going to be a security relevant part, but it is worth checking voltages around it.

And although this footprint looks tempting from afar – 10 pins, possibly JTAG, a look under the microscope indicates it is something else. A missing package of some form?

Dell provides a tool to upgrade the firmware on these drives… But there is no separate firmware file.

I have found a Linux update for another SK Hynix drive (unpacked from initrd.img on a USB boot drive). It’s not similar though.

Back to the proper update file. 7zip extracts the resources from the .exe, including a FIRMWARE folder. With the firmware in it.

The firmware file contains multiple firmwares, all bundled up. A very helpful twitter contact wrote a script to unpack it all: https://twitter.com/xorloser/status/1105995761362202624

Next question; Ghidra or IDA?

I’m going with IDA because I know it works. It’s certainly ARM code. No idea on memory map and entry point, there’s lots of direct references in the 0x4000000 range though.

OK, so commands regr and mprint seem to show the same data. Reading an invalid address seems to result in a abort which dumps some registers, but not PC.

I think there are millions of these deployed, it’s interesting how there doesn’t seem to have been any work on them.

I’m going to keep on digging – both for the data recovery and potential vulnerabilities in the device.