Wii U Architecture

Welcome to the last section of this article (and thanks for making it this far!). Here is where we analyse how resilient the Wii U proved itself against the attempts of hackers. To be fair, no console (in this article series) has ever achieved 100% success rate. Yet, it's the amount of time a console remains 'unhackable' and the effort required that will, to some degree, affect whether game studios will invest in the platform.

Having said that, let's get on with the analysis!

Main targets

Nintendo had to defend three fronts with code-execution capabilities:

• The optical drive with its capacity of reading game discs.
• IOSU (running on Starbuck) with its exclusive ability to access most of the I/O and memory; and control Espresso.
• Cafe OS (running on Espresso) which is where the game runs on top of.

Protection implemented

First things first: The disc drive.

... Well, to this date, the drive hasn't been publicly cracked. There have been reports about the development of 'WiiKeyU' , a drive emulator that can load disc images, but nothing ever reached the stores.

Considering the low adoption of Blu-ray drives throughout the Wii U's lifecycle, I presume there wasn't enough enthusiasm to crack the drive and/or deeply research its new protection methods. For the curious, the Wii U's motherboard now authenticates with the drive in a similar way to the Xbox 360's drive and, from there, all communication appears encrypted .

That leaves us with two remaining targets (IOSU and Cafe OS) and, this time, there's plenty of research done.

Dedicated hardware

In general, there are many methodologies IBM and Nintendo employed to secure this console efficiently and cost-effectively.

First is a separation of concerns model present to limit hardware access between Espresso and Starbuck. This makes sure that if the main CPU (Espresso) is ever hijacked, the I/O is still protected somehow. Additionally, both CPUs contain a Memory Management Unit to disguise the physical memory map as they see fit.

Secondly, as I mentioned before, both Espresso and Starbuck bundle their own hidden Boot ROMs (with 16 KB and 4 KB, respectively) so they always come prepared with some degree of protection (RSA and AES encryption) before reaching out outer areas that are susceptible to tampering. In doing so, all subsequent code processed must be encrypted and only authored by Nintendo.

Thirdly, Starbuck disposes of considerable amounts of memory within Latte to boot up its operating system (IOSU) without having to reach out to external memory. This adds another layer of tampering protection.

Next, Starbuck embeds SHA-1 and AES-128 accelerators on its hardware to hash, encrypt and decrypt data without performance penalties.

Moving on, while Starbuck is technically an outdated ARM9 CPU, Nintendo enhanced it with a custom eXecute Never (XN) controller that restricts which memory locations Starbuck may execute . The XN block fulfils the role of an NX bit.

Finally, encryption keys and certificates are stored in OTP memory inside Latte and both Espresso and Starbuck can seal access to each entry as soon as they are finished with it.

Chain of trust

As per any software involving signatures and encryption, there must be a hierarchy in place from which signatures are trusted.

From Espresso's side, the master core always starts in a blank state, but as soon as it finishes executing the Boot ROM, it will only run binaries in the form of Ancast images (fail0overflow's nomenclature). Ancast images contain a header signed by Nintendo using a RSA-2048 private key (which only Nintendo knows) and its payload (the actual program) is signed with an AES-128 key. The OTP block provides Espresso with the AES key to decrypt Cafe OS' Kernel (the starting point of Espresso in Wii U mode). Afterwards, it's up to Cafe OS to enforce the security model.

Starbuck, on the other hand, uses the Ancast image format for their bootloader stages after the Boot ROM. After IOSU is loaded up and running, one of its kernel modules called IOS-MCP is responsible for verifying and decrypting the AES key. Afterwards, the encrypted Ancast image and AES key are uploaded to MEM2 for Espresso to finish decrypting it and finally execute the payload.

Applications in Wii mode share the same nature, Espresso is provided with a separate key for decrypting the Wii System Menu or NAND Boot Program , thereby enabling Espresso to execute Wii applications without downgrading its security model. Starbuck is also provided with two extra keys in OTP to decrypt cafe2wii (in Ancast format) and Wii system updates (installed as part of a larger bulk of Wii U updates), respectively.

Operating System protection

To further complement the chain of trust, each operating system adds extra layers on top of it.

To start with, Cafe OS implements process isolation so programs under Espresso can't fiddle with the memory space of their neighbours.

