Hacking Hacking the WiiU gamepad

[awesomeee]

I'm trying to come up with ideas for an actual product with this. Here's what I have in mind so far:

My first idea is a custom boot menu of sorts. The menu could either come up every time you start the gamepad, or be set to only come up when pressing a specific key combo.

It could then let you boot into the stock firmware, or into alternate programs, games, CFW, whatever you want.

It could let you connect to a wifi network to download said programs into your gamepad. IR could also be another way to transfer data, but I would have to reverse-engineer the UART hardware.

It could also have some utility features, like dumping the UIC EEPROM and whatnot.

Could even let you boot into the service firmware, if I figure out a safe way to do that. For whatever it's worth.

-

From a technical standpoint, the menu would be made of a custom bootloader (which would have boot options coded in) and the actual menu part implemented as a small 'firmware' of sorts. The latter part would be installed in one of the free spots in Flash.

I went over the Flash memory structure and usage. There are 7 'slots' of about 1MB each, which could be used to store homebrew or whatever you want. 3 more MB can be freed if you don't mind getting rid of the service firmware.

It could be worthwhile to look into expanding the gamepad's storage if there's actual interest into homebrew, but I think for now this will be good enough for a start.

-

Thoughts?

Sounds good. An idea I have for a simple homebrew tool for the gamepad would be something that sends input from the DRC to a PC or such. It would be pretty cool lol

Or possibly the GamePad as a camera? Just some ideas

 

[Arisotura]

There was libdrc, but I figure it would be nice to have something that supports regular wifi networks.

Would require some work in the wifi department tho. If I can get the non-Nintendo wifi firmwares working, 2.4GHz would be plenty for button input and all, but video would most likely require 5GHz.

 

[neverendsDull]

Maybe starting like I suggested earlier, cut/reduce the wake up frequency of the pad to save battery?
Of course provided the "wakeup" is initiated by the pad, otherwise we need to modify the console's firmware, then maybe an aroma plugin is needed.

 

[Arisotura]

I haven't looked into that at all, but I think this would be handled by the UIC, so we'd need to reverse-engineer the UIC firmware some more

 

[Arisotura]

Still thinking of the design for the gamepad menu stuff...

I was trying to see if I could get the non-Nintendo BCM4319 firmwares working. But I haven't really been successful -- they seem to only properly receive frames once in a blue moon, and I haven't found why. This makes them unable to get any connection going.

I guess I'll stick to the Nintendo firmware for the time being.

-

In the meantime, I gave my 'fix a WiiU gamepad' side project another try. If you remember this post: https://gbatemp.net/threads/hacking-the-wiiu-gamepad.661890/post-10569753

It was the gamepad that didn't turn on at all, gave no signs of life. As I suspected a bad PMIC, I wanted to try replacing that. However, had trouble doing a proper solder job -- everything is so small on the gamepad motherboard, and it wicks away heat so quickly, which makes it hard to solder stuff correctly.

The PMIC is a QFN package with a big fat center pad for ground (probably heat dissipation). I needed to use some hot air to be able to really clean up that center pad.

I had made some attempts at soldering a new PMIC, but I couldn't get good connections, couldn't properly tin the pads, ... I had a feeling I wasn't going to get anywhere without the right stuff, so I got some solder paste. Applied it as best as I could, with some flux, and placed my PMIC on there. The solder paste worked wonders, and I was able to remove the excess solder with hot air and tweezers.

The connections looked good, so I gave it a try. Lo and behold, it works! So I was right about the bad PMIC.

So now I got 4 functional gamepads. Oh yeah, the other failed one, which I thought had a bad Flash, apparently fixed itself? Either that or it didn't like being started with a battery pigtail in place of an actual battery.

 

[mikodraws]

I have a second gamepad, is it possible to flash it without open it up? Like with a wubp file?

 

[awesomeee]

I have a second gamepad, is it possible to flash it without open it up? Like with a wubp file?

EDIT: Ignore this, I thought it was in another thread lol apologies

 

[mikodraws]

