Table des matières

1 Introduction

2 Getting started

3 PCB

4 Trying to get the code

5 Blackbox analysis

6 Sni ALL THE THINGS

7 Attack Attack !

8 Conclusion

Attacking hardware for software reversers : analysis of an encrypted HDD

Jorey Czarny et Raphaël Rigo

firstname.lastname@airbus.com

Airbus Group Innovations

Résumé The idea of this presentation is to debunk the myth that analyzing the security of hardware is dicult. From the perspective of a software reverse engineer we present the process of studying a hardware-encrypted, PIN secured, external hard drive : the Zalman VE-400.

While the end result of the analysis and attack is not a full success as it was not possible to recover an encrypted drive, it shows that the drive is nevertheless vulnerable by design.

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 [1]

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 [2] 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 :

# dd if=/dev/sdf bs=1M skip=476920 | hd

1404c00  fb f4 be fa 14 1a c7 b2  2f a2 a0 df 52 b6 ae bf

1404c10  07 36 f6 50 04 b0 fc fa  c7 cc f7 2d 54 2e 14 5c

1404c20  be 88 1c 55 90 3a 0d 49  61 09 e0 8d a1 83 2d ad

1404c30  e3 61 61 bc fb b5 07 38  fb da e1 0a 4a cb e8 c4

1404c40  00 d7 f7 07 d4 3d 2c fd  1b 61 37 8b 6f a2 d3 69

1404c50  f3 bf b9 64 9a 1f cb d3  28 0d 69 89 5b d6 05 fb

1404c60  80 2b 98 ac ff 54 80 2b  40 57 ce a0 5b be 7b c7

1404c70  a4 5c 90 3c f6 47 2f 68  70 85 3c 52 e2 80 56 bf

[...]

1404ec0  a8 62 20 d8 8f 01 df 6f  1a c1 87 41 5d 75 c9 05

1404ed0  1c a4 d5 22 63 de cb 60  c4 83 ef f2 ca fc 0f 7b

1404ee0  6e f6 e5 76 0d 85 01 65  12 62 59 25 da 0b be c1

1404ef0  72 bf 73 2c 04 62 52 9c  bf 29 28 ee 82 4e 96 0e

1404f00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

*

1405000  fb f4 be fa 14 1a c7 b2  2f a2 a0 df 52 b6 ae bf

[...]

Data 1 - Block at the end of drive

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

Figure 1: PCB front side

Figure 2: PCB back side

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 [3] , 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 [4]  :

- 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.

Figure 3: Schematic view of the various components

Now that we know the dierent components, as summarized on gure 3, we would like to dump the code from the PIC and Fujitsu controllers to complete our understanding.

Summary 3

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 :

config-zalman-ve400-02.ini

font5_worldwide_01.fon

fw-integrity.dll

VE400_firmware_1-48(FAT).bin

VE400_firmware_1-48(NTFS).bin

VE400_micom_1-48(FAT).mic

VE400_micom_1-48(NTFS).mic

zalman-fw-updater-03.exe

zalman-fw-updater-03.ini

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.

Figure 4: Binary di of rmware updates

The .ini les also contain interesting parameters :

[Authentication]

AuthWait=1

DeleteKey=00000000000000000000000000000000

[Control Parameter]

SFlashSecret=1

Extract 1 - INI params

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.

Figure 5: Firmware updater settings dialog extracted from ressources

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.

As the rmware updater only contains encrypted rmwares transfered as-is to the hardware, we must attack the hardware.

Summary 4 - Failure, next step

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 :

2 o  4 o  6 o           1 : MCLR     2 : VCC (3,3v)

3 : GND      4 : PGED

1 o  3 o  5 o           5 : PGEC     6 : unused

Of course, Microchip provides a way of protecting the code stored into the PIC : the conguration bits include a Code-Protect bit[5] 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 [6] for J3 header are big enough to solder wires.

Once small wires have been soldered [7] 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).

Figure 6: Unsoldered ash

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.

Figure 7: Tweezers soldering iron / Credit : Aisart on Wikipedia (CC-BY-SA 3.0)

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.

Dumping code from the SoC and PIC failed.

We must move to black box, by analyzing communications.

Summary 5 - Fail ! Next step

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

Figure 8: Physical traces and probes placement

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 9: Strap wires

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

Figure 10: Logic analyzer probes placed

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 11: Logic analyzer results

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 12: Trace of both ash and PIC$SoC communications

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 :

Time [s],Packet ID,MOSI,MISO

0.000000000000000,0,'5' (0x05),'5' (0x05)

0.000000510000000,0,'0' (0x00),'0' (0x00)

Data 2 - Raw SPI ash commands

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 :

