In this article, we'll show you how to extract firmware from a secure USB device running on cortex M0.

Who "blacked" the game?

In the field of video game consoles, the manufacture of counterfeit and unlicensed products is very common. Because it's a multi billion dollar business, counterfeiters will naturally flock to it when there's a need. Now, almost all released game consoles can find corresponding devices, so that we can use flash drives, fake game handles and accessories, and various adapters to play "backups" of authorized video games. Some of these devices can give you more advantages than other players, or even cheat in online and offline video games. What's more, through some services, you can directly spend money to buy grades, without spending time to blame. Of course, these are sold without the consent of the game mechanism manufacturer.

Like 20 years ago, modern video game players are proprietary systems whose rules has the final say of the hardware manufacturers themselves, not by millions of customers who use them. Of course, their design also includes a variety of protection measures to ensure that these game consoles can only run signed code, so that users can only play authorized video games obtained through legal channels, and all players have equal rights and can only use official authorized accessories. In some countries, trying to crack their own video game consoles is even illegal.

But at the same time, the scale of protection makes these game consoles an attractive target, as well as a big target for the enthusiasts interested in information security and reverse engineering. And, for them, the harder it is to crack, the more motivated they are. Especially for those who love playing video games since childhood.

Protection scheme of dualshock 4

Readers who follow my twitter account may know that reversing video game consoles and related content, including unofficial game devices, has always been my favorite. Shortly after Playstation 4 was launched, through a well-known vulnerability in the FreeBSD kernel (the kernel on which Playstation 4 is based), I and many other researchers had the opportunity to deeply explore the architecture and internal working principle of Sony's new game console. To do this, I did a variety of research, such as how USB Authentication works in Playstation 4, and how it distinguishes between licensed devices and blocked unauthorized devices. This paper chooses this topic because I have done similar research on other game consoles before. Although Playstation 4's authentication scheme is much simpler than that used in Xbox 360, it is also very effective.

Authorization scheme for USB accessories of Playstation 4

PS4 sends 0x100 random bytes to dualshock 4. In response, the game controller will create the corresponding rsassa-pss SHA-256 signature and return it together with the encryption constants n and E (public key) to be verified. These constants are unique to all dualshock 4 joysticks. At the same time, the game controller will send the signature needed to verify N and E. During verification, the same rsassa-pss SHA-256 algorithm will be used, but the encryption constant is the same for all Playstation 4 game consoles and stored in the kernel.

This means that if you want to authenticate your USB device, attacking the Playstation 4 kernel alone is not enough - you also need the private key stored in the game handle. Even if someone tries to crack the game handle and get the private key, Sony can still blacklist the key through firmware update. If the console does not receive a verification response after eight minutes, it will stop communicating with the joystick until it is unplugged from the USB port and inserted again. This is the working mechanism of the early fake game controller, which simulates the process of unplugging / inserting a USB port every 8 minutes. As anyone who has used it knows, it is particularly annoying.

A rumor about super imitation of dualshock 4

Since the advent of dualshock 4, there has been no sign that this protection mechanism has been successfully broken. Recently, however, as like as two peas, the DualShock 4 is emerging in the market. It is almost the same as the genuine product in appearance or function. Driven by curiosity, I couldn't help ordering some from stores in China.

While I was waiting for my package to arrive, I decided to try to gather more information about fake game consoles. With the help of search engine, I found a game controller named Gator claw.

Unauthorized Gator claw gamepad

There is an interesting discussion on reddit. People say that it can only use 8 minutes like other unauthorized game consoles, but developers have solved this problem through firmware update. The pages in the figure provide links to firmware updates and the corresponding manuals.

Gator claw firmware update manual

Analysis of embedded firmware

The first step in the analysis is to look at the resources section of the firmware updater executable.

Firmware code found in the Gator claw firmware updater resource

Readers familiar with embedded device code are likely to have an understanding of this file format. In fact, this is an Intel hex file format, which is usually used in microcontroller programming. Many compilers (such as GNU compiler) can output compiled code in this format. In addition, we can see that the entropy at the beginning of the firmware code is not too high, and the byte sequence is easy to identify. This means that the firmware is not encrypted or compressed accordingly. In order to examine these codes, we can decode the firmware in Intel hex format and load it into the hex editor (010 editor can directly open files in this format). So, what architecture is it compiled for? Obviously, this is the arm Cortex-M architecture.

Gator claw firmware (left) and arm Cortex-M vector table (right)

