Saturday, October 28, 2023

Exploiting DNS response parsing on the Wii U

It's annual Wii U exploit time! 😄

Image of the Wii U connection test screen on the GamePad.

After reverse engineering parts of the Wii Us' NET stack for another project I was working on, I realized it's using a modified version of NicheStack.
NicheStack is a TCP/IP stack developed by InterNiche Technologies and is designed for use in embedded systems.

INFRA:HALT

If you end up searching for NicheStack on the internet, one of the first things you'll find is a security research report called INFRA:HALT, published by Forescout Research Labs and
JFrog Security Research. This report contains a set of 14 vulnerabilities, which all affect various parts of NicheStack.

While most of these vulnerabilities "only" lead to a DoS, two vulnerabilities might lead to remote code execution. One of them affects the HTTP server, which is not used on the Wii U. The other one sounds a lot more interesting though...

CVE-2020-25928

CVE-2020-25928 is a vulnerability in the DNS client, which is also in use on the Wii U. It has a CVSS v3.1 Score of 9.8 and results in a heap buffer overflow which can lead to remote code execution.

The code described by the INFRA:HALT write-up looks something like this:

uint8_t *cp;
cp = (uint8_t *)&dnshdr[1];
dns_entry->alist[0] = 0;
dns_entry->ipaddrs = 0;

for (i = 0; i < records; i++)
{
// ...
cp = getoffset(cp, (char *)dns, &offset);
cp = getshort(cp, &type);
cp = getshort(cp, &netclass);
// ...
cp = getlong(cp, &ttl);
cp = getshort(cp, &rdlength);
switch (type)
{
// ...
case 0xCu:
if ( type == 1 && rdlength != 4 )
err = 7;
if ( !err )
{
++dnsc_good;
if ( i < ( queries + answers ) )
{
if ( nameoffset == 0 )
{
nameoffset = offset;
// ...
}
dnc_set_answer(dns_entry, type, cp, rdlength);
// ...
}
else
{
if ( nameoffset == offset )
{
dnc_set_answer(dns_entry, type, cp, rdlength);
}
// ...
}
// ...
}
break;
// ...
}
}

As we can see dnc_set_answer is called for each record with type 0xC (PTR). 

The dnc_set_answer implementation does something like this:

void 
dnc_set_answer(dns_querys *entry, unshort type, uint8_t *cp, int rdlen)
{
// ...
switch ( type )
{
// ...
case 0x0c:
memcpy(entry->ptr_name, cp + 1, rdlen - 1);
// ...
break;
// ...
}
}

As we can see the DNS client basically copies the record data into a fixed size buffer on the heap without checking the size.

At this point I was interested and decided to take a look if the Wii U implementation suffers from the same issue. To my surprise the Wii U implementation looks something like this instead:

if (type == 0xC)
{
dnc_copyin(dns_entry->ptr_name, cp, dns);
}
else
{
dnc_set_answer(dns_entry, type, cp, rdlength);
}

The affected dnc_set_answer call is explicitly not called for the type 0xC (PTR) records. Instead a function called dnc_copyin is called, which does proper bounds checks.

So someone (at Nintendo?) fixed this several years before INFRA:HALT was discovered and disclosed? Well, they tried!

As we can see from the full code above there are two places where dnc_set_answer is called. The first one for answer records and the second one for additional records pointing to the first answer. But they only added the check for the first one?!

The second one still blindly calls dnc_set_answer without doing any size checks.

Exploiting it on the Wii U

After writing a quick PoC server to confirm this actually works on a Wii U, I decided to try and exploit this.

Since the dns_querys struct is stored on the heap, this is a basic heap overflow. The Wii U added a few additional fields to the dns_querys struct, which we can overwrite. Due to the NET stack running on the ARM co-processor, the Wii U later copies this entire struct back to the PPC side using an address stored in a reply struct. Unfortunately to overwrite the pointer to this reply struct, we would need to spoof a reply struct and point to it. Since the heap layout is determined by various network setup specific factors we have no idea where in the heap this dns_querys struct is allocated. So we need a way to store a buffer at a location in memory which we know the address of.

Introducing DNS over TCP

This doesn't seem to be part of NicheStack, but the Wii U features support for DNS over TCP instead of UDP. After two attempts of using UDP, the Wii U will switch to TCP if the truncated flag was set in the DNS header. For TCP support more fields were added to the dns_querys struct, one of them is a pointer to a buffer in which the received TCP data is stored.

So just overwrite this with an address in the stack and we can receive data into the stack? Unfortunately, no. Before storing data into this buffer it is resized using IOS_HeapRealloc (basically realloc), if it isn't NULL. If the heap block is already the same size as the reallocated size, the same pointer is returned though. This allows us to take over already allocated blocks inside of the heap but limits us to stay in bounds of the heap. If we point the receive buffer to one of the already allocated packet buffers at the start of the heap, which will always have the same address, we can receive data into a known memory location (limited by the MTU and TCP/IP fragmentation).

