Table des matières

1 Introduction

1.1 The target

Analysing the security of hardware products seems to scare software reversers and hackers. It used to scare us.

But, fortunately, today there is no need to know much about electronics, as most products are just System on Chip (SoC), a single integrated circuit with IO and a CPU or microcontroller. All that is needed is a bit of soldering ability, a multimeter, some useful pieces of hardware and a brain.

The subject here is not embedded systems in the now common sense of small hardware running Linux but smaller systems using one or two chips.

Most interesting for software hackers are encrypted HDD/USB keys : their functionnality is conceptually simple and they provide an interesting target.

We will focus on the Zalman VE-400 encrypted drive, a consumer enclosure for 2.5" SATA hard drives which supports hardware encryption. It also supports advanced features like mounting ISO les as virtual optical drives. To do so, the user must choose between the ExFAT and NTFS lesystem support, by reashing the correct rmware.

Encryption is unlocked by a physical PIN pad, which makes it particularly interesting because the absence of unlocking software on the PC means that everything is done on the drive itself.

1.2 Methodology

This article presents the approach we applied on this drive, from basic aspects to in-depth details. It starts with basic analysis of drive functionnality, followed by a PCB analysis. We then explain how we try to access the code running on the board and proceed to do a black box analysis. With the results, we mount a potential attack, which fails. We nally review our research and conclude.

2 Getting started

2.1 Before opening the drive

The idea is to understand the functionnalities and the limitations as best as possible before going into the technical details.

This means :

• activating encryption : PIN is between 4 and 8 digits
• trying to change the PIN : not possible
• disabling encryption : wipes the drive (probably deletes the key)
• entering bad PINs : incremental wait between trials

Basic cryptographic checks

Of course, as we are dealing with encryption, we must verify that data seems encrypted and that the (key,IV) pair is not constant. This can be done with simple steps :

1. congure encryption
2. write zeros on the drive
3. remove drive from enclosure
4. read encrypted data (A) directly from the disk (use a normal USB/SATA bridge)
5. verify that the entropy is very high and that the block cipher mode ECB is not used ¹

In our case, the encrypted blocks have high entropy and ECB is apparently not used ; the documentation states AES-XTS is used, which is the current standard mode for disk encryption [8]. We must also check that resetting encryption actually changes the encryption key (or IV) and that it is not directly derived from the PIN :

1. using the same VE400, disable and recongure encryption with the same PIN
2. write zeros again
3. ensure that the (raw) encrypted data is dierent from read A

After verication, our enclosure encrypted the same zeros to a dierent output, which means that the encryption key (and hopefully not only the IV) is changed everytime the PIN is congured, which is good.

Is encryption tied to the enclosure ?

Before digging deeper, a simple step can give us information about where the secrets ² needed to decrypt the drive are stored :

1. put HDD in enclosure A
2. congure encryption with PIN P
3. write zeros
4. put HDD in a new, out of the box, enclosure B
5. analyze behavior

With the VE400, the result is surprising : everything works ! Putting an encrypted HDD in another enclosure and entering the correct PIN lets you access the data.

This means that everything needed to decrypt the data is stored on the encrypted disk itself and not in components of the enclosure.

Everything needed to decrypt the drive data is stored on the drive itself. No secret is present in the enclosure.
The attacker should be able to brute-force the PIN or extract the encryption key only in software.

Summary 1

2.2 Analysing secrets stored on disk

As we know that the secrets are stored on the HDD itself, we must nd where and how.

The procedure is simple :

1. ll raw drive with zeros
2. enable encryption in enclosure
3. dump raw disk content (outside enclosure)
4. analyse dierences

The only part that changes is the end of the drive, ten sectors before the end. We can see two identical blocks with high entropy, 0x300 bytes long :

After reconguring encryption, with the same PIN, the whole block changes.

What could be stored in this blob ? It is hard to say, but, depending on the cryptographic scheme used to derive encryption keys, the secret may include :

• the AES-XTS encryption keys and IVs
• the PIN hashes
• random IVs for deriving the PIN into encryption keys