According to the relevant specifications, the first doubleword is the initial stack pointer, followed by the exception vector table. The first doubleword in this table is the reset vector used as the firmware entry point. The high address of other exception handlers provides the base address of the firmware.

In addition to the firmware, the resource section of the firmware updater contains a configuration file that passes descriptions of the different microcontrollers. As a result, developers of firmware updates are likely to use the open source code provided by the microcontroller manufacturer, which explains why the configuration file comes with the relevant source code.

Profile with different microcontroller description information

After searching for the microcontroller identifier from the configuration file, we found the site of manufacturer Nuvoton. We found that technical documents and SDKs contain relevant product information. Importantly, they can be downloaded for free without any license agreement at all.

Nuvoton microcontroller manufacturer's website

So far, we've got the firmware, the architecture and the microcontroller manufacturer, and we've got information about the base address, the initial stack pointer, and the entry point. Next, we will use IDA pro to load the firmware and start the analysis tour.

The arm processor has two different instruction sets: arm (32-bit instruction) and thumb (16 bit instruction extended with thumb-2 32-bit instruction). We know that Cortex-M0 only supports thumb mode, so when using IDA pro to load firmware, we need to switch the radio button in "processoroptions edit arm architecture options set arm instructions" to "no".

Later, we will see that the firmware will load at base 0 and automatically analyze almost all the functions that have been identified. Now the problem is how to further develop the reverse analysis of firmware code.

Firmware function example

When analyzing the firmware, you will find that the base address is 0x40000000 from the beginning to the end when the firmware reads and writes to the memory. This is the base address of the memory mapped to the input / output (mmio) register. These mmio registers allow you to access and control all peripheral components of the microcontroller. Firmware does everything by accessing them.

Memory mapping of peripheral controllers

By looking up the technical documents related to address 0x40000000, we found that the microcontroller belongs to m451 series. Now that you know the family of microcontrollers, you can download the corresponding SDK and code samples. In the SDK, we found a header file that defines all mmio addresses, bit fields, and structures. We can also use all libraries to compile sample code and compare them with functions in the IDB, or look up the name of the mmio address in the source code and compare it with disassembly. This makes the reverse engineering process much easier. In fact, it's mainly because we know the architecture and model of the microcontroller, so we can find the definition of all mmio registers. If we don't have this information, analysis will be much more difficult. At the same time, this is why many vendors only distribute SDKs after signing NDA.

Find library functions in firmware

The shadow of giants

Waiting for the fake joystick to arrive, I took the time to analyze gatorclaw's firmware. We have little interest in the details of its internal operation: authentication data is sent to another microcontroller that can be accessed through I2C, after which the response is sent back to the console. The developers of the unlicensed game controller also realize that their firmware may be reversed, and if so, more fake game controllers will come out, which will affect their sales. To stop this, they used another microcontroller to protect them. This is a very common practice. Hackers work hard on their products because they don't want to be hacked by other hackers. In this firmware, what really catches my attention is that there are strings that seem to be unused. They are likely to be part of the USB device descriptor, but this particular descriptor is not yet used. Is this string intentionally reserved? Is this some kind of signature? Most likely, because this string is the name of a hardware manufacturer known for its logic analyzer. However, the company has also established a game department, aiming to become an original equipment manufacturer (OEM), and even has many patents related to the production of game accessories. In addition, they also have some subsidiaries with various game accessories on their websites, which are all sold under the same brand. The products on sale include more than 20 kinds of adapters, which can make the game handle of one kind of game machine be used on another kind of game machine. For example, there is a product that allows us to connect the game controller of Xbox 360 to Playstation 4, while another product can connect the game controller of Playstation 3 to Xbox one, and so on. What's more, some adapters can connect PC mouse and keyboard to PS4, Xbox one, Nintendo game console, various handles and PCB. All products offer firmware updates similar to Gator claw, but there is a significant difference - all firmware is encrypted.

Examples of manual and encrypted firmware from resources from one of the products

These printed circuit boards are used to help me create my own streetcar controller. With them, we can view the relevant PCB design without purchasing relevant equipment or disassembling. Their PCB design is likely to be very close to the Gator claw handle. In the picture below, we can see two microcontrollers; one is Nuvoton m451, and the other is an additional microcontroller for storing confidential data. All the wires are converged to the microcontroller under the black epoxy resin, so it should be the main microcontroller, and the microcontroller with four yellow pins seems to meet the requirements of working on I2C.

PCB design example

New discovery