Remember the reply struct which is pointed to by the dns_querys struct? We now have a known memory location at which we can create a fake reply struct which points the reply buffer to anywhere in IOS-NET memory. This causes the entire dns_querys struct to be copied to anywhere we want and we can control approximately 256 bytes in this struct!

Memory layout showing dns_querys copying.

Creating a ROP Chain

Since the Wii U features no-execute on the ARM side, we need to write a ROP chain which performs a kernel exploit. Doing this within 256 bytes is tricky, but it's enough to open up a TCP socket, connecting to a server and receiving data from it into memory. We're abusing some buffering of the TCP stack implementation here, but it works!

We can now perform a stack pivot into the next ROP chain. 

I wish more IOS modules had a gadget to load the stack pointer from the stack!

In this ROP chain we perform a kernel exploit as described in the previous write-ups, and copy the kernel binary from the buffer we received over the socket in the previous ROP chain.

We now have kernel code execution!

Presenting: DNSpresso

Since everything on the Wii U needs to be coffee related this implementation is called DNSpresso :p

You can find the GitHub repository with usage instructions here.

Monday, January 23, 2023

Looking into the Stadia Controller Bluetooth Mode Website


With the end of Google's Stadia platform on January 18, 2023, Google published a website allowing people to "Switch the Stadia Controller to Bluetooth mode".
This seems pretty cool, but there are two points listed under "Important things to know" which I didn't like:
  • Switching is permanent
    Once you switch your controller to Bluetooth mode, you can’t change it back to use Wi-Fi on Stadia. You can still play wired with USB in Bluetooth mode.
  • Available until December 31, 2023
    You can switch to Bluetooth mode, check the controller mode, and check for Bluetooth updates until Dec 31, 2023.
While permanent switching is not a huge issue, since Stadia isn't available anymore, and the Bluetooth mode is way more useful, I still wanted to have the option to switch back.
Since the Stadia Controller's WiFi approach is rather unique, I didn't want to just disable it and no longer have the option to look into it.
 
But only one year to update the firmware and then you're stuck in "Wi-Fi mode" forever? I guess Google really wants to forget about Stadia forever, and get rid of the site after a year.
 
So I started looking into the switching process on the site, to try and avoid those limitations. I also reverse engineered some parts of the binaries hosted on the site, more about that later.

Analyzing the Bluetooth mode website

The JavaScript used by the site is minified which won't give us function and variable names. It doesn't stop us from seeing what it does and analyzing the packets using Wireshark though.
Note that most of the flashing process seems to be standard NXP stuff, and only contains some minor adjustments by Google. 

The site uses WebUSB and WebHID to communicate with the controller. It filters for several different Vendor and Product ID combinations, to determine the state/mode the controller is currently in.

The switcher loads several files from the data endpoint, which we'll take a look at in more detail later. From taking a rough look at the files and the logs in the JS, the "Bluetooth mode switcher" actually flashes a firmware update to the controller. So from now on I'll be referring to this as "flashing the Bluetooth firmware" and the site as "flashing tool/site".
 
 The site starts by checking the firmware revision and battery percentage while the controller is in the normal, powered on mode, this is referred to as "OEM Mode".
 

OEM Mode

While in OEM mode, after plugging in the controller to the PC without holding down any buttons, the site communicates with the controller using WebUSB.

It starts by checking the first two bytes of the serial number from the USB string descriptor. There are some prefixes which are not allowed to be flashed. The serial prefix is also used to determine if this controller is a development controller (dvt) or a production controller (pvt).

It then retrieves the current firmware revisions using USB control request 0x81.
Firmware revisions less than 0x4E3E0 are referred to as gotham, while all later revisions are called bruce. gotham being the old Wi-Fi firmware, while bruce is the new Bluetooth firmware.

After that the battery percentage is requested using control request 0x83 and retrieved with request 0x84. This value is used to check if the controller has enough charge (more than 10%) to perform the flashing process.

After all that info has been retrieved, the site asks us to unplug the controller and turn it off.
 

Bootloader

The site now wants the user to hold down the Options button, while plugging the controller back in. This will enter the Bootloader.
Not much to say about this mode. The site asks us to press Options + Assistant + A + Y while in the Bootloader, which will enter the SDP Mode.
 

SDP Mode

SDP (Serial Download Protocol) Mode allows sending several low-level commands to the controller.
The flasher uses WebHID to send and receive commands.
It starts by uploading a signed Flashloader binary (restricted_ivt_flashloader.bin) into the controller's memory (@0x20000000), by using the SDP WRITE_FILE command.
It then jumps to the uploaded Flashloader binary (@0x20000400) using a JUMP_ADDRESS command.
The controller is now running the Flashloader.

 Flashloader

