Anatomy of a Wii U: hexFW

As I mentioned in my last post, in parallel to researching the Vita's kernel I decided to research the Wii U and see what I could come up with.

For all this to make any sense, we must go back to the beginning and waste a couple minutes looking into the Wii U hacking scene's history.
It all began back in 2013 when team fail0verflow made a presentation at 30C3 describing their journey in hacking the Wii U.
For quite some time they became the reference in terms of research and documentation for the Wii U's internals and even set up a wiki for this purpose: http://wiiubrew.org/wiki/Main_Page
However, they had no intention to release their exploits or talk about any vulnerabilities. This led to a community-driven effort to recreate their steps and hack this system.

Attempts to exploit the vWii date from late 2013, but it wasn't until mid 2014 that Wii U userspace code execution was achieved. This was done originally by what would become the libwiiu team.
One year later, the same team achieved the first PowerPC kernel exploit (a TOCTOU involving the OSDriver structures) and opened the doors for homebrew (with some restrictions).
The libwiiu project became a very valuable framework to write, compile and execute code from within the Wii U's Web Browser and it kept being used across firmware changes.
Other projects were developed during this time frame and eventually branched away from libwiiu (e.g.: Loadiine, homebrew_launcher).

Later that year, the first reports of someone being able to break into the Wii U's secure processor (IOP, running a custom operating system called IOS and dubbed IOSU by the community) showed up. The hacker and developer hykem claimed that had defeated IOSU around December of 2015.
This was shortly followed by another team claiming the same feat. This time it came from smealum, plutoo, naehrwert, derrek and yellows8, all very well known video game console hackers from the 3DS (and PS3 in naehrwert's case) scene.
The 3DS group wasn't planning a release while hykem, on the other hand, revealed that was working on a CFW-like setup for a public release.
During the following weeks, hykem massively documented his findings on the wiiubrew wiki, but ended up disappearing before releasing his announced project.
Then came an awkward period of drama and mystery that marked the Wii U hacking scene for good.
Eventually, smealum announced he had no plans on developing further for the Wii U and released "iosuhax", a collection of patches for the IOSU that would, in theory, create a CFW-like environment (privileged memory access and direct communication with the IOSU in a RPC setup). However, no one released an actual exploit to take over the system and allow for firmware patching.
Earlier this year, someone documented two vulnerabilities found by hykem, naehrwert and plutoo in the wiiubrew wiki and yet again, a community-driven effort began to build an exploit based on these bugs.

This led us to today. The current state of the Wii U hacking scene is a fragmented playground with two dominant groups using this now public information to build an exploit chain and achieve the goal of building a CFW for the Wii U:
- Team SALT: a collective of hackers/developers mainly active on the 3DS scene that began working on a CFW solution quite early this year. They are developing everything in private and share a few details occasionally on their progress.
- Team wiiubru: formed under the public eye by early contributors and developers of the PowerPC homebrew scene that sparked after libwiiu. They develop everything in public and have achieved popularity among the community.

After learning about all this, I still felt motivated to research and work by myself for quite a few reasons:
 - The Wii U's security scheme is nowhere near the Vita's and is much easier to take down;
 - Public vulnerabilities already exist and there's plenty of documentation out there as well;
 - My vision conflicts with team SALT's and team wiiubru's.

That last point is crucial. Team SALT chose to work privately, which is understandable when dealing with something that can potentially brick your console, but it's not possible to evaluate what they have accomplished thus far. Also, one of their members was allegedly responsible for leaking team libwiiu's OSDriver exploit which doesn't inspire much trust in the group.
On the other hand, team wiiubru is doing everything in public, but using low standards in terms of code quality and organization, which is to be expected when working in large groups.

Not satisfied with either groups' approaches, I decided to come up with my own: hexFW.
The name may not be very original, but to be honest, I didn't put much effort into making it up.

So, in order to build a CFW of my own, I made two important decisions: use smealum's iosuhax as the base for IOSU patching and implement my own exploit chain.
In my opinion, iosuhax does the job fairly well. It's a set of patches and a script that replaces sections of a firmware image and re-encrypts it back to be run on the Wii U. The idea is to start with smealum's code base and evolve from there.

But that only covers the process of creating a CFW image, the hard part is to exploit the system and make it load this image.
I looked into wiiubru's public implementation of the two publicly disclosed bugs, but found many issues with it.
By far, what seemed to make less sense in their implementation was the fact that the exploit is launched using the "homebrew_launcher" (or HBL). This felt like an overkill: why exploit the PPC kernel and run userspace code to exploit the IOSU when the disclosed bugs can be used without kernel privileges?
After playing around with the bugs for a while I finally understood their point: it's really hard to pull this off solely from the browser.

Hacker yellows8 released a stagefright exploit compatible with the Wii U a long time ago which became the standard for userspace code execution under the most recent firmware versions (the bugs libwiiu had used in the past have all been patched). It's code is quite clean and does the job perfectly, so I decided to use it as the main entry point to achieve userspace code execution.
For compiling the code I resorted to libwiiu for it's simplicity and began writing the exploit chain from scratch. Soon enough I came across an issue that might have been why wiiubru decided to ditch direct code execution and resort to HBL and ELF loading: the userspace payload's size is limited due to the nature of the stagefright exploit.

Nonetheless, I came up with some creative ways of squeezing all the necessary steps into a single payload and managed to get it working.
This means hexFW is launched solely from the browser without the need for installing or using HBL!
Of course, this came with a small cost: it's very likely that running the exploit will crash once. This is due to how I'm locating a target thread inside the IOSU to modify it's stack pointer. However, if you reset the console it is guaranteed to launch the second time. After the launcher runs, the actual CFW will be booted into the system from the SD card.

I have released a preview version of hexFW on Github: https://github.com/hexkyz/hexFW
It contains my own exploit chain ("fwboot") and a copy of smealum's original iosuhax minus the filesystem patches (IOS-FS). This is merely to demonstrate it's usage, but the overall structure is very likely to stay the same. The following commits will consist in the actual firmware patches that make hexFW a CFW (SLC/MLC/OTP/SEEPROM dumping with/without compression, redNAND, USB read/write/install, coldboot, etc.).
If you're familiar with iosuhax, you can setup hexFW and it will generate a patched firmware image that contains smealum's wupserver. You can then communicate with it using the wupclient.py script and play around with it.

In the next days I'll be pushing several components of hexFW I've been working on. My next post will be a detailed write-up on the two vulnerabilities exploited and how I constructed the exploit chain from scratch.

Stay tuned!

The aftermath: What's next?

Even though HENkaku's KOTH challenge has ended, this is far from being the end!

First and foremost, I want to personally congratulate Team molecule for their achievements and show my appreciation for what they have done.
In the past few days we've got a full fledged CFW framework (taiHEN), an upgraded HENkaku payload (taiHENkaku), a SDK with plugin and kernel module support and a handful of valuable documentation on the Vita's internals.
I've taken the time to analyze everything and I simply stared at my laptop's screen in awe. The level of dedication that has been put into this project is mind blowing.
Their talent is unquestionable, sure, but the professional and meticulous way they handled everything is unparalleled.
Many successful companies (which actually profit from their work) don't have this level of coordination and dedication. I can easily tell this is a labor of pure love. Love for knowledge, curiosity and overall fun.
I can't thank you enough for what you have done here. I hope this will help cement how much hackers' love their work and promote an healthy coexistence between companies and individuals.
Four talented individuals brought interest back to a forsaken video game console and did it in the most respectful and professional way I've ever seen.
I can't stress this enough, everything was orchestred in such a way that the intentions of Team molecule became fully transparent and resulted in something that opens many doors without hurting the (almost non-existent anyway) market.

History has been made. Yes, we are talking about hacking video game consoles, but the principles behind this go way past that. We are actually seeing talented people doing something good and showing the world we have the right to explore, research and reverse-engineer in the name of knowledge.
Actions like this help building and supporting those who defend our rights and I eager for the day we have the freedom to explore without being afraid.
Thank you Yifan Lu, Davee, Proxima and xyz. Your work will never be forgotten.

So, what's next?
As you've probably noticed, the challenge's prize was the access to the now public Vita Wiki. Me and st4rk (the other winner of the challenge) were granted write access to this collaborative Wiki and I plan to put that privilege to good use.
I've been spending a lot of time researching the Vita's kernel and planning TrustZone attacks. All the information I'm acquiring in the process will be gradually added to the Wiki not only to fill in the gaps but also to continue Team molecule's work for as long as I can.
Even though we are running code inside the Vita's kernel by now, there's still a lot to do. Team molecule themselves have already defeated the secure kernel (a.k.a. TrustZone) and learned about it's true purpose: communicate with the security processor (dubbed F00D due to ELF headers).
I plan on following their steps and, hopefully, defeat the secure kernel next. After that comes the massive challenge of defeating the obscure F00D processor.
Considering how little is known about it and how small it's attack surface is, we may never even be able to take it down. Still, the process is guaranteed to provide critical information just like Team molecule has proven.

Parallel to all this, I've been introduced to a whole different "scene" recently. Earlier this week, a friend of mine came to me complaining about how disappointed he was with his latest purchase: a Wii U.
Apparently he hated the console and watching the new Switch's trailer was enough for him to get rid of it. Believe it or not, he wanted to toss it in the trash (yeah, money is not a problem there) but asked me first if I wanted it.
The last Nintendo console I ever had was a SNES so, why not?
Naturally, I began looking into hacking it and learned a looooong story about it in the process. Popular video game console hackers fail0verflow were the first to crack this device back in 2012, but only recently people have managed to defeat it's most critical security components.
Unfortunately, it appears that hacking efforts for this device are heavily fragmented with a large group of people working on it publicly and a smaller one working in private. Useful vulnerabilities are already public and a few shaky implementations are out in the wild as well.
After researching the console and analyzing what's been documented already I've decided to take a shot at it and over the last few days I've spent plenty of time digging into it and working on cool stuff for it (emuNAND, USB read/write, boot-time launching, to name a few).
I'll be publishing a few articles about this along with a crude CFW and some tools. I'm working on top of other hackers' work, so I'll be sure to cover and credit their work as well.

Stay tuned!