0.116114 : WREN

0.116118 : PP @ 0x11b8

0x74,0x38,0xac,0x67

0.116124 : RSR : 3

[...]

0.116139 : RSR : 0

---------------------

0.116171 : READ @ 0x1000

0x00,0xff,0x40,0x00,0x26,0xf9,0x9b,0xf3,0x6b,0x45,0xf7,0x11

0.116183 : READ @ 0x100c

0xd4,0x83,0x1b,0x7a,0xce,0x5a,0x2e,0xa2,0x2f,0xe1,0xf2,0x69

Data 3 - Interpreted SPI ash commands

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 :

Time [s],Packet ID,MOSI,MISO

0.00000000,,'170' (0xAA),'170' (0xAA)

0.00000274,,'170' (0xAA),'170' (0xAA)

0.00000549,,'170' (0xAA),'170' (0xAA)

0.00000823,,'170' (0xAA),'170' (0xAA)

0.00001098,,U (0x55),U (0x55)

0.00001389,,'8' (0x08),'8' (0x08)

0.00001663,,3 (0x33),3 (0x33)

0.00001938,,'20' (0x14),'20' (0x14)

0.00002213,,'1' (0x01),'1' (0x01)

0.00002487,,'1' (0x01),'1' (0x01)

0.00002762,,'16' (0x10),'16' (0x10)

0.00003037,,'1' (0x01),'1' (0x01)

0.00003311,,L (0x4C),L (0x4C)

0.00003586,,'1' (0x01),'1' (0x01)

0.00003860,,'0' (0x00),'0' (0x00)

0.00007927,,'165' (0xA5),'165' (0xA5)

0.00008135,,'165' (0xA5),'165' (0xA5)

0.00008343,,'165' (0xA5),'165' (0xA5)

0.00008556,,Z (0x5A),Z (0x5A)

0.00008775,,'21' (0x15),'21' (0x15)

0.00008988,,'0' (0x00),'0' (0x00)

0.00009201,,'0' (0x00),'0' (0x00)

0.00009415,,'20' (0x14),'20' (0x14)

0.00009628,,'6' (0x06),'6' (0x06)

0.00009841,,'0' (0x00),'0' (0x00)

0.00010055,,'1' (0x01),'1' (0x01)

0.00010268,,'0' (0x00),'0' (0x00)

[...]

Data 4 - Raw SoC$PIC protocol

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 :

0.0000000 S->P [0x00,0x08] T: 0x33, ID: 0x14 | 01,01,10,01 (4c01)

0.0000386 P->S [0x0e,0x15]        RESP: 0x14 | 06,00,01,00,61,3f,

8a,27,0e,00,00,00,

44,99,c7,d5 (a300)

Data 5 - Interpreted SoC$PIC protocol

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

We are now able to decode most of the communications :

- with the two SPI ash chips

- between the SoC and PIC32

we must dig into the details to understand the actual logic

Summary 6 - Next step

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 :

S->P T: 0x33, ID: 0x14 | 01,01,10,01

P->S        RESP: 0x14 | 06,00,01,00,61,3f,8a,27,0e,00,00,00,44,99,c7,d5

S->P T: 0x33, ID: 0x14 | 01,01,10,01

P->S        RESP: 0x14 | 06,00,01,00,8a,62,8f,82,0e,00,00,00,4c,63,d9,65

Data 6 - PIN validation frames

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 :

0.00000000 S->P T: 0x33, ID: 0x14 | 01,01,10,01

0.00003861 P->S        RESP: 0x14 | 06,00,01,00,09,4d,01,cb,

0e,00,00,00,89,0f,3a,7a

1.10261073 S->P T: 0x37, ID: 0x15 | 07,01,01,01

1.10266848 P->S         ACK: 0x15

3.10530806 S->P T: 0x37, ID: 0x16 | 07,02,02,01

3.10534667 P->S         ACK: 0x16

3.10545591 S->P T: 0x37, ID: 0x17 | 05,01,01,01

3.10549452 P->S         ACK: 0x17

3.73653834 S->P T: 0x37, ID: 0x18 | 09,01,01,01

3.73657695 P->S         ACK: 0x18

4.02558845 S->P T: 0x37, ID: 0x19 | 07,41,01,01

4.02562706 P->S         ACK: 0x19

4.02575436 S->P T: 0x33, ID: 0x1a | 01,01,10,01

4.02579297 P->S        RESP: 0x1a | 06,00,01,00,08,07,00,00,

05,00,00,00,00,01,00,00

Data 7 - More complete PIN validation frames (good PIN)

0.00000000 S->P T: 0x33, ID: 0x14 | 01,01,10,01

