Reversing and cracking external self-encrypting drives has been a longtime hobby of mine. In the past, I have had the opportunity to practice with models such as Zalman VE-400, Zalman ZM-SHE500, Zalman ZM-VE500. Just recently, a colleague brought me another exhibit: Patriot (Aigo) SK8671, which is built according to a typical design - an LCD indicator and a keypad for entering a PIN code. That's what came out of it…

1. Introduction
2. Hardware architecture
– 2.1. Main board
– 2.2. LCD display board
– 2.3. Keyboard board
– 2.4. Look at the wires
3. Sequence of attack steps
– 3.1. We remove the data dump of the SPI flash drive
– 3.2. Sniffing communications

1. Introduction

Chassis

Packaging

Access to the data stored on the disk, which is supposedly encrypted, is carried out after entering the pincode. A few introductory notes on this device:

To change the pincode, you must press F1 before unlocking;
The pincode must contain from 6 to 9 digits;
After 15 incorrect attempts, the disk is cleared.

2. Hardware architecture

First, we dissect the device into parts in order to understand what components it consists of. The most tedious task is opening the case: a lot of microscopic screws and plastic. Having opened the case, we see the following (pay attention to the five-pin connector soldered by me):

2.1. Main board

The main board is pretty simple:

The most notable parts of it (see top to bottom):

connector for LCD indicator (CN1);
squeaker (SP1);
Pm25LD010 (specification) SPI flash drive (U2);
Jmicron JMS539 controller (specification) for USB-SATA (U1);
USB 3 connector (J1).

The SPI flash drive stores the JMS539 firmware and some settings.

2.2. LCD display board

There is nothing remarkable on the LCD board.

Only:

LCD indicator of unknown origin (probably with a Chinese font set); with sequential control;
ribbon connector for keyboard board.

2.3. Keyboard board

When examining the keyboard board, things take a more interesting turn.

Here, on the back side, we see a ribbon connector, as well as Cypress CY8C21434 - PSoC 1 microcontroller (hereinafter we will simply call it PSoC)

CY8C21434 uses the M8C instruction set (see documentation). On [product page]( (http://www.cypress.com/part/cy8c21434-24ltxi) is indicated that it supports the technology capsense (solution by Cypress, for capacitive keyboards). Here you can see the five-pin connector I soldered - this is the standard approach for connecting an external programmer via the ISSP interface.

2.4. Look at the wires

Let's figure out what is connected with what here. To do this, just ring the wires with a multimeter:

Explanations for this diagram drawn on the knee:

PSoC is described in the technical specification;
the next connector, the one to the right, is the ISSP interface, which, by the will of fate, corresponds to what is written about it on the Internet;
the rightmost connector is the terminal for the ribbon connector with the keyboard board;
the black rectangle is a drawing of the CN1 connector, designed to connect the main board to the LCD board. P11, P13 and P4 - Connected to PSoC pins 11, 13 and 4 on the LCD board.

3. Sequence of attack steps

Now that we know what components this drive consists of, we need to: 1) make sure that the basic encryption functionality is really present; 2) learn how encryption keys are generated/stored; 3) find where exactly the pincode will be checked.

To do this, I did the following steps:

took a data dump of the SPI flash drive;
tried to dump PSoC flash drive data;
made sure that the communication between Cypress PSoC and JMS539 actually contains keystrokes;
made sure that when changing the password, nothing is overwritten in the SPI flash drive;
was too lazy to reverse 8051 firmware from JMS539.

3.1. We remove the data dump of the SPI flash drive

This procedure is very simple:

connect the probes to the legs of the flash drive: CLK, MOSI, MISO and (optionally) EN;
"sniff" communications with a sniffer using a logic analyzer (I used Saleae Logic Pro 16);
decode SPI protocol and export results to CSV;
take advantage decode_spi.rbto parse the results and get a dump.

Please note that this approach works especially well with the JMS539 controller, since this controller loads all the firmware from the flash drive during the initialization phase.

$ decode_spi.rb boot_spi1.csv dump
0.039776 : WRITE DISABLE
0.039777 : JEDEC READ ID
0.039784 : ID 0x7f 0x9d 0x21
---------------------
0.039788 : READ @ 0x0
0x12,0x42,0x00,0xd3,0x22,0x00,
[...]
$ ls --size --block-size=1 dump
49152 dump
$ sha1sum dump
3d9db0dde7b4aadd2b7705a46b5d04e1a1f3b125 dump

After dumping the SPI flash drive, I came to the conclusion that its only task is to store the firmware for the JMicron control device, which is built into the 8051 microcontroller. Unfortunately, dumping the SPI flash drive turned out to be useless:

when changing the pin code, the dump of the flash drive remains the same;
after the initialization stage, the device does not access the SPI flash drive.

3.2. Sniffing communications

This is one way to find which chip is responsible for verifying the communications for the time/content of interest. As we already know, the USB-SATA controller is connected to the Cypress PSoC LCD via a CN1 connector and two ribbons. Therefore, we connect the probes to the three corresponding legs:

P4, general I/O;
P11, I2C SCL;
P13, I2C SDA.

Then we launch the Saleae logic analyzer, and enter on the keyboard: “123456~”. As a result, we see the following diagram.

On it we can see three data exchange channels:

channel P4 has several short bursts;
on P11 and P13 almost continuous data exchange.

Zooming in on the first burst on channel P4 (the blue box in the previous figure), we see the following:

Here you can see that on P4 almost 70ms of a monotonous signal, which, as it seemed to me at first, plays the role of a clock signal. However, after spending some time to test my guess, I discovered that this is not a sync signal, but an audio stream that is output to the buzzer when the keys are pressed. Therefore, in itself, this section of the signal does not contain useful information for us. However, it can be used as an indicator - to know the moment when PSoC registers a keystroke.

However, the last audio stream of channel P4 is a bit different from the others: it's the audio for the "wrong pincode"!

Returning to the keystroke diagram, when the diagram of the last audio stream is enlarged (see again the blue rectangle), we get:

Here we see monotonous signals on P11. So it looks like this is the sync signal. And P13 is data. Notice how the pattern changes after the end of the beep. It would be interesting to see what happens here.

Protocols that work with two wires are usually SPI or I2C, and the Cypress data sheet says that these pins correspond to I2C, which, as we can see, is also true for our case:

The USB-SATA chipset constantly polls the PSoC - to read the state of the key, which is "0" by default. Then, when you press the "1" key, it changes to "1". The final transmission immediately after pressing “~” is different if a wrong pincode is entered. However, at the moment I have not checked what is actually transmitted there. But I suspect that this is hardly the encryption key. Anyway, see the next section to understand how I removed the ladies of the PSoC internal firmware.

Source: habr.com

Reversing and hacking Aigo self-encrypting external HDD. Part 1: Dissecting the parts