Moreover, the manipulation of Cafe OS applications is a complex process involving the two CPUs and different security mechanisms. To make a long story short, to install and/or boot up applications, the IOS-MCP kernel module is responsible for all the necessary routines . Before being installed, the application's signature (found in its header) is checked against the respective certificate stored in OTP, thereby making sure the application has been approved by Nintendo (as they are the sole possessors of the certificate's private key). Afterwards, the title key of the application is decrypted using the OTP-stored Wii Common key, this allows Espresso to execute the binary later on (as the payload is still encrypted). Finally, whenever the application is launched at any time, Cafe OS' Launcher is used to prepare the binary for execution and linking. Nevertheless, IOSU checks the signature again before transferring it to Espresso.

Finally, IOSU is aware of Espresso's applications and only grants certain I/O permissions depending on the app's entitlements. That means that particular applications like the Web browser will never have access to the SD card.

Flaws

At first glance, the Wii U's security model looks more resilient and gratefully solves many deficiencies of its predecessor. However, it's not without apparent flaws:

• Espresso, being an off-the-shelf CPU at its heart, only understands unencrypted code and, unlike the Xbox 360's Xenon with its hidden encryption logic, Espresso will have to store the unencrypted data somewhere after decrypting it. In practice, that data is exposed on MEM2, meaning it's at the mercy of external tampering.
• OTP lacks console-unique encryption keys (a big difference from the Xbox 360 and PS3), meaning that if they are ever extracted on a remote console, they will work on others.
• The Boot ROMs are secure media, but the code itself may contain vulnerabilities. Plus, the way the chain of trust is constructed makes the boot code a single point of failure.
• Data encryption/decryption relies on AES-128, a symmetric encryption system. While AES is faster than the asymmetric RSA, if the AES keys ever get extracted somehow, all encryption is therefore nullified.
• One of the pre-installed applications is a Web browser. Its rendering engine is a fork of WebKit and JavaScriptCore. The WebKit project provides a public report of security vulnerabilities continuously being discovered and fixed (as expected from any responsible and large open-source project). However, this also makes it an attractive starting point with many potential attack surfaces. To make matters worse, JavaScript engines tend to bypass memory execution protections as the engine needs to compile streams of JavaScript code on-the-fly (it's worth emphasising that's code coming from an arbitrary network server).
• Cafe OS lacks Address Space Layout Randomisation (ASLR), enabling exploits based on Return Oriented Programming (ROP).
• The Wii has already been completely hacked in advance, which leads us to think that vWii mode will share the same fate (and potentially spread to take over Wii U mode as well).

But of course, most of these weren't discovered right away (especially on launch day). So, we'll now take a look at how different security researchers and homebrew developers managed to crack this console.

Defeat

Breaking the Wii U's security model was a slow process. Yet, it eventually happened and thus opened the door to many types of homebrew applications. The journey was not without periods of long silence, super-secret discoveries, piracy-focus developments, unnecessary drama and golden eras.

Let's start from the beginning.

Extracting the keys

As soon as a device makes employs a symmetric encryption model like AES, it's a matter of time before hackers manage to extract the keys. It happened to the Wii and, lo and behold, the Wii U followed suit. Remember, once you have the keys, you can encrypt the content just like Nintendo would do, so that's one layer of protection nullified.

fail0overflow (Sven, Marcan and Comex) presenting their findings at the 30th Chaos Communication Congress (2013) .

On 2013, during the 30th Chaos Communication Congress, fail0overflow published a vast amount of discoveries and, shortly after, kickstarted a chain of reaction for other researchers and developers. To give an overview, fail0verflow noted:

1. Old Broadway and Starlet exploits from the Wii era still work on vWii mode. This grants researchers control of Starbuck, which can then be used to fiddle with memory and/or zap Espresso. In other words, a glitcher and snooper in-house.
2. As soon as Boot ROM finishes decrypting an Ancast image, nothing verifies the unencrypted data against third-party alterations. So, by altering decrypted memory (using a hijacked Starbuck in vWii mode), Espresso will end up executing arbitrary code. So much for having a Boot ROM...
   • This was a starting point for fail0verflow and it enabled the group to extract system code (only in vWii mode for now) for research purposes. Thus, paving the way for new discoveries. Although, this didn't include the Boot ROM and OTP keys as access is disabled before arbitrary code can be executed.