So, we know that the sensitive data is stored encrypted at the end of the disk in an opaque encrypted blob. We also know that this blob is decryptable by all Zalman enclosures.

The main goal is to understand the encryption of secrets stored at the end of the disk. Accessing the decryption code should enable PIN bruteforce or data decryption.
We must now analyze the PCB to try to access to the rmwares.

Summary 2 - Goal denition

3 PCB

3.1 Identifying components

The board identies itself as an iodd 2541, from Korea. A little Google search clearly shows that the Zalman (a Korean company) disk is just a rebranding of the iodd one.

Reading the markings on the main components gives us :

• one Fujitsu MB86C311A USB3-SATA controller (1 on gure 1)
• one PIC32MX150F128D MIPS microcontroller (3 on gure 1)
• two EEPROM SPI EN25F80-100HCP ash (2 on gure 1, 4 on gure 2)

Before going further, looking for datasheets is essential, as they will give us information on the features of each chip and, most importantly, the role of each pin.

While nding the datasheets for the PIC and EEPROM is straightforward, the Fujitsu controller is only briey described on the ocial site. Luckily, some leaked datasheets are available on Chinese sites ³ , mostly for the previous version of the controller, the MB86C30, but we also have the pinout of the MB86C311A.

The Fujitsu datasheet states that the rmware can be customized, in which case it is stored on an external SPI ash chip. Some interestings excerpts from the datasheet :

• Control Information of Encryption is stored in serial ash.
• MB86C30 has also additional Encryption function for Firmware itself which is stored in serial ash.

It may also be interesting to look for other products using the same SoC : the PlayStation 4 or the Bualo LBU3. They may provide more information via rmware updates or manuals.

3.2 PCB traces analysis

To map chips with functionnalities, following the traces on the PCB is essential. Fortunately, this PCB only uses 2 layers, one on each side. Traces are connected from one side to the other by vias, caracteristic little holes.

Our primary tools for analysis are :

• a multimeter, in beep mode
• GIMP, with aligned pictures of both sides, one per layer, to follow traces which use vias

Ideally, we would use an X-Ray machine to get a view of both sides simultaneously. However, with only our basic equipment, we nd that ⁴  :

• the PIC is connected to the keypad using pins 19, 20 and 23 to 27
• the ash on the back is connected to the PIC
• the ash near the Fujitsu is connected to the SPI pins of the SoC
• the PIC is connected to the Fujitsu's GPIOs by PINs 9,10,42,43,44
• the PIC is connected to the LCD screen
• the PIC is connected to the J3 6-pads connector on the back side

It should come as no surprise that the PIC is responsible for handling display and input. Of course, it must exchange information with the SoC, hence the connections. Both ash chips are probably used for rmware and/or settings storage. While the PIC has an internal ash, its size may not be sucient.

4 Trying to get the code

As software hackers, our prefered way is to do everything using IDA. So before attacking hardware, we look for easier ways. Luckily, Zalman provides a tool to update their product's rmware, which we will study rst.

4.1 Firmware updater

Basics

Hopefully the code will be directly available in the rmware update. On the manufacturer website [2] , two rmware versions are available : one for FAT lesystems and one for NTFS lesystems.

After extraction, and the merge of both versions, the le listing is :

Unfortunately, the micom (probably short for microcontroller, so PIC) and SoC rmwares are encrypted.

The PIC one is probably protected with a real block cipher as the two (presumed) very similar rmwares VE400_micom_1-48(FAT).mic and VE400_micom_1-48(NTFS).mic are completely dierent

However, the two SoC rmwares are probably encrypted with a stream cipher, as we can see on gure 4.

The .ini les also contain interesting parameters :

Our hope at this point is that the rmware will be decrypted by the update app and not by the board itself. So we will have to reverse the update process.

Reversing the update process

Since we are interested only by the hardware reversing process, we will not detail the reversing of the rmware update application.

Just looking at the dialog boxes contained in the resources section is interesting, gure 5 shows that micom le most probably is used in the PIC32 eld. Which validates our initial hypothesis.

The only interesting result from the reverse process is that the settings read from the ini les are stored in several binary structures that are then transferred to the USB device using standard SCSI-over-USB commands.