EDIT: Ignore this, I thought it was in another thread lol apologies

Hey, I'm trying to use the screen of a gamepad, did you know what type of controller or protocol used?

 

[awesomeee]

Hey, I'm trying to use the screen of a gamepad, did you know what type of controller or protocol used?

I honestly have no idea.

Not sure why im being replied for this since I said I mixed something up. Apologies

 

[IamtheSandwicj]

I haven't read the full

I'm trying to come up with ideas for an actual product with this. Here's what I have in mind so far:

My first idea is a custom boot menu of sorts. The menu could either come up every time you start the gamepad, or be set to only come up when pressing a specific key combo.

It could then let you boot into the stock firmware, or into alternate programs, games, CFW, whatever you want.

It could let you connect to a wifi network to download said programs into your gamepad. IR could also be another way to transfer data, but I would have to reverse-engineer the UART hardware.

It could also have some utility features, like dumping the UIC EEPROM and whatnot.

Could even let you boot into the service firmware, if I figure out a safe way to do that. For whatever it's worth.

-

From a technical standpoint, the menu would be made of a custom bootloader (which would have boot options coded in) and the actual menu part implemented as a small 'firmware' of sorts. The latter part would be installed in one of the free spots in Flash.

I went over the Flash memory structure and usage. There are 7 'slots' of about 1MB each, which could be used to store homebrew or whatever you want. 3 more MB can be freed if you don't mind getting rid of the service firmware.

It could be worthwhile to look into expanding the gamepad's storage if there's actual interest into homebrew, but I think for now this will be good enough for a start.

-

Thoughts?

If you're taking requests I think it'd be really cool to have a feature that lets you take screenshots and send them to the SD card if possible. Aroma already has a screenshot plugin however it doesn't work in vWii Mode or on certain screens

 

[Arisotura]

I have a second gamepad, is it possible to flash it without open it up? Like with a wubp file?

Possible to do so from the WiiU, from what I heard. But you shouldn't go and flash the current melonpad codebase to it -- you'd need a hardmod to restore it to stock functionality.

-

Status update.

As I was thinking of how to lay out my menu stuff, I thought that the cleanest way to load a different binary (stock firmware, menu, whatever) would be to restart the gamepad CPU, and set a flag which would tell the (custom) bootloader what to load.

The gamepad already works this way -- for example, when you press the SYNC button, it changes the UIC state to 5, which reboots the CPU. The firmware, when booting, finds that the UIC state is 5 and loads the pairing screen.

However, I tried replicating that as a test and could only get the CPU to shut down for some reason.

So I'm digging into UIC stuff. My current goal is to get my STM8 emulator (berrySTM8) complete enough that I can integrate it into my bigger gamepad emulator (pomelopad) and see what happens.

Only got a couple features left to implement -- HALT instructions and some form of ADC support.

I also found where the RTC is initialized, and it seems it's set to wake up the system every 10 seconds. I'm not 100% confident I understood the parameters correctly, but regardless, it shouldn't be hard to change how often the gamepad wakes up. Maybe we can even make it configurable.

Downside is that it will require a custom UIC firmware, which is a bit scary considering how easy it is to brick the UIC. I'd be interested to get in touch with whoever has successfully attached a debugger to the UIC...

Not to mention the development time to get an open-source UIC firmware replacement going. The UIC does a lot of things, and we need to understand all of them. We could, of course, patch the stock UIC firmware, but it's less clean.

 

[neverendsDull]

it's set to wake up the system every 10 seconds.

WTF? I thought it was something like 5 minutes or so... This is definitely the culprit of battery drain

 

[Arisotura]

Again, I'm not sure I understood the parameters correctly, but it's also possible that Ninty fucked up

 

[Arisotura]

The gamepad already works this way -- for example, when you press the SYNC button, it changes the UIC state to 5, which reboots the CPU. The firmware, when booting, finds that the UIC state is 5 and loads the pairing screen.

However, I tried replicating that as a test and could only get the CPU to shut down for some reason.

