Who Hacks Video Game Consoles?
The manufacturing of counterfeit and unauthorized products is prevalent in the world of video game consoles. This is a multi-billion dollar industry where demand creates supply. You can now find devices for nearly every existing console that allow you to play licensed video game “backups” from flash drives, counterfeit game controllers, and accessories, various adapters, some of which also work with other players, as well as cheats in online and offline video games. There are even services that let you directly purchase achievements in video games without spending hours to complete them. Of course, all of these are sold without the consent of the video game console manufacturers.
Just like 20 years ago, modern video game consoles are proprietary systems whose rules are set by the hardware manufacturers, rather than by the millions of gamers using these devices. They incorporate various protections in their design to ensure that these consoles only run authorized code, so they only play licensed and legally obtained video games, with equal rights for all players to only use officially authorized accessories. In some countries, attempting to hack your own video game console is even illegal.
However, at the same time, such stringent protection schemes make these consoles an attractive target for attacks, and a significant “crack” for hobbyists interested in information security and reverse engineering. Because for them, the harder the puzzle, the more challenging it is to solve, and the more interesting it becomes. Especially for those players who have been obsessed with video games since childhood.
DualShock 4’s Protection Scheme
Readers who follow my Twitter account may know that I am a long-time fan of reverse engineering video game consoles and their related content, including unofficial gaming devices. In the early days of the PlayStation 4, a well-known vulnerability in the FreeBSD kernel (which the PlayStation 4 is based on) allowed me and many other researchers to understand the architecture and inner workings of Sony’s new gaming console. I conducted a lot of different research, some of which included understanding how USB authentication works in the PlayStation 4, and how it distinguishes between licensed devices and blocks unauthorized ones. This research was interesting because I had previously done similar studies on other consoles. The authentication scheme of the PlayStation 4 is much simpler than that used in the Xbox 360, yet equally effective.
Figure:Authorization scheme for PlayStation 4 USB accessories
The PS4 sends 0x100 random bytes to the DualShock 4, as a response, the game controller creates an RSASSA-PSS SHA-256 signature and sends it back along with the required cryptographic constants N and E (the public key). These constants are unique for every DualShock 4 game controller manufactured. The game controller also sends the signature required to verify N and E. It uses the same RSASSA-PSS SHA-256 algorithm, but the cryptographic constants are the same for all PlayStation 4 consoles and are stored in the kernel.
This means that if you want to authenticate your own USB device, attacking the PlayStation 4 kernel is not enough; you also need to have the private key stored in the game controller. Even if someone manages to hack the game controller and obtain the private key, Sony can still blacklist the key through a firmware update. If the game console does not receive a verification response within eight minutes, it will stop communicating with the game controller, and you will need to remove the controller from the USB port and plug it back in to make it work. This is why early counterfeit game controllers needed to simulate the USB port unplugging/plugging process every 8 minutes to keep functioning, which was very annoying for those who bought them.
Rumors about Super Counterfeit DualShock 4
For a while, I hadn’t heard of any events related to cracking this authentication scheme until I heard rumors about new counterfeit game controllers being sold on the market that looked just like the originals. I was really curious to investigate them, so I ordered some from a Chinese store.
While waiting for my package to arrive, I decided to try to gather more information about the counterfeit game controllers. After quite a bit of searching, I found a game controller called Gator Claw.
Unauthorized Gator Claw game controller
On Reddit, there was an interesting discussion where people said it worked like other unauthorized game controllers—only 8 minutes, but developers have managed to fix this with firmware updates. Stores selling them include links and manuals for the firmware updates.
GatorClaw firmware update manual
Basics of Embedded Firmware Analysis
The first thing I did was look at the resource section of the firmware updater executable.
Firmware found in the Gator Claw firmware updater resources
Readers familiar with writing code for embedded devices will likely recognize this file format. It is the Intel HEX file format, commonly used for encoding microcontrollers, and many compilers (like the GNU Compiler) can output compiled code in this format. Additionally, we can see that the initial information entropy of the firmware is not very high, and the byte sequences are easily recognizable. This means the firmware is neither encrypted nor compressed. After decoding this firmware from the Intel HEX format and loading it with a hex editor (the 010 editor can open files in this format directly), we can see what architecture it was compiled for. Given the widespread adoption of the ARM Cortex-M, I recognized it immediately.
GatorClaw firmware (left) and ARM Cortex-M vector table (right)
According to the specification, the first double word is the initial stack pointer, followed by the exception vector table. The first double word in this table is the reset vector (Reset Vector), which serves as the firmware entry point. The high addresses of other exception handlers can give insights into the firmware’s base address.
Besides the firmware, the resource section of the firmware updater also contains a configuration file that describes different microcontrollers. The developers of the firmware updater likely used publicly available source code from the microcontroller manufacturer, which could explain why this configuration file is accompanied by source code.
Configuration file containing descriptions of different microcontrollers
After searching the configuration file for microcontroller identifiers, we found the manufacturer’s website—Nuvoton. Technical documents and product information in the SDK are available for free download without any licensing agreements.
Nuvoton microcontroller manufacturer’s website
At this point, we have the firmware, we know its architecture and microcontroller manufacturer, and we have information about the base address, initial stack pointer, and entry point. Therefore, we have a lot of information, more than what is needed to load the firmware in IDA Pro and start analyzing it.
The ARM processor has two different instruction sets: ARM (32-bit instructions) and Thumb (16-bit instructions using the Thumb-2 32-bit instruction extension). The Cortex-M0 only supports Thumb mode, so when we load the firmware in IDA Pro, we will switch the radio button in the “Processor Options” – “Edit ARM Architecture Options” – “Set ARM Instructions” to “NO.”
After that, we can see that the firmware has been loaded at the base address 0, and automatic analysis can recognize almost every function. The question now is how to advance the reverse engineering of the firmware?
Example of one of the firmware’s multiple functionalities
If we analyze the firmware, we will see that it performs read and write operations throughout memory at the base address 0x40000000. This is the base address for memory-mapped input/output (MMIO) registers. Everything the firmware does is accomplished by accessing them.
Memory mapping of peripheral controllers
By searching the technical documentation for the address 0x40000000, we found that this microcontroller belongs to the M451 series. Now that we understand the microcontroller series, we can download the SDK and code examples for that platform. In the SDK, we find a header file that contains definitions for all MMIO addresses, bit fields, and structures. We can also compile code examples using all libraries and compare them with functions in IDB, or we can look for the names of MMIO addresses in the source code and compare them with our disassembly. This makes the reverse engineering process simple because we know the architecture and model of the microcontroller, and we have definitions for all MMIO registers. If we did not have this information, the analysis would be much more complicated.
Finding library functions in the firmware
In the Shadow of Giants
While waiting for my counterfeit game controller to arrive, I researched the firmware of Gator Claw, which had nothing particularly interesting inside—the authentication data was sent to another microcontroller accessible via I2C, and the response was sent back to the console. The developers of this unauthorized game controller knew that this firmware might be reverse-engineered, and the existence of more counterfeit game controllers might harm their business. To prevent this, the only purpose of using another microcontroller was for security. This is common practice. Hackers put a lot of effort into their products and do not want to be hacked themselves. What really caught my attention in this firmware was the presence of some seemingly unused strings. It is likely part of the USB device descriptor, but that specific descriptor was not used. Was this string left intentionally? Is it some sort of signature? Most likely, because this string is the name of a major hardware manufacturer known for logic analyzers. But it turns out they also have a gaming division aimed at being an original equipment manufacturer (OEM), and even have many patents related to the production of gaming accessories. In addition, they have subsidiaries with a wide variety of gaming accessories on their website. Among the products for sale are over twenty adapters that allow a game controller from one console to work with another. For example, there is a product that allows you to connect an Xbox 360 game controller to a PlayStation 4, another product that allows you to connect a PlayStation 3 game controller to an Xbox One, and so on, including universal “all-in-one” adapters. The product list also includes adapters that allow you to connect a PC mouse and keyboard to PS4, Xbox One, and Nintendo Switch video game consoles, various game controllers, and printed circuit boards to create your own arcade controllers for the game consoles. All products come with firmware updaters similar to the one provided for Gator Claw, but with one significant difference—all the firmware is encrypted.
Manual and encrypted firmware example of one of the products
The printed circuit board for creating your own arcade controller allows you to view the PCB design and disassemble it without having to buy the device, and their designs are likely very close to that of Gator Claw. We can see two microcontrollers: one should be Nuvoton M451, and the other is an additional microcontroller for storing secrets. All traces enter the microcontroller under black epoxy resin, so the main microcontroller should be the one with four yellow pins that seems to have the functionality needed to work via I2C.
Example of PCB design for the product
Revelations
At this point, I finally received the package from Shenzhen, and this is what I found inside. I think you would agree that the counterfeit game controller looks exactly like the original DualShock 4 and feels just like the real controller. It is a wireless game controller made of high-quality materials with a working touchpad, speaker, and headphone jack.
Counterfeit DualShock 4 (from the outside)
I pressed one of the combinations in the update instructions and turned on the power. The game controller booted into DFU mode! When connecting the game controller to a PC in this mode, it was recognized as another device with different identifiers and features. I already knew what I would see inside…
Counterfeit DualShock 4 (main PCB view)
I soldered a few wires to what looked like the JTAG points and connected them to a JTAG programmer, but the programming tool could recognize the microcontroller but had a security lock enabled.
Programming tool recognizes the microcontroller but has security lock enabled
Attacking Microcontroller Firmware via USB
After this quite lengthy introduction, it is now time to return to the subject of this article.USB (Universal Serial Bus) is the industry standard for peripherals. Its design is very flexible and can be widely applied.USB protocols define two entities, a host and other devices connected to it.USB devices are categorized into hubs, human interface devices, printers, imaging devices, mass storage devices, and more.
Connection scheme for USB devices
The data and control exchange between devices and hosts occurs through a set of unidirectional or bidirectional pipes. Through the pipes, we consider the data transfer between the host software and specific endpoints on the USB device. A device can have many different endpoints to exchange different types of data.
Data transfer types
There are four different types of data transfers:
1. Control transfer (for configuring devices)
2. Bulk data transfer (generated or consumed in relatively large and burst quantities)
3. Interrupt data transfer (for timely but reliable data transmission)
4. Isochronous data transfer (occupying a negotiated amount of USB bandwidth with a pre-negotiated transmission delay)
All USB devices must support a special designated pipe at endpoint zero, where the control pipe of the USB device will connect. These types of data transfers are achieved using packets provided according to the following schemes.
Packets used in USB protocols
In fact, the USB protocol is a state machine, and we will not check all these packets in this article. You can see below an example of a packet used in control transfer.
Control transfer
USB devices may contain vulnerabilities when implementing bulk transfer, interrupt transfer, and isochronous transfer, but these types of data transfers are optional, and their presence and usage will vary by target. However, all USB devices support control transfer. Their formats are common, which makes this type of data transfer the most attractive for vulnerability analysis.
The following scheme shows the format of the SETUP packet used to perform control transfers.
Format of SETUP packets
The SETUP packet occupies 8 bytes and can be used to obtain different types of data based on the request type. Some requests are universal for all devices (e.g., GET DESCRIPTOR); others depend on the device class and manufacturer licensing. The length of the data to be sent or received is provided in the SETUP packet as a 16-bit word.
Examples of standard and class-specific requests
In summary: “Control transfer” uses a very simple protocol supported by all USB devices, which can have many additional requests, allowing us to control the size of the data. All of this makes Control Transfers the perfect target for fuzzing and exploitation.
Development
To hack my counterfeit game controller, I did not have to fuzz it because I found vulnerabilities while looking at the Gator Claw code.
Weak code in the HID class request handler
The function HID_ClassRequest() is used to simulate the original DualShock 4 game controller’s operation and implements the minimum required requests to make it work with the PlayStation 4. USBD_GetSetupPacket() retrieves the SETUP packet and, depending on the report type, it will send data using the USBD_PrepareCntrlIn() function or receive it using the USBD_PrepareCntrlOut() function. This function does not check the length of the requested data, which should allow us to read part of the internal flash where the firmware resides, and it may also allow us to read and write the beginning of the SRAM memory.
Buffer overflow during control transfer
The size of the DATA packet is defined in the USB device descriptor (also received via control transfer), but it seems that it was not noticed that this size defines the length of a single data packet, and many packets may depend on the length set in the SETUP packet.
It is worth noting that the code examples provided on the Nuvoton website also lack length checks, which may lead to similar errors propagating in all products using this code as a reference.
Exploiting buffer overflow in SRAM memory
SRAM (Static Random Access Memory) is a type of memory that includes memory occupied by the stack. SRAM is also typically executable memory (this is configurable). This is usually done to improve performance by copying frequently called code snippets (like real-time operating systems) into SRAM. It cannot be guaranteed that the top of the stack can be accessed through a buffer overflow, but the possibility remains quite high.
Surprisingly, the main obstacle to exploiting the USB firmware is the operating system. I observed the following while using Windows, but I believe much of it also applies to Linux without special patches.
First, the operating system does not allow you to read more than 4 kb of data during control transfer. Second, in my experience, the operating system does not allow you to write multiple DATA packets during control transfer. Third, the USB device may have hidden requests, and the OS will block all attempts to use them.
This is easily demonstrated with human interface devices (HID), including game controllers. HID comes with additional descriptors (HID descriptor, report descriptor, physical descriptor). The report descriptor is entirely different from the other descriptors, consisting of different items that describe the reports supported. If a report is missing from the report descriptor, the operating system will refuse to complete the report, even if it has been processed in the device. This essentially diminishes the discovery and exploitation of vulnerabilities in the firmware of USB devices; these nuances are likely to hinder vulnerability discovery.
To solve this issue without having to read and recompile the Linux kernel’s source code, I simply used the low-end instruments I had at hand: Arduino Mega board and USB Host Shield (totaling <$ 30).
Connection scheme
After connecting the device using the above scheme, I executed control transfers using the Arduino board without any interference from the operating system.
Arduino Mega and USB Host Shield
The counterfeit game controller has the same vulnerabilities as the Gator Claw, and the first thing I did was dump part of the firmware.
Partial firmware dump
The easiest way to find the base address of the firmware dump is to look for a structure containing pointers to known data. After that, we can calculate the offset of the address and load the partial firmware dump into IDA Pro.
Structure containing pointers to known data
The firmware dump allows us to find the address of the printf() function, which outputs the UART information required for factory quality assurance. More importantly, I was able to find the hexdump() function in the dump, which means I didn’t even need to write shellcode.
Finding useful functions for development
After locating the UART points on the printed circuit board of the game controller, soldering wires, and connecting them to a TTL to USB adapter, we can see the output in the serial terminal during the startup of the game controller.
Standard UART output during game controller startup
The standard library for the Nuvoton microcontroller includes a very convenient hard fault exception handler that outputs a register dump. This greatly facilitates development and allows debugging of vulnerabilities.
UART output after stack overflow leading to hard fault exception
The final vulnerability of the dumped firmware can be seen in the screenshot below.
Exploiting shellcode and shellcode through UART to dump firmware
However, this method of dumping firmware is not perfect, as the microcontrollers of the Nuvoton M451 series may have two types of firmware: the main firmware (APROM) and mini firmware used for device firmware updates (LDROM).
Memory mapping of flash and system memory in different modes
The APROM and LDROM map to the same memory address, so only one of them can be dumped. To obtain the LDROM firmware dump, we need to disable the security lock and use the programming tool to read the flash memory.
Shellcode to disable security lock
Decryption Failure
Analysis of the firmware responsible for updates (LDROM) shows that it is primarily standard code from Nuvoton, but with added code to decrypt firmware updates.
Encryption algorithm scheme for decrypting firmware updates
The encryption algorithm used for decrypting firmware updates is a custom block cipher. It operates in cipher block chaining mode, but the block size is only 32 bits. The algorithm takes the product’s text (ascii) identifier and an array of instructions as the key, defining the transformations to perform on the current block. When the end of the key and array is reached, their current position is reset to the initial position. The transformation list includes six operations: xor (exclusive or), subtraction, subtraction (reverse), and the same operations but with swapped bytes. Because the firmware contains large areas filled with zero padding, the secret part of this algorithm can be easily calculated.
Displaying the firmware update encryption key
Applying the algorithm extracted from the firmware of the counterfeit game controller to the firmware produced by the main OEM manufacturer can reveal that all of these firmwares are encrypted with this encryption algorithm. The vulnerability of this algorithm allows us to compute the encryption key applicable to all devices and decrypt their firmware update programs. In other words, the algorithm used in counterfeit products compromises the security of all products developed by that manufacturer.
Conclusion
This blog content, while extensive, aims to help the audience understand the principles involved. I have analyzed embedded firmware, discovered vulnerabilities, and exploited them to obtain firmware dumps and execute code on USB devices.
The topic of fault attacks is not covered in this article, but such attacks are also very effective against USB devices. For those who want to learn more about related information, I recommend watching this video. For those curious about how piracy managed to extract algorithms and keys from the DualShock 4 to create their own devices, I recommend reading this article.
As for the mystery of the auxiliary microcontroller used for confidentiality, I found that it is not applied in all devices, merely added to increase complexity. The microcontroller does not retain any secrets, only used for SHA1 and SHA256. This research also assists enthusiasts in creating their own open-source projects for gaming consoles.
As for the buyers of counterfeit game controllers, they are not in an enviable position, as manufacturers block keys used for illegal purposes, and these buyers ultimately end up with non-functional game controllers without any indication of where to obtain firmware updates.
Translated by: He Yueying, Sun Zhonghao