As like as two peas of the original DualShock 4, I finally received the parcel from Shenzhen. This is a wireless game handle made of high-quality materials, providing working touch pad, speaker and headphone interface.

Fake the appearance of dualshock 4

When the handle is activated, it will enter DFU mode; in this mode, the game handle is connected to the PC, which is recognized as another device with different identifiers and characteristics. Next, we'll look inside

Fake PCB of dualshock 4

I welded several wires to what looked like JTAG points and connected them to a JTAG programmer. We find that the programmer can recognize the microcontroller correctly, but it has a safety lock.

The programming tool recognizes the microcontroller, but it enables a security lock

Intrusion of microcontroller firmware via USB

Well, it's time to get back to the subject of this article. USB (Universal Serial Bus) is the industrial standard of peripheral devices. Its design is very flexible, at the same time, it has been widely used. The USB protocol defines two entities - one host connecting to another device. USB devices are divided into hub, human-computer interface, printer, image, mass storage device, etc.

USB device connection scheme

The data and control exchange between the equipment and the host is completed by a set of one-way or two-way pipelines. For the pipeline, we can think of it as the data transmission channel between the host software and the specific endpoint on the USB device. A device can have many different endpoints to exchange different types of data.

Data transfer type

There are four different types of data transmission:

• Control transfer (for configuring devices)
• Batch data transmission (the amount of data generated or consumed is relatively large and the burst is strong)
• Interrupt data transmission (for timely and reliable data transfer)
• Synchronous data transmission (occupy the pre negotiated USB bandwidth and have the pre negotiated transmission delay)

All USB devices must support a special pipe specified through endpoint 0 to which the control pipe of the USB device will connect.

These types of data transmission are implemented through the packets provided by the following scheme.

Packets used in USB protocol

In fact, the USB protocol is a state mechanism, and we will not cover all of these packets in this article. The following is an example of a packet used in a control transfer.

Controlled transmission

USB devices may have vulnerabilities in batch transmission, interrupt transmission and synchronous transmission, but these types of data transmission are optional, and their existence and usage will vary depending on the target. But all USB devices support controlled transfer. Their format is universal, which makes this type of data transmission the most attractive vulnerability analysis target.

The format of the setup packet used to perform the control transfer is shown below.

Format of setup packets

The length of the setup packet is 8 bytes, and different types of data can be obtained according to the request type. Some of these requests are common to all devices (for example, get desc riptor); others depend on the device category and the manufacturer's license. The length of data to be sent or received is recorded by the 16 bit word provided in the setup packet.

Examples of standard and special requests

All in all: the control transfer uses a very simple protocol, which must be supported by all USB devices. It can provide many additional requests, and at the same time, we can control the size of the data. All of these make control transfer the perfect target of fuzzy test and sending false signal.

Utilization method

To crack this fake game handle, we don't need to fuzzy test it, because I found some vulnerabilities when I examined the code of Gator claw.

Code related to vulnerability in HID class request handler

The hid_classrequest() function is used to simulate the operation of the original dualshock 4 handle and implement the minimum requests required to work with PS4. The usbd ﹣ getsetuppacket() function is used to get setup packets. Depending on the type of report, it either uses the usbd ﹣ preparecntrlin() function to send data or uses the usbd ﹣ preparecntrout() function to receive data. This function does not check the length of the requested data, so we can read the internal flash memory of the part where the firmware is located, or read and write the beginning part of the SRAM memory.

Buffer overflow during control transfer

The size of data packets is defined in the USB device descriptor (also received with the control transmission), but it is easy to be ignored that this size defines the length of a single packet, and because there may be many packets, their length depends on the settings in the setup packet.

It is worth noting that the sample code provided on the Nuvoton site also does not check the length, which could lead to similar security vulnerabilities in all products that use this code as a reference.

Utilization of buffer overflow vulnerability in SRAM memory

Static random access memory (SRAM) is a kind of memory used for stack. SRAM is also generally executable memory (which is configurable). It is common practice to copy frequently called code fragments (for example, real-time operating system) to SRAM to improve system performance. We can't guarantee that buffer overflows will reach the top of the stack, but the probability of this is still high.

Surprisingly, the main obstacle to using USB firmware is the operating system. The following is what I observed when I used Windows system, but I think most of them are also applicable to Linux systems without corresponding patches.

First, the operating system does not allow reading more than 4KB during the control transfer. Second, in my experience, the operating system does not allow more than one data packet to be written during control transfers. Third, USB devices may have hidden requests, and all attempts to use them will be blocked by the operating system.