3. With control of Starbuck, latching the SREST (soft reset) line on Espresso while it's executing its Boot ROM induces it in an infinite loop (as the Boot ROM adds traps in Espresso's reset vector). However, if Espresso is soft reset at its last stages of Boot ROM execution (particularly, just after flushing the caches), the reset vectors point to a writable location in MEM2. Hence, enabling arbitrary code execution while the Boot ROM is still visible.
   • Consequently, Boot ROM was finally extracted (and subsequently studied).
4. Still with Starbuck, latching the HREST (hard reset) at shorter pulse widths than expected may induce Espresso in an unstable/unpredictable state, but that can work in the hacker's favour as Espresso may ignore instructions to hide OTP memory (where the keys reside). Furthermore, with the help of custom code, this enables to dump the encryption keys.
   • With this, fail0overflow managed to extract the AES keys used by Espresso to decrypt binaries.
5. Starbuck's Boot ROM (boot0) is hidden after this CPU updates a register. Well, the same register can still be re-enabled in vWii mode...
   • ...allowing fail0verflow to extract Starbuck's Boot ROM without much hassle.
6. The Wii U web browser's source code is public (as dictates WebKit's LGPL license). Well, the commit history of the project exposes references to past vulnerabilities. One of them was able to produce a heap overflow that led to arbitrary code execution.
   • Reproducing this vulnerability allowed the group to execute code in Wii U mode and subsequently extract Cafe OS for study purposes. Moreover, this environment also interacts with IOSU, which leads to the next discovery...
7. An exploit of IOSU was eventually found by the team, which led to code execution with Starbuck's kernel privileges in Wii U mode.
   • ... Resulting in Starbuck's encryption keys being extracted.

New possibilities

Taking into account that this was the first security-related presentation about the Wii U, the immense amount of work and achievements presented were astonishing. With this, homebrew developers could now start fiddling with vWii entry points.

Be as it may, there were still some gaps to be solved. Native homebrew was still not possible as Wii U executables still require valid RSA signatures. Plus, there was system code (i.e. boot2) remaining to be extracted and decrypted.

In any case, fail0verflow didn't publish their Wii U exploits right away, as they worried it would lead to piracy developments before homebrew or Linux support . They did however publish a guide to write Wii U code (including the possibility of bringing in Linux). Their environment still relied on vWii, with no access to Cafe OS or the whole of MEM2 , although it provided instructions for re-enabling multi-coring on Espresso.

Conquering Cafe OS

After fail0verflow's discoveries, progress began slowly emerging on the global Wii U hacking scene, starting with exploits on the web browser that led to arbitrary code execution with userland permissions (for now) under Cafe OS.

Relys showing his new pong game running on top of Cafe OS .

In March 2015 (almost two years later), user Relys published the first native Homebrew application running under Wii U mode , a Pong clone. It boots from a custom web browser exploit that takes over the UI thread and gains control of the frame buffer. The implementation of this game also managed to call native system routines to draw over the screen.

Back in the headquarters, Nintendo also began pushing frequent system updates to patch userland exploits using the now-famous "Further improvements to overall system stability" changelog motto. The cat-and-mouse game had started.

Example of website specifically crafted for triggering an exploit chain on the Wii U. The chain may also bundle a payload to perform something of use.