The rmware itself is never decrypted, as a basic check with Wireshark and USBPcap could have shown from the start.

Since we could not get the code directly from software, we will have to get it from the hardware itself.

We will start with the PIC, which is easier, in theory.

4.2 PIC32MX

Every modern micro-controller contains ash or EEPROM memory to store program code and data. Programming is done by putting the controller in a special mode, usually by running a specic sequence on some pins. Most of them also include a way to protect the code against external reading so that manufacturer can ship microcontrollers to customers without having the code read, mostly to protect against clones.

PIC32MX microcontrollers support two dierent ways of interacting : standard JTAG and ICSP, the Microchip proprietary In-Circuit Serial Programming interface. ICSP has the advantage of only requiring 2 pins for data exchange.

Trace analysis showed that the J3 6-pads header on the back (gure 2) is connected to pins that are used for ICSP access.

The pinout is standard :

Of course, Microchip provides a way of protecting the code stored into the PIC : the conguration bits include a Code-Protect bit⁵ which Prevents boot and program Flash memory from being read or modied by an external programming device.. This bit can only be cleared to enable the protection, to disable it, the chip must be fully erased.

We will now try to use this ICSP header to check if the PIC is protected.

PICkit 2

We need a PIC programmer to interact with our target from the host. One of the most interesting options is the PICkit 2, which is a cheap (25e) USB programmer for PIC microcontrollers. As its design is open, it is very well supported by open source programs but is now unsupported by Microchip.

So, in theory, we should use the more cumbersome PICkit3 to interface with PIC32MX but, thanks to the opensource pic32prog tool [4], we can directly use a PICKit 2 to interact.

As show on the gure 2, the pad/test point ⁶ for J3 header are big enough to solder wires.

