Programm 30C3

All “managed FLASH” devices, such as SD, microSD, and SSD, contain an embedded controller to assist with the complex tasks necessary to create an abstraction of reliable, contiguous storage out of FLASH silicon that is fundamentally unreliable and unpredictably fragmented. This controller is an attack surface of interest. First, the ability to modify the block allocation and erasure algorithms introduces the opportunity to perform various MITM attacks in a virtually undetectable fashion. Second, the controller itself is typically powerful, with performance around 50MIPS, yet with a cost of mere pennies, making it an interesting and possibly useful development target for other non-storage related purposes. Finally, understanding the inner workings of the controller enables opportunities for data recovery in cards that are thought to have been erased, or have been partially damaged.

This talk demonstrates a method for reverse engineering and loading code into the microcontroller within a SD memory card.

TECHNICAL APPROACH

Publicly available documentation on SD card controllers is scarce. However, based upon tear-down and decap analysis as well as a survey of the publicly available product briefs, most controllers are believed to be either an enhanced 8051, or an ARM derivative.

A further challenge to overcome is the fact that SD card manufacturers typically reserve the right to change the controller IC within a card without updating the external markings to reflect the change. This policy favors the SD card manufacturers, as it allows them to swap out existing controllers for lower-cost devices as new controllers are introduced. However, it is problematic for users as it means that two otherwise identical looking cards can have different performance and/or bugs with which to contend.

To kick off the effort, a survey of available cards was made at an SD card gray market in Shenzhen, China. Each card was dissected and visually inspected for cues, such as the layout of the traces going to the controller glob-top, that would indicate the type of controller within. About a dozen different controller types were identified, of which one was picked for further investigation due to its use of SLC FLASH memory. SLC is a good starting point for reverse engineering because no storage-level scrambling is required to prevent the read and write-disturb issues typical of MLC and TLC FLASH.

A simple binary dump of the FLASH memory within the card revealed structure within the first erase block consistent with what we might expect for code storage. Since FLASH memory is inherently unreliable, four CRC + ECC protected copies of code are located within the first sector. This crude duplication scheme allows the card to boot even if bit errors creep into the code storage sector. We also noted the existence of the string “BUILDWIN” within the code storage sector, which indicates that the controller is likely from a series made by a company called Appotech. Product briefs from the Appotech/Buildwin websites indicated that the architecture of the code is likely an 8051-derivative, and the model of the controller is probably an AX211.

At this point, our effort to reverse engineer the controller split into two paths. One path was static analysis, where extracted binaries and manufacturing-related tools were analyzed with IDA to determine key entry points, storage locations, and most importantly a method for injecting code into the card via the SD interface. The other path was dynamic analysis, where the signals going to the SD card bus and to the NAND FLASH were instrumented with logging and stimulus facilities, and the controller's operation could be observed with exquisite resolution, enabling a broad class of fuzzing and other brute-force analysis attacks, as well as the rapid confirmation or rejection of hypotheses generated by static analysis. Dynamic analysis was key in determining features such as the location of the GPIO control registers and the function and format of otherwise undocumented extended instruction opcodes.

The static analysis path was assisted by the availability of official firmware burning routines, scavenged from Chinese language file-sharing websites. These are tools normally used during the production of SD cards, but made available on the gray market to enable (and correct) card capacity expansion fraud. Typically, these tools are used to flash an incorrect version of the firmware onto the SD cards, which would identify the card as having a much higher capacity than the physically available storage. This would allow unscrupulous dealers to sell, for example, aging 128MiB silicon as devices identifying themselves with 2GiB capacity. These bootleg tools would come with a collection of firmware blobs for loading onto the card, as well as a routine that communicates to a proprietary USB-based burning device. We did not have access to the burner, but static analysis of the communication protocol via code reverse engineering revealed that firmware loading is initiated through the application of a specific “secret knock” sequence during card boot.

The dynamic analysis path was implemented using an embedded platform of our making, known publicly as Novena. It is a quad-core ARM CPU running Linux mated to a Spartan 6 FPGA with a high speed expansion port. The FPGA also has a 256 MiB DDR3 buffer slaved off of it. This buffer + FPGA was used to implement a combination logic analyzer + ROM emulator used to wrap the controller on the SD card. The ROM emulator presents a virtual, dual-ported NAND FLASH device to the SD card controller. The dual-port design allows us to modify and read the contents of the NAND FLASH on the fly, thereby allowing us to stimulate the controller IC with various fault conditions or code loops and measure its effect on the FLASH device. This tight coupling enabled us to rapidly discover, for example, which SFRs (Special Function Registers) are responsible for reading or writing to the Flash controller hardware. Furthermore, each port of the SD card controller is connected to a virtual logic analyzer within the FPGA that can store up to a 16MiB trace of transactions going to and from the controller from both the SD and FLASH buses. This very deep buffer length allowed us to observe behavior of the device from power-on to full operation, as well as observe stimulus-response loops to compound SD bus commands.

SD INTERFACE OVERVIEW

Before diving into the details of our approach, we review a few important aspects of the SD protocol. When an SD card first boots, it is running in SD/MMC mode. This is a 9-wire protocol, using the following pinout (note: pin 9 is located below and to the side of pin 1):

12345678
9|||||||\- DAT1
|||||||\-- DAT0
||||||\--- GND
|||||\---- Clock
||||\----- VDD +3.3V
|||\------ GND
||\------- Command
|\-------- DAT3
\--------- DAT2

SD commands consist of a start bit of 0, a sync bit of 1, a 6-bit command number (referred to as CMDn, where n is between 0 and 63,) four 8-bit arguments, a CRC7 checksum, and a stop-bit of 1. This yields a total of 48-bits (or 6 bytes) per command.

While the card is processing the request, it will keep the Command line high, and will begin its communication with a start bit by bringing the Command line low, indicating "0". This will be followed by 38 bits of data, 7 bits of crc7, and a stop bit of "1", for a total of 48 bits.

Bit values are sampled when the clock line is high, and may change when the clock line is low. Bytes are sent from high to low. For example, hex value 0x80 would be written out as 0b10000000. CMD0 must be sent before any other commands are processed. To send such a command, transmit the following six byes.

{0x40 0x00 0x00 0x00 0x00 0x95}
| | | | | \----- (CRC7 of ({0x40, 0x00, 0x00, 0x00}))< for uploading code into the controller was found, and through this mechanism we explored the register map and extended opcodes of the microcontroller. Significantly, in this particular device all of the SD protocol-layer commands are implemented in software. This allowed us to redefine the SD protocol set and implement, as a demonstration, a REPL-mode debugger for the SD card.

Info

Tag: 29.12.2013
Anfang: 14:00 Uhr
Dauer: 01:00
Room: Saal 1
Track: Hardware & Making
Sprache: en

Links:

• iCalendar

Feedback

Uns interessiert deine Meinung! Wie fandest du diese Veranstaltung?