The Flashloader is a bit more advanced than the previous modes. It can also receive and send several commands via USB, and the flasher site once again uses WebHID to send and receive those commands.
Google seems to have chosen a restricted version of this Flashloader though, since only a few commands actually used by the flasher are available.
Also only a few, small memory regions are allowed to be read and written using the WriteMemory and ReadMemory commands.

The Flashloader is used to actually write the new firmware into the controllers flash storage.
 

Detecting the MCU Type

The site starts by detecting the MCU type, by reading from 0x400D8260. There are two supported types (106XA0 and 106XA1), if the detected type doesn't match one of them it will throw an error.
 

Detecting the Flash Type

Since different Stadia Controller models seem to have different flash storage types, the exact chip is now detected. Detecting the flash type is a bit of an interesting approach. 
To communicate with the flash storage a FlexSPI configuration block needs to be loaded and applied. To determine the flash type, the site retrieves the device ID from the flash. It starts by uploading a special configuration block for determining this ID (flashloader_fcb_get_vendor_id.bin) into memory (@0x00002000), and applies this configuration using the ConfigureMemory command.
This configuration block contains some sane values for the different flash chips, and also contains a lookup table (LUT) with different FlexSPI sequences which will be sent to the flash chip.
For the get_vendor_id configuration the first sequence in the LUT, usually used for reading from flash, has been replaced with a Read Manufacture ID/ Device ID command.
Now comes the interesting part: The site now directly configures the FlexSPI registers using ReadMemory/WriteMemory Flashloader commands via USB.
It configures the FlexSPI FIFO and sends the Read Device ID command from the LUT sequence.
It then retrieves the result from the first RX FIFO Data Register.
It seems like writing to and reading from those few FlexSPI registers is explicitly allowed in the flashloader.

Setting up the Flash Storage

Now that the flash type is known the site can load the proper configuration block for that chip.
There are two supported flash types (Giga-16m and Winbond-16m).
To setup the Winbond chip an entire flash configuration block (flashloader_fcb_w25q128jw.bin) is loaded and applied.
For the Giga the flash is automatically configured by the Flashloader based on a simple configuration value (0xC0000206).
 

Flashing the Firmware

Now that everything is ready the actual firmware flashing can begin.
After clearing GPR Flags 4-6, the site loads the signed target firmware image (<bruce/gotham>_<dvt/pvt>_a_<dev/stage/prod>_signed.bin) and parses some build info values from it.
It also determines where in the flash the firmware should be flashed to. To flash data the site sends a FlashEraseRegion command to erase and unlock the flash, followed by a WriteMemory command to write to the flash mapped in memory @0x60040000.
The IVT (Image Vector Table) is now flashed to @0x60001000 (only if the image contains one), and the actual firmware application gets flashed to the proper slot location (Application A / Application B).

Cleaning up

Now that the firmware is flashed, GPR6 is set to the proper application slot and a Reset command is issued to restart the controller.
And that's basically it, the controller is now running the newly flashed firmware.

Dumping the old Firmware

As mentioned in the beginning, it is not possible to revert to the old Wi-Fi firmware using the Stadia mode switching site, once the new Bluetooth firmware has been flashed.
While the site does seem to technically support flashing the old Wi-Fi firmware, and also has references to the firmware files required for it, all those files lead to a 404 and can't be downloaded.
So to preserve the old Firmware I had to dump it from the controller itself.
 
I tried to read from the flash memory region while in the Flashloader, which only results in errors. It seems like reading from flash is not allowed by the restricted Flashloader.
 
But I had another idea...
Remember that we have direct access to some of the FlexSPI registers, which are used to determine the flash type?
 
Instead of applying the get_vendor_id configuration block and sending the Read Device ID command, I tried applying the proper flash configuration and sending a Read Data command over the registers.
That surprisingly did work without any issues. I could now issue FlexSPI read commands via USB and dump the flash.
 
Since only reading the first register of the RX FIFO Data Registers is allowed by the restricted Flashloader, I had to dump the flash 4-bytes at a time, which did take several hours.
At the end I had a full dump of the Stadia controller flash though!

Finishing up

During the testing I started reimplementing parts of the site in Python which I called stadiatool, which also allowed me to mess around with the Flashloader commands.
After dumping the flash, I extended the tool to allow flashing the firmware as well.
Note that this was a pretty quick project which is why the code might seem rushed.
You can find the GitHub repo here.

That's it for now, I might take a look at analyzing the firmwares themselves next.

Special thanks to cmplx for some help while analyzing this and for listening to my random ideas!

Exploiting DNS response parsing on the Wii U

It's annual Wii U exploit time! 😄 Image of the Wii U connection test screen on the GamePad. After reverse engineering parts of the Wii ...