Soon after, homebrew development under web browser exploits became the de-facto standard. In the same month, to ease the effort, a new group of developers released libwiiu , a toolkit for developing software under a web browser exploit. libwiiu relied on the devKitPro compilation suite and provided additional CafeOS headers for accessing system functions (only those available under the web browser's userland). Finally, their toolchain automatically embedded a payload with the necessary exploits and packaged everything up in ready-to-host HTML files.

In August 2015, a new milestone was reached: the libwiiu team published a kernel exploit . The new discovery takes advantage of a multi-threaded racing condition by altering the contents of a structure called OSDriver before the Kernel can lock it . This allows neighbouring cores to fill it with data that eventually gets uploaded into the kernel's memory space. Consequently, arbitrary kernel syscalls can be added to read and write to memory without enforcing permissions.

In spite of everything, Nintendo already patched the OSDriver exploit with system version 5.5.0 (released only two days before the exploit became public). Furthermore, IOSU still couldn't be controlled (meaning no arbitrary I/O).

Fooling IOSU

For those who didn't update past 5.3.2 (as 5.4.0 patched the last userland web exploit and 5.5.0 fixed the kernel exploit), there was still more functionality to be unlocked. While IOSU remained unconquered, the tri-core Espresso was now under the user's control. So, as a workaround, IOSU could now be tricked into thinking it's executing an application and thus give out greater entitlements.

Golden45 showing his new homebrew application which enables users to launch game dumps from the SD card .

In October 2015, developers Golden45 and Dimok released Loadiine . This application relied on the Espresso kernel exploit to run pirated Wii U games from the SD card. To work, Loadiine is launched from the web browser and uses kernel privileges to kickstart an official application. Right after, Loadiine proceeds to mangle memory on-the-fly so execution is redirected to the game stored on the SD card. Initially, only Super Smash Bros. was used for this trick, then, Mii Maker was added as an alternative. In any case, all this memory fiddling is done to make IOSU think it's still running the same official program and thereby grants enough privileges for the pirated game to work. This method can't completely rely on the web browser as IOSU doesn't provide it with access to the SD card, for instance.

You may now think that further aspirations for homebrew were completely eclipsed after Loadiine brought piracy-related advancements. However, in February 2016, Dimok released Homebrew Launcher , another web browser payload that, this time, launches ELF binaries from the SD card. In an apparent tribute to the classic Homebrew channel by Team Twiizers/fail0verflow, the Homebrew Launcher lists the ELF applications stored on the SD card, and then allows users to launch any as they wish. This was a departure from having to embed programs into an HTML file and, similarly to Loadiine, the Homebrew Launcher hijacks the Mii Maker to operate.

The Homebrew Launcher in action.

Now, for those who updated to 5.5.0, good news awaited (at last):

• Since November 2015, new vulnerabilities were discovered on the web browser, thereby restoring userland execution. The new exploits relied on buffer overflows induced after pulling an MP4 file from a crafted PHP server .
• It seems a new kernel exploit compatible with the latest firmware was being beta-tested among a private group. That is, until May 2016, when the exploit got leaked by one of its testers . The new vulnerability relied on GPU7's direct access to MEM2 which inherently allows it to override parts of the kernel heap. Hackers used this finding to reconstruct the old trick that exploited OSDriver .

In conclusion, users on 5.5.0 were now able to enjoy the latest homebrew developments. In fact, these exploits haven't been patched to this day.

Reaching semi-permanency

Once the homebrew scene reaches a certain maturity, there's always one that asks... is there a way to make this more enjoyable? In other words, can we get rid of the need for the web browser?

Well, that's one challenging task, as IOSU is still enforcing code signatures before running any application on the System menu (hence, the need for the web browser and hijacking Mii Maker). All in all, without a method of installing unsigned channels and being able to launch them, it's back to the chicken-and-egg problem.

That brings us to the year 2016, which turned out to become an 'interesting' year for independent security research (and unnecessary drama ...):

• Hackers yellows8, smea and WulfyStylez discovered that certain application assets don't go through the typical security checks, allowing a third party to exchange them with others carrying potential exploits. To alter these packages, however, one would need an IOSU exploit that enables Espresso to move data in and out of NAND without special privileges.
• New IOSU exploits, with userland and kernel permissions, were developed independently by two separate hacking groups (plutoo and naehrwert on one side; and Hykem on the other). These found many vulnerabilities in IOSU's system calls and subsequently allowed to run arbitrary code with high permissions on Starbuck (meaning unlimited access to I/O).

In any case, neither of these discoveries was made public until the end of that year. The reason being most authors planned to publish them once they've got a proper end-user solution in place, and for that, they needed more time.

Regarding the game asset exploit, smea also discovered the emulator bundled with Nintendo DS games sold over the eShop (called 'hachihachi') carries dynamic code execution entitlements and, most importantly, its ROM parser is vulnerable to arbitrary code execution . Meaning that with the help of an IOSU kernel exploit, one could alter the assets of a purchased DS Virtual console game so, once the game launched, it could provide arbitrary code execution (in the same fashion the web browser was being used for). Well, this exploit chain was finally published in November 2016 and called haxchi.

Soon afterwards, developer FIX94 forked haxchi and made it work with the PAL version of Dr. Kawashima's Brain Training , with support for more games added in the following days. Furthermore, FIX94 implemented a straightforward 'installer' that automatically converts a DS game into a 'haxchi launcher' (facilitating the task of deploying haxchi for the average user). The installer additionally relies on an IOSU userland exploit discovered by Hykem.

If that wasn't enough, here's another discovery: Cafe OS's config files can also be altered to boot up any installed channel instead of the System Menu. Well, DS games are channels, so it should be possible to automatically boot up haxchi (to run Homebrew) as soon as the Wii U starts. Lo and behold, this was packaged up as Coldboot Haxchi. Unlike the rest of Homebrew apps, however, this scared some people off, as permanently altering Cafe OS' boot configs could also lead to devastating results!

As a curious note, once Haxchi had become popular, you could also observe Dr. Kawashima's Brain Training climbing the charts on the eShop, happy coincidence?

Unlocking IOSU

Now that users can run homebrew without depending on the web browser, is there something missing? Well, signature checks are still enforced, so Starbuck may need a bit more tweaking.

And here is where the good-old term of Custom Firmware (CFW) surfaces. Now that we've got IOSU kernel exploits and all necessary encryption keys, we could force Starbuck to boot an alternative system image (fw.img) from the SD card. The new system could have many 'annoyances' removed, like entitlements and signature checks. Well, this is what the Wii U homebrew scene called a 'CFW'.

Still, a CFW needs a bootstrapper, such as a homebrew application (with its set of IOSU exploits) that reboots Starbuck into our arbitrary image. Well, that task was taken care of by Dimok and his CFW booter utility released on October 2016 .

Now, regarding the actual CFW, hackers like smea released a set of utilities called IOSUHAX that facilitated the authoring of a customised IOSU firmware image .

A notable utility included with IOSUHAX was 'Redirected NAND' (redNAND). This enabled users to dump the contents of the NAND into an image file stored in the SD card, and then make both Espresso and Starbuck boot from there instead. The main advantage of this environment is that any change in IOSU or Cafe OS would not permanently affect the primary operating systems (found in NAND). Hence, any accidental damage done within redNAND could not break the console, meaning hackers and developers could use redNAND to play with the system files without worrying about permanent damage. Just another utility to make the life of security researchers a bit easier.

And so, CFWs (in the form of fw.img files) began surfacing on the net, each providing different types of customisations, including the removal of signature checks and even the addition of new system calls (interacting with IOSU Kernel modules) for homebrew programs to enjoy. All in all, allowing to install and run homebrew programs as 'official' channels on the System Menu.

Tweaking Cafe OS

As running a CFW quickly became the chosen method for any hacked Wii U, subsequent years focused on simplifying the steps required.

December 2016 saw the developments of CFWs that didn't require an fw.img anymore. Instead, the exploits altered the running IOSU and Cafe OS on-the-fly, they also disabled signature checks and added new system calls. FIX94's fork of Haxchi and Dimok's Mocha CFW are examples of these.

Moreover, the turn of 2017 saw the flourishing of sophisticated Wii U homebrew apps. To name a few:

• SwapDRC allows to swap the TV's framebuffer and audio with the GamePad ones on-the-fly . This is particularly useful for games that don't provide mirroring capabilities.
• Nintendont (another authoring of FIX94) maps the legacy hardware on unsupported Wiis (or vWii mode) so GameCube games can be played without resorting to any kind of emulation . While originally a Wii-only app, Nintendont can also be packaged with a GameCube game and installed as a Wii U channel (meaning it would take advantage of the Wii U's native storage). Then, the GameCube game would run on vWii mode but with extra support for the GamePad (as any other vWii virtual console game enjoyed).
• The Homebrew App Store provides a catalogue of hundreds of free homebrew apps ready to be downloaded directly from the Wii U (and then launched from the Homebrew Launcher) .
• WUP Installer to install channels on the Wii U's System Menu .

Much later on (now entering the year 2021), developer 'Maschell' published a new set of tools that eventually replaced the haxchi suite as the default tools for hacking a Wii. In it, Maschell brought a forked version of the Mocha CFW which could now be bootstrapped from the 'Health and Safety' app (using a new revision of the exploit that tampered with game assets ), thereby not requiring to purchase a Virtual Console DS game anymore. The new CFW suite also exposes a consolidated set of APIs to help developers implement plugins for Cafe OS, this was packaged up under a new suite/environment called Tiramisu .

The new Environment Loader (part of Tiramisu) lets the user select a particular set of patches and plugins before booting up the System Menu (or any other app of choice).

And here is when the story comes to an end. The scene is still going forward while Nintendo is apparently not interested in fighting it anymore. For what it's worth, the Nintendo Switch was released in 2017.