Found out that it's related to wifi not being properly shut down. Experimented, with some progress, but still not perfect...

 

[awesomeee]

Another simple Homebrew idea would simply be some drawing tool or Pong lol. Of course the whole sending input from Gamepad to PC would be pretty complicated due to wifi chip issues. Maybe these would be simpler as tests

 

[V10lator]

they seem to only properly receive frames once in a blue moon, and I haven't found why.

Just a shoot into the blue but this might be a hardware issue. I get to this conclusion after reading here that there is a 5 GHz amplifier (SiGe SE5008L) integrated on the gamepads WiFi module.

//EDIT: There it is:

As you see with my markings it looks as it sits directly between the BCM and the antennas. This might simply not amplify or even filter out 2.4 GHz.

//EDIT²: From the datasheet this chip allows frequencies between 4900 and 5850 MHz to pass while boosting RX to +14 dB with an internal LNA. So yea, that's simply not suited for 2.4 GHz and the once in a blue moon package you see on RX might be unwanted interference.

 

[Arisotura]

Oooo, so that would explain it. Thank you for the info.

This sucks mildly though. Basically we ain't gonna do 2.4GHz on this stuff unless the hardware is modified. Then the only option for networking is to figure out how to modify the non-Nintendo Broadcom firmwares for 5GHz, or patch Nintendo's firmware to support regular WPA. And hope 5GHz networks are widespread enough.

 

[lordelan]

You could possibly achieve what Cemu didn't:
Make the Gamepad act as a second screen to a PC (or Steam Deck which is docked to a TV) so Cemu's second window (that of the gamepad) can be moved onto it while redirecting the button inputs from the Gamepad to a PC so we can finally use it with Cemu.

 

[N7Kopper]

You could possibly achieve what Cemu didn't:
Make the Gamepad act as a second screen to a PC (or Steam Deck which is docked to a TV) so Cemu's second window (that of the gamepad) can be moved onto it while redirecting the button inputs from the Gamepad to a PC so we can finally use it with Cemu.

With a modified GamePad firmware, there'd potentially be no need for "redirecting" - you could just connect the pad itself to a 5 Ghz Wi-Fi adapter on your computer. I'm assuming the bootloader doesn't prevent you from choosing to load either firmware block (from what I gather the firmware is indeed backed up on the pad in the official configuration)

Oooo, so that would explain it. Thank you for the info.

This sucks mildly though. Basically we ain't gonna do 2.4GHz on this stuff unless the hardware is modified. Then the only option for networking is to figure out how to modify the non-Nintendo Broadcom firmwares for 5GHz, or patch Nintendo's firmware to support regular WPA. And hope 5GHz networks are widespread enough.

The use cases for 2.4 with the GamePad would be limited, considering it needs 5 Ghz to maintain a stable 60 FPS 480p stream.

 

[Arisotura]

Well, some better news.

I managed to get the gamepad to connect to regular 5GHz networks. It also seems to support 802.11ac fine, unlike what I had observed.

I patched Nintendo's wifi firmware to get there. Most notably:

* The function at 0x24B78 is responsible for pairwise key expansion (basically, calculating the PTK from the PMK). The end of this function does the funny 3-byte rotate that makes it incompatible with regular WPA, so I patched that out.

* At 0x297F2 you find the bytes A4:C0:E1 (Nintendo OUI). When connecting to a WPA2 access point, the RSN information element's data is checked for this value, which means it will refuse to connect to a regular WPA2 access point. Changing it to the standard 00:0F:AC allows the gamepad to atleast attempt to connect.

* At 0x2AFEB you find a pattern for the RSN information element the gamepad sends to the access point. Same issue as above: all 3 instances of A4:C0:E1 need to be changed to 00:0F:AC. Then, and only then, will the gamepad connect to a WPA2 access point.

* The firmware has a CRC32 at 0x3D300. The wifi card will refuse to start if that CRC32 doesn't match the actual firmware data (from beginning up to 0x3D300).

With this in mind I guess I can implement some networking features.