0.00003861 P->S        RESP: 0x14 | 06,00,01,00,77,bd,f8,14,

0e,00,00,00,86,bb,34,9e

0.00392331 S->P T: 0x37, ID: 0x15 | 05,01,01,01

0.00396192 P->S         ACK: 0x15

0.00409148 S->P T: 0x37, ID: 0x16 | 09,04,01,01

0.00413009 P->S         ACK: 0x16

1.00720932 S->P T: 0x37, ID: 0x17 | 0a,01,01,01

1.00724793 P->S         ACK: 0x17

2.01064556 S->P T: 0x37, ID: 0x18 | 0a,01,01,01

2.01068417 P->S         ACK: 0x18

Data 8 - More complete PIN validation frames (bad 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 :

PIN   Hash

3333  094d01cb890f3a7a

1111  d123a2b469452914

0111  3faf7e23c912063c

0011  5177ab50c9030491

0000  9d11fea0fcc89c77

00000  f1a6b81046b0d834

1234  15fb1e2bd24ecb0b

123456  a4250a552009475e

11111111  613f8a274499c7d5

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 :

0.00000000 S->P T: 0x37, ID: 0x15 | 0a,01,01,01 (4d01)

0.00003861 P->S         ACK: 0x15 (9100)

0.22340134 S->P T: 0x33, ID: 0x16 | 01,01,10,01 (4a01)

0.22343995 P->S        RESP: 0x16 | 06,00,01,00,3e,c5,

ab,0a,0e,00,00,00,

03,01,34,df (9c00)

0.22733179 S->P T: 0x37, ID: 0x17 | 05,01,01,01 (5001)

0.22737040 P->S         ACK: 0x17 (8f00)

0.22750210 S->P T: 0x37, ID: 0x18 | 09,04,01,01 (4701)

0.22754071 P->S         ACK: 0x18 (8e00)

1.23121708 S->P T: 0x37, ID: 0x19 | 0a,01,01,01 (4901)

1.23125569 P->S         ACK: 0x19 (8d00)

2.23464766 S->P T: 0x37, ID: 0x1a | 0a,01,01,01 (4801)

2.23468627 P->S         ACK: 0x1a (8c00)

3.23808799 S->P T: 0x37, ID: 0x1b | 0a,01,01,01 (4701)

3.23812660 P->S         ACK: 0x1b (8b00)

4.24152672 S->P T: 0x37, ID: 0x1c | 0a,01,01,01 (4601)

4.24156533 P->S         ACK: 0x1c (8a00)

Data 9 - Bad PIN with delay trace

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).

- the SoC is doing the verication

- we cannot easily do a bruteforce attack because of the unknown hash

- check result is known right after entry, delay is bypassable

Summary 7 - PIN check results

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 :

0.00000000 S->P T: 0x33, ID: 0x14 | 01,01,10,01

0.00003861 P->S        RESP: 0x14 | 06,00,01,00,09,4d,01,cb,

0e,00,00,00,89,0f,3a,7a

0.000218 : READ @ 0x1000 (0x94 bytes)

0.000890 : READ @ 0x1094 (0x128 bytes)

0.005659 : READ @ 0x1000 (0x94 bytes)

0.006848 : SECTOR_ERASE @ 0x1000

0.096850 : WREN

0.096854 : PP @ 0x1000

[... repeated sequential PP ... ]

0.099916 : PP @ 0x11b8 (total : 0x1bc bytes)

0.100391 : READ @ 0x1000 (0x1BC bytes)

1.10260833 S->P T: 0x37, ID: 0x15 | 07,01,01,01

1.10264694 P->S         ACK: 0x15

3.10529433 S->P T: 0x37, ID: 0x16 | 07,02,02,01

3.10533294 P->S         ACK: 0x16

3.10546138 S->P T: 0x37, ID: 0x17 | 05,01,01,01

3.10549999 P->S         ACK: 0x17

3.57679572 S->P T: 0x37, ID: 0x18 | 09,01,01,01

3.57683433 P->S         ACK: 0x18

Data 10 - Good PIN, trace of interchip and ash communications

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.

00000000  00 ff 40 00 26 f9 9b f3  6b 45 f7 11 d4 83 1b 7a

00000010  ce 5a 2e a2 25 24 ff e0  00 69 a6 8b ac d5 e9 b7

00000020  66 3e 59 48 3f 52 89 bc  a3 22 84 ab 51 55 ec 1b

00000030  b5 c5 8e 50 ca dc 89 9d  1e 55 78 4f 8d d4 fd 18

00000040  5f 06 17 1b b7 d7 a2 51  c0 0e 17 4c be 98 e1 28

00000050  d5 45 8a 9d 7f 21 04 40  5e 13 91 b8 69 55 be 0c