Once small wires have been soldered ⁷ to the J3 header and interfaced with the PICkit, we can check the code-protection status. pic32prog displays the dreaded message : Device is code protected and must be erased first So, protection is enabled. It is even impossible to read the conguration registers :(

Before admitting defeat, we read PIC32 Flash Programming Specication datasheet[3] thoroughly but could not nd any attack.

Other options

As we know from reversing that the rmware update contains encrypted code for the PIC, its core is upgradable. It most probably uses a bootloader to be reashed. While we could not nd any publicly available bootloaders that implement encryption, some commercial oers exist and may have been used. Potential vulnerabilities may help recover the code.

While some logical attacks exists on smaller PICs, mostly the PIC18F family, which involve erasing parts of the code, no public attack exists for PIC32MX.

In last ressort, as the PIC32MX is not a secure chip, it is always possible to use physical attacks to access the code. They usually involve chemical decapping. Quite a few companies oer such services for a fee of several thousands USD.

4.3 Fujitsu MB86C311A

The datasheet of the SoC states that the code can be loaded from an external SPI ash chip. We will look at this option in the next subsection.

Another possibility is an possible JTAG/SWD port. Unfortunately, the datasheet we have does not mention such port. While some pins are named PTST/TMODE, which could indicate a test port, looking closely at the documentation suggests they are really used to switch between two modes and do not indicate a debug port.

4.4 SPI ash chips

Since we are unable to access the code directly from the chips, we will dump the SPI (Serial Peripheral Interface) ash chips to see if their content is also encrypted.

The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specication. SPI devices communicate in full duplex mode using a master-slave architecture with a single master. The SPI bus species four logic signals :

• SCLK : Serial Clock (output from master).
• MOSI : Master Output, Slave Input (output from master).
• MISO : Master Input, Slave Output (output from slave).
• SS : Slave Select (active low, output from master).

Unfortunately, dumping SPI ashes directly from the board using a SOIC clip is usually hard, as the current will also power surrounding chips that will interfere. So, unsoldering is needed. However, it is interesting to re-solder the ash on a SOIC to DIP connector in order to keep the board functionnal and usefull for subsequent analysis (see gure 6).

It is important to note that when you unsolder the ash, you should pay attention to the temperature. If the temperature of your soldering iron is too high, metal traces on the PCB could separate from the board and loose connectivity.

Another mistake often made is unsoldering pins one by one by using something to raise the pin. But it frequently leads to breaken pins or to traces disconnected from the PCB. A good solution is to use tweezers soldering iron, as on gure 7.

So after unsoldering, dumping the chip is just a matter of using a :

• GoodFET with goodfet.spiash
• Bus Pirate via SPI port
• RaspberryPI with spi.dev

Just do not forget to put the HOLD pin at VCC, otherwise commands may be ignored.

After dumping, we unfortunately note that both chips contain the same encrypted data that we had in the rmware updater :

• the SoC SPI contains : a conguration block, USB descriptors, unknown data, encrypted rmware, font (for LCD display), encrypted PIC rmware
• the PIC SPI contains : font (for LCD display), encrypted PIC rmware

While looking for information on the Fujitsu SoC, we came across information related to the PlayStation 4, which uses a very similar controller, the MB86C311B, which doesn't include encryption. [5] links to a dump of its ash.

Comparing the dump from the PS4 ash with ours shows that :

• the conguration block at the beginning is mostly the same
• USB descriptors dier
• only our dump contains high-entropy data @ 0x1000
• the rmware code seems to be encrypted with the same key

So, we probably have encryption related data at address 0x1000.

Unfortunately, we are stuck, since we could not get any code from our dumps.

5 Blackbox analysis

Since we have two chips with very dierent uses, we can probably gain valuable information by sning :

• communications between them
• accesses, both read and write, to SPI ashes

This section will focus on describing the process of placing probes and analyzing the signals. Everything will be done using a logic analyzer. We used the Saleae Logic Pro 16, which is both convenient and performant.

5.1 Placing probes

Since section 3.2 we have a good idea of which pins are used for communication between the SoCs and for ash access. Some are used for both, which is quite handy because the logic probes are small enough to be directly attached to the SPI pins. Figure 8 shows the important traces and where the probes have been connected : Chip Select, Clock , and DI/DO pins.

Other pins will have to be connected by soldering thin wires (strap wire) to the relevant PIC pins.

Figure 9 shows the kind of wire we used and gure 1 shows the end result when soldered on the board.

Figure 10 shows what it looks like when the probes are placed on the PCB.

5.2 Sning and decoding

Once the probes are placed, we just have to setup a trigger, which will determine when to start recording. Obvious options include : the Chip Select pin of an SPI ash, or the clock pin. We will use the latter.

Before going into details, some words on SPI : it is a simple serial protocol, which uses 4 wires for transfering data [9] :

• /CS : chip select, held low to activate the chip we want to talk to
• CLK : the clock, used to sample bits
• DO/MISO : Data Output or Master Input Slave Output : data coming out of the chip
• DI/MOSI : Data Input or Master Output Slave Input : data arriving to the chip

We know that the bus is shared for communications with the SPI ash and the PIC, so our capture will probably include both.

Figure 11 shows the result in the analyzer window.

Figure 12 shows a trace with both communications. The red block, on the left, clearly contains communications from the SoC to the ash as the CS pin is brought low (not visible here) for each transfer. While the blue block, on the right, is dierent : the CS pin is maintained high while the pins CLK, DO, 44 and 43 are active.

Figure 13 shows the beginning of the blue block in details. Analysis is rather straightforward :

• CLK (named from the SPI ash pin) is obviously also a clock
• DO is also used for data transfer
• pin 44 is used as a CS for the PIC
• pin 43 is used as a broader CS, as seen on gure 12

Figure 13: Detail of PIC$SoC communications

Since the protocol looks like SPI, we will also use the SPI decoder to export the trace to CSV for further analysis.

5.3 Analysing the traces

SPI Flash chips

SPI serves as the underlying protocol for ash memory access. While no ocial standard seems to exists, most SPI ash memories support the same simple procotol, as specied in the datasheet [1].

While the Saleae software includes protocol decoders, including SPI, it does only decode the transport, and not the ash commands. However, we can export the decoded SPI frames to CSV and decode the ash commands from this input :

into commands : READ, RSR, WSR, etc.

A little Ruby script will parse the CSV le using a simple state machine and output the actual commands. The only detail we have to pay attention to is the boundary of commands, in particular for the READ answer which can return an arbitrary amount of data. The CS pin is used in hardware, but as it is not exported in the CSV, we use timing information to detect the end of transfers. The result looks like this :

The following commands are present :

• WREN : write enable
• PP : page program (write)
• RSR : read status register
• READ : read

Since we can decode the addresses of READ commands and get the returned data, we can also dump the binary data to a le, which can be compared with the dumps we acquired by reading the ash chips directly.

PIC

Contrary to the ash chips, we do not know the upper layer protocol used to communicate :

We have to do a black box analysis of the protocol. We can readily identify two interesting patterns : 0xAA,0xAA,0xAA,0xAA,0x55 and 0xA5,0xA5,0xA5,0x5A which are at the start of each transmission block (pay attention to the timings).

Such patterns are usually syncwords/preambles used to indicate the beginning of a frame. Since the DATA line is used for both directions, each preamble probably corresponds to one direction.

Comparative analysis of several traces allows us to determine the following frame structure :

• preamble (4 or 5 bytes)
• length (1 byte)
• type (1 byte)
• frame id (1 byte)
• data (length-2 bytes)
• checksum (2 bytes)

Putting all together in a Ruby script gives us :

which shows a request of type 0x33 from the SoC to the PIC (S->P) with ID 0x14, which is answered by the PIC.

6 Sni ALL THE THINGS

Since we cannot read the code, we will read the communications and try to determine how the following works :

• valid PIN check
• invalid PIN check (1st try)
• invalid PIN check (Xth try)
• encryption enabling
• encryption disabling
• boot with encryption

Of course we will probably be unable to have the ne details, but we may be able to understand the role of each chip and how the storage capabilities are used.

6.1 PIN checks

Basic check

To understand how PIN verication works, we boot the disk and only start sning before pressing the enter key. The trac on the bus after entering 11111111 and 12345678 as PINs is :

We see here that the communication consists in the SoC asking something to the PIC, which replies with some data.

Looking at the previous trace, the roles of each message is not obvious. Looking at the full trace may help identifying messages, in particular, which message transmits the PIN :

It seems that the SoC is requesting the PIC for the PIN (interestingly, we do not see any trac before we press the Enter key on the keyboard, we do not know why). However, we see that only 8 bytes dier in the response.

Also, data sent by the PIC seem like a deterministic hash of the PIN, as collected samples show :

As the hash is transmitted to the SoC, it is probably in charge of verifying the PIN. The message giving the result (good) to the PIC could be either 07,01,01,01 or 09,01,01,01. We can also see the dierent response times : almost instant for bad PIN, a second for a good one.

Bad PIN delays

Sning a verication where a bad PIN is entered for the Xth time is interesting :

The PIN hash is transmitted right away but the PIC is pinged by 0x37 frames while the wait is on going.

So by sning, we can tell if the PIN was good or bad right away and restart the disk to bypass the increasing delay (see [6] for a similar attack).

6.2 Monitoring the SPI ash

While checking the communications between the SoC and the PIC is interesting, combining this information with read and writes to the ashes allows us to have a better overview of the external interactions of both chips.

Good PIN entry

Notably, this is the trace of a successful PIN entry, showing both inter-chip comms and SoC ash accesses :

When a good PIN is entered, the SoC rewrites 0x1BC bytes at 0x1000, and nothing happens when a bad PIN is entered. So maybe this block contains some crypto related data ?

Enabling encryption

Checking what happens while enabling encryption can give clues. Interestingly the trace show the same behaviour as entering a good PIN :

1. the hashed PIN is sent to the SoC
2. the block at 0x1000 is erased…
3. …then rewritten

While enabling encryption implies using the last 10 sectors for the enclosure's internal use, the size presented by the drive is still the same. However, trying to read or write those sectors just doesn't work so the SoC probably lters access.

Disabling encryption

Disabling encryption give the following :

1. read of data at 0x1000
2. hashed PIN is sent to the SoC
3. sector erase of 0x1000

Of course the block stored at the end of the HDD is also zeroed and normal access is restored.

SPI block at 0x1000

Analysing the block written at oset 0x1000 in the ash could help understanding its role.

The 00 ff 40 00 and 80 ff 40 00 sequences are TLV-style delimiters, also used in the device conguration blocks generated by the rmware updater. The role for the rest of the data is not evident. The two TLV blocks are followed by 512 bits of data, which could represent the two keys needed for AES-256-XTS. We could determine that the last 32 bytes are the SHA-256 hash of the beginning of the block.

We tested the possibility that the block directly contains the AES keys by bruteforcing every possible combination of two blocks of 32 bytes as the keys for AES-XTS and by trying to decrypt sector 0 with AES-XTS. Unfortunately the result was negative.

So, as this data is written after a good PIN entry, we suspect it contains material necessary to decrypt the drive, such as the AES-XTS keys. They are however probably encrypted or obfuscated.

One hypothesis is that the SDK from Fujitsu contained an example for encrypted drives which stores the keys in the SPI ash. That code could have been reused by the developers of the drive.

7 Attack Attack !

7.1 Theory

Summing up everything we have seen so far, the boot process seems to be :

1. custom rmware in the SATA controller check if there is an encrypted block at the end of the HDD (10 sectors before the end)
2. if a valid block is found it asks the PIC for a PIN
3. PIC gets the PIN from user
4. PIC hashes the PIN and sends it to SATA
5. SATA validates the PIN against the data previously read at the end of the disk
6. if the PIN is valid, encryption related data is written at oset 0x1000 in the SATA SPI ash
7. encryption processing is enabled

So, since the data necessary to decrypt the disk is probably stored in the SATA SPI ash, we conceived the following attack :

1. attacker setups an enclosure and drive with PIN (named A)
2. get a victim HDD, copy ash + HDD (named V )
3. write ash V to attacker SoC ash
4. make the attacker SPI ash read only
5. build HDD with : victim data and attacker encryption block (containing PIN/key A)
6. enter PIN A
7. SoC reads block A to verify PIN A : success
8. SoC tries to write data A in SoC ash but fails
9. SoC reads back block V from SoC ash
10. disk is decrypted using key data from block V

In theory, the PIN should be veried against the data stored at the end of the disk, which we overwrote with a block containing a PIN we chose. But since the SPI ash is read-only, the actual key used for decrypting the victim HDD should remain untouched and used to access the target data.

7.2 Practice

Writing the ash and making it read only is just a matter of a few GoodFET commands :

Of course, the theory never works at the rst try. When we rst tried our attack, the key data in the ash was overwritten even though we set it up read-only. Analysing the boot with the logic analyzer showed that the SoC actually resets the status register to 0, removing the protection.

So, to avoid this problem, we just changed the ash content and set the status register after boot but before entering our known PIN. Figures 14 and 15 show how we setup the attack using a socket for the ash.

But, unfortunately, the attack did not work, the drive did not unlock. So it most probably checked that the data written on the ash was actually written.

8 Conclusion

Starting with no information, we managed, in full black box, to have a good understanding of the way this encrypted drive enclosure works.

While we know the crypto design is a fail, because all the encryption related data is stored on the drive itself, with no enclosure dependent secret, we were unable to actually exploit it.

However, accessing the code running on the USB$SATA bridge would be enough to compromise the security trivially : we could reproduce the decryption of the block at the end of the drive and access the keys or bruteforce the PIN code, which is limited to 8 chars.

To achieve this goal, several options can be considered :

• someone leaks the Fujitsu key used to encrypt the external rmware in the SPI ash, as it is shared by all Fujitsu SoCs
• a vulnerability in ARM or MIPS code : NTFS/exFAT parsing for ISO mounting, SPI parsing, USB parsing ?
• low level hardware attack : chip decapping
• side-channel attacks

Regarding the reverse engineering process we applied in this study, we showed that everything is actually doable in software using relatively cheap tools : Bus Pirate/GoodFET, Saleae, etc. The only hard thing to get is steady hands ;)

And in the end, this process is not that dierent from reversing an unknown network protocols in black box.

We now hope that you will feel attacking hardware is not that hard :)

Références