This is easily demonstrated by a human-computer interface device (HID), including a game controller. Hid also provides other descriptors (HID descriptors, report descriptors, physical descriptors). Report descriptors are very different from other descriptors. They are made up of different items that describe supported reports. If a report is missing from the report descriptor, the operating system will refuse to complete it, even if the report is processed by the device. This makes it more difficult to find and exploit vulnerabilities in USB device firmware. In fact, it is likely that these subtle differences lead to no one can find relevant vulnerabilities in the past.

To solve this problem without having to read and recompile the source code of Linux kernel, I can only turn to the low-level tools at hand: Arduino Mega board and USB host shield (less than $30 in total).

Connection scheme

After connecting the device with the above scheme, I use the Arduino board to control the transmission, so that I won't be interfered by the operating system.

Arduino Mega + USB HostShield

The fake game handle has the same vulnerability as Gator claw, so the first thing to do is dump the corresponding firmware.

Dump the corresponding firmware

The easiest way to find the base address of a firmware dump is to find a structure with a pointer to known data. After that, we can provide the increment of the calculated address to load the dumped firmware into IDA pro.

Structure of pointer to known data

Through the firmware dump, we can find the address of the printf() function, which is used to output the UART information required for factory quality assurance. Not only that, I was able to find the hexdump() function in the dump, which means that even shellcode doesn't have to be written.

Find functions that can help exploit vulnerabilities

After locating UART points, welding wires and connecting them to ttl2usb adapter on the printed circuit board of the game handle, the output content can be seen at the serial terminal.

Standard UART output during joystick boot

The standard library of Nuvoton microcontroller comes with a very convenient hard fault exception handler, which can output register dump contents. This is very helpful for exploit, and it is also very useful for debugging exploit code.

UART output after hard fault exception caused by stack overlay

The last vulnerability to dump firmware can be seen in the screenshot below.

Exploit code and shellcode for dumping firmware on UART

But this way of dumping firmware is not perfect, because the Nuvoton m451 series microcontroller may have two different types of firmware - the main firmware (aprom) and the mini firmware (ldrom) for device firmware update.

Memory mapping of flash memory and system memory in different modes

Aprom and ldrom are mapped to the same memory address, so we can only dump one of them. In order to get the dump of ldrom firmware, we need to disable the security lock and use programming tools to read the flash memory.

Shellcode with security lock disabled

Encryption failed

After analyzing the firmware responsible for the update (ldrom), it is found that it is mainly derived from Nuvoton's standard code, at the same time, it also adds the code to decrypt the firmware update.

A cryptographic algorithm for firmware update and decryption

The encryption algorithm used to decrypt firmware updates is a custom block cipher. It is executed in cipher block linking mode, but the block size is only 32 bits. The algorithm needs to receive a key (the product's text (ASCII) identifier) and an array of instructions that define what transformations should be performed on the current block. At the end of the key and array, the algorithm sets their current location to the initial location. The conversion list involves six operations, exclusive or, subtraction, and subtraction (reverse). The remaining three operations are the same, except that bytes are exchanged. Because the firmware contains a large number of zero filled areas, it is easy to calculate the secret part of the algorithm.

Encryption key for firmware update

The algorithm extracted from the firmware of the fake game handle is applied to all the firmware of the accessories found on the sites of the major OEM manufacturers. We find that all the accessories use this encryption algorithm, and the weakness of the algorithm allows us to calculate the encryption keys of all devices, so that we can decrypt their firmware updates. In other words, the algorithm used inside the fake product causes the security lines of all products developed by the manufacturer to collapse.

Summary

In this paper, we introduce the specific methods of analyzing embedded firmware in detail. Through these methods, we can find vulnerabilities and use them to obtain firmware dump and execute code on USB device.

Although the discussion of glitching attack is beyond the scope of this paper, it should be noted that this attack is also very effective for USB devices. For those who want to learn more about this attack method, it is recommended to watch the video here. For those who want to know how pirates get algorithms and keys from dualshock 4 to make their own devices, this article is recommended.

As for the secondary microcontrollers used for security, I found that not all devices will use them, and only devices that want to improve the concealment will add them. However, the microcontroller itself cannot keep any secrets, only for SHA1 and SHA256. The research will also help gamers create their own open-source projects on game consoles.

As for the buyers of fake game consoles, their situation is a little worrisome, because manufacturers can disable illegal keys, so their game consoles can't be used normally, and they can't get help with firmware updates.

Original address: https://securelist.com/hacking-microcontroller-firmware-through-a-usb/89919/