00000060  8a 35 7d f8 98 0b e0 91  84 f5 53 d9 fb 4b 9c a7

00000070  3b 23 eb d6 da ca 89 ed  81 52 c5 6f 7e 47 62 51

00000080  72 de 26 b8 92 3e d0 6a  31 ad 58 df 76 8c 9e 5a

00000090  43 10 58 75 80 ff 40 00  cb 0b 83 73 47 dc 0d 0f

000000a0  ff 5b 05 92 6c a3 b0 4c  68 84 77 fc 58 ae 92 10

000000b0  28 cb 4a e8 cb 02 a1 90  59 d5 c0 e4 dd 81 c9 70

000000c0  8e 08 88 66 30 b5 a1 95  ad 9a d4 96 f6 87 a5 64

000000d0  d4 f9 e4 1a ac c2 5a a3  ef f1 b8 56 d6 0f c5 d5

000000e0  60 35 3b d7 a3 36 8f 7f  a5 aa 8e 59 cf 03 22 37

000000f0  98 0e a7 31 01 78 8c d4  c0 b9 8b cf f1 a5 a7 6c

00000100  c9 63 65 5b 25 7b 08 96  5e 89 45 4e f5 c8 a5 cc

00000110  a5 df 39 b6 54 c0 18 c5  00 00 20 00 a5 fe 03 88

00000120  63 b6 0d 20 79 63 ac 5d  ce 3c 55 94 85 eb ab bd

00000130  3d 15 6d 67 f6 b5 1c 71  02 a2 c7 79 00 00 00 00

00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

*

00000190  00 00 00 00 00 00 00 00  00 00 00 00 79 cc 89 57

000001a0  4e 94 89 86 93 ee 16 7c  07 02 a7 57 d9 6d 35 c8

000001b0  57 f3 ae 38 14 ae d8 db  0c 2a ee b6

Data 11 - Hexdump of ash block

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.

- the SoC veries the PIN using the hash it receives from the PIC

- if a good PIN was entered a block containing (probably) crypto material is written on the SoC SPI ash at oset 0x1000

- else nothing is written

- the block at oset 0x1000 probably contains encrypted or obfuscated keys for drive encryption

Summary 8 - Current knowledge

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 :

goodfet.spiflash dump backup_SPI

goodfet.spiflash erasesector 0x1000

goodfet.spiflash flash boot_key_block 0x1000 0x11BC

goodfet.spiflash writestatus 0x1C

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.

Figure 14: Soldering ash socket

Figure 15: Attack setup

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.

Our black box attack failed. We must access the code.

Summary 9 - The end

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

1.    Eon : EN25F80 datasheet. http://www.eonssi.com/upfile/p200892918920.pdf. Accessed : 2015-04-10.

2.    Iodd 2541 : rmware updates. http://crm.iodd.co.kr/projects/iodd2541/files. Accessed : 2015-04-10.

3.    Microchip : PIC32 Flash Programming Specication (DS60001145P). http://ww1.microchip.com/downloads/cn/DeviceDoc/cn532867.pdf. Accessed : 2015-04-10.

4.    pic32prog : Flash programming utility for Microchip PIC32 microcontrollers. https://github.com/sergev/pic32prog. Accessed : 2015-04-10.

5.    PS4 developer wiki : MB86C311B. http://www.psdevwiki.com/ps4/MB86C311B. Accessed : 2015-04-10.

6.    SpritesMods : DiskGenie review - Timing-attack. https://spritesmods.com/?art=diskgenie&page=5. Accessed : 2015-04-10.

7.    Wikipedia : Block cipher modes of operation. https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB. Accessed : 2015-04-10.

8.    Wikipedia : Disk encryption theory. https://en.wikipedia.org/wiki/Disk_encryption_theory. Accessed : 2015-04-10.

9.    Wikipedia : Serial Peripheral Interface Bus. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus. Accessed : 2015-04-10.

1. Electronic codebook preserves patterns, making it the worst mode for encryption [7]. For example, zeroed sectors are readily identiable.

2. From now on, secrets will always refer to cryptographic data, not user data stored on the encrypted drive.

3. For an interesting discussion about Chinese sharing, see http://www.bunniestudios.com/blog/?p=4297

4. pin numbers are those from the datasheets.

5. DS60001168F-page 226

6. A portion of exposed metal on the surface of a board usually used for testing or programming during manufacturing.

7. First time we really have to touch hardware !

Table des Matières

Introduction

Getting started

PCB

Trying to get the code

Blackbox analysis

Sni ALL THE THINGS

Attack Attack !

Conclusion

1

8

2

3

4

5

6

7

3.2

9

10

11

12

13

14

15