30c3-5322.txt

Here, the subtitles for talk XY are supposed to be created 
  
Link and further information can be found here: https://events.ccc.de/congress/2013/wiki/Static:Projects
or: www.twitter.com/c3subtitles (most up to date infos)
or the table of ALL pads: http://subtitles.media.ccc.de/

The language is supposed to be: 
[ ] German 
[x] English  
(the orignal talk-language)
Amara Links: http://www.amara.org/de/videos/MedDt2Cy4XTb/info/ 
-------------------------------------------------------------------------------------------------------------

Welcome everyone, good evening, thanks for attending this talk.
So i am delroth this is shuffle2 we have another member in our reverse engineering team which is called booto
but he couldn't make it for 30c3 this year.
We are basicaly consolehackers and emulator developers. So we work on the wii on the gamecube and we are like developers of the  dolphin emulator  [...?] which is a gamecube and Wii emulator. And we were helped with this WiiU reverse engeneering project by friends from fail0verflow. You might have seen them day 1 they basically cracked open the WiiU and made it possible to do this work, so thanks a lot to them.
So for those who don't know what the WiiU gamepad is, so this is a WiiU gamepad. This is what you actually connect to the console to play games.
It's code named DRC, so we're probably going to use DRC a lot in this presentation just because it's a lot shorter to write and stuff like that. So just so that you know DRC is basicaly the gamepad.

As you can see it's not like your standard game cube control thing with just like two joysticks and a few buttons, it has actually a lot of features. The main feature is that it's a wireless device that you don't have to plug into the WiiU or anything, it's kind of standard nowadays, but still. It has an 854x480 touchscreen which is resistive so it's not like a capacitive touchscreen, it's just resistive. It has audio output and also microphone and together with microphone it has a VGA camera which outputs a 640x480 resolution. It also has the standard gamepad stuff, so analog sticks, 19 digital buttons, motion stuff like accelerator, gyroscope, compass, and a few other wireless stuff which are interesting like NFC and IR which is used actually to use the Gamepad as a TV remote, like it can communicate with your TV over infrared.

But one big problem with it, is that it's actually only usable with the Nintendo WiiU. Unlike Microsoft and Sony, with the Xbox1 and the PS4, they actually told people, we're going to release drivers at some point and you can use it with your PC, etc. Nintendo never said anything like that, they just don't plan for it to be open, just the Wiimote before and all of their other devices. It's kind of sad because it's a really fun device, like you could use it to do a lot of stuff like control robots or just create new games without being in front of your screen. So yeah, let's fix that! This is the whole point of this talk. So let's open the box. This is the motherboard of the WiiU Gampad, as you can see it's actually quite a complex device.

The main chip on this in the middle, the big one, is actually an STM8 CPU from ST Microelectronics, it's called UIC, it has written UIC on it. This is the first of actually three CPU's that are on this Gamepad. On the left you can actually see there is a big empty space where you connect the wifi chipset, it can actually be detached, it's a broadcoam wifi chipset, kind of standard. And on the bottom right you also have an empty space which is for the NFC antenna and NFC controller.

This is the other side of the motherboard with more interesting stuff, the chip on the right-most is the flash that contains basically all the code and firmware and stuff for the Gamepad.

And the CPU just to the left of the flash, is called, it's written on it DRC-WP and the only other marking on it is Japan. You have no other indication of what the chip is. And we see later on that this is the main CPU that controls most of the Gamepad. This is on the other side of the system, so on the WiiU Motherboard, not in the Gampad, so on the left you can see the main bundle with the CPU and the GPU of the WiiU and at the top right you have the DRH, which is basically just the same as the DRC the microcontroller on the Gamepad, but it handles communication between the WiiU and the Gamepad.

So how does it actually communicate? If you look at the back of the wifi chip, it actually indicates 5GHz for use indoors only, it's actually a wifi chipset that is very common. So you can just look online and start sniffing wifi in the 5GHz frequency band, but obviously it's encrypted. It's not that easy.

So just a side note, this is actually a big problem with this project, finding a properly working wifi device that can actually do access point mode on 5GHz channels is really hard, especially on Windows it's basically mostly impossible. On OS X I think some people actually managed to get access points working with all the features we need for this project.

On Linux actually only a few drivers are able to do that. So for example, if you take Intel wireless devices there is no AP mode support on most cards that support 5 GHz. On Atheros devices, you actually can find a lot of these cards, but they have minor issues which I'm going to talk about. Car? 9170 is basically [?] 7088? 9K ATH but for USB, for some reason it's very hard to find devices that use this chipset. They are the same minor issues like with ATH 9K, because it's basically the same chipset inside, but they also have the same minor issues. And then this one is interesting, the Rugging? RT 2800 USB is actually a nice USB chip, which is not too hard to find, has no major issues, but it only started working with Linux 3.11, which is fairly recent, so it wasn't actually working when we started this project. We might actually be able to work as well on broadcom chips but we haven't tested that yet.

So let's work on decrypting the communication between the WiiU and the Gamepad. We basically need two things: first of all ? is actually encrypted so maybe WPS or something like that, and what's the key used for encryption? So it was actually fairly easy to find strong signs of the encryption scheme. If you just look as the 802.11 at the packets that you sniff it just like WPA2 packets, it has these protected bits that the header is, basically integrity checks, basic encryption scheme, and you have 8 bytes in the 802.11 headers that are encrypted for every packet and this matches what WPA2 does with the CCMP ID. So just looking at it was really like it was using WPA2.

So we just need the key now. It was actually harder than expected. Actually no, they made it easy for us compared to just having to hack stuff. They actually have a nice feature, the WiiU, when you want to connect a Gamepad to a WiiU for the first time you have to pair it with the console, and what this pairing system does is you have, the WiiU displays four symbols on the screen and you have to type the same four symbols on your Gamepad and then the Gamepad can connect to the WiiU. And looking at dumps, it's actually using WPS. So WPS is a wifi standard that is used for auto configuration of wifi devices and basically what it does is use WPS with access points you don't know about, and they give you all the information, including SSID, encryption method, encryption key and everything like that.

So WPS is secured, well "secured", by the need to press a button on the access point or to enter the pin that is shown on the access point like to prove that you have physical access to the access point that provides you the wifi network. The specification is kind of interesting because it really doesn't make a lot of sense it's extremely complicated for something that should be simple. Like, just check that the guy presses on the button and sends them the data. This is actually how WPS works, there are actually eight steps to the protocol, as you can see, it uses encryption, Diffie Hellman, HMAC, with two seperate hashing algorithms, like ? K derivation fuctions,and a few other stuff like that, i'm not going to go over it the interesting thing to see in there that basically, you only get the config data at the end, and that each step basically checks if, they do that in HMAC over this message and the previous message, so that you can check that the message isn't tampered with. So obviously we tried to pair our PC with the WiiU just using WPS supplicant which is a standard Linux program to do WPS, And it failed. As you can see on this ? dump it failed at M2, M2 is at the second stage of this WPS stuff.

What's interesting, it's not actually the WiiU sending us an error message, it's actually us not recognizing what the WiiU sent us. So WPS supplicant sent an error message saying sorry I can't authenticate to you. So we looked at it a bit more, why is it actually failing and the HMAC of the previous message plus this message is not correct, which would mean, the interesting thing in this, is that, there is no user data, we don't [?] any user data for this HMAC, so that means that means basically the crypto was changed, so they took WPS, but it's not exactly WPS, they changed stuff that makes it fail [?] so always like, what's actually failing is that the auth key that is used for the HMAC is not the same. and the auth key is derived from something called the KDK and you can see it uses a string constant wifi using secure key derivation, so it takes the auth key from this key derivation function and it uses it to, well, this is what is used for HVAC, so KDK is derived from N1 and N2 which are basically random values and the MAC address, nothing depends on user data, nothing depends on symbols that we should have to enter. So everything should just work if there was nothing there doing a man in the middle, but it doesn't.

So that is when we actually started to do some weird stuff, so ? will explain how we actually worked on dumping the firmware.

So when we got the gamepad one of the first things we did was just inspect the board and dump all the flashes that we saw. And it turns out that everything is unencrypted and plaintext and the flashes were really easy to connect to. We did have to make some changes to flashrom, but it wasn't very difficult and as soon as we did this, we could start looking through the firmware that was contained on the chip and look for the interesting wifi stuff.

Oh, I just have a picture of our respective setups. And so before we could actually look for wifi code, we had to determine the filesystem that Nintendo was using on the flash chip. It's just some custom thing they that threw together with a really simple header and it contains two different banks, so they support safe flashing, so you can flash a new version, and switch to it atomically.

And within the blob, within the version of the firmware there are multiple blobs, which are LVC, wifi and UMI among some others, which are ? resources, but these are the main interesting code ones. After inspecting these blobs, we found out the LVC is for the main DRC chip which is an ARM 926 EJS and the wifi blob is for the broadcom dongle which is ARM cortex M3 code, and the UMI blob was for the STM8 UIC controller.

So we knew from before, we knew this string was involved in computing the KDK. And a simple grep returns that's only existing in the LVC blob. So after looking at comparable implementations in host AP we can see that we should see some kind of HMAC SHA256 being returned and entered into the KDF function as an argument. So, through the magical power of Hex-Rays we find this in the LVC code. They're just doing standard HMAC SHA256 and after it returns they are doing some post-processing to do rotate left three on the buffer. And that's the only change that they've made to the algorithm, so this is the crypto. [applause]

So let's go back to WPS, so now we can actually go further than just the second stage. So we need the WPS pin to be able to authenticate to it. But it's eight digits and the WiiU only shows us four symbols. An interesting fact in the WPS specification, is that they designed it in such a way that there are two stages where they are using the four digits of the pin and two stages where they used the last four digits of the pin. Which doesn't make any sense, because basically instead of having to test 100 million pins, like you should have eight digits and you wanted to try each of them, you only have to try 20,000 pins to actually go through the whole space and brute force the pin.

And another interesting fact is that normally, most people implement WPS pin by showing the pin on the device and asking people to enter the pin on the access point and what Nintendo did was the opposite, they show the pin on the access point, the console, and they ask the user to enter the pin on the device, which is the Gamepad.

That means that, unlike the opposite way, which is the usual usuage of the WPS pin, you can actually brute force the hash offline, without having to ask the console every time, hey is this the correct pin or not. So it actually only takes a few miliseconds to just find out the pin. So this is just how it works. Basically you have these four symbols you just replace them with the corresponding digits. Yeah. [applause]

Advanced scripters stuff, I know. And the second half is basically 5, 6, 7, 8. Which is interesting because it actually violates the WPS standard which says that the last digit should be a checksum. So yeah. It's actually another interesting fact, because you know the last digits of the checksum if you've already brute forced the first half, you only have to brute force three digits of the second half so it's not even 20,000 combinations to test, it's something like 11,000. I don't know what they were trying to do with this WPS standard, but it doesn't make any sense. And other people have actually exploited that. You can look at reverWPS which is a tool to brute force WPS pin on standard devices, it basically just does that.

After that, this is the last two steps of the WPS handshake, so it just gives us the information. So hey! This is the SSID, this is the 32 random byte you need to connect to the network. Great! But obviously that would be too easy.

[stopped transcribing at 17:30 if someone wants to continue]