PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

November 18, 2012 // 9:44 pm - Following up on the Wii U Specifications with the US launch being today, NeoGAF user Trike has already uncovered what appears to be a Wii U Miiverse Debug Menu with details below.

Also of note, a Nintendo Wii U Teardown Guide is now available followed by a second Nintendo Wii U Teardown Tutorial and Geoff Keighley of GameTrailers TV has Tweeted that: The Wii U Firmware update is apparently about 5 gigs. No wonder it takes about an hour+ to download.

Additionally, the Wii U is able to run Nintendo Wii homebrew at launch (WiiXplorer ELF) and run Wii U games Off an SD Card, as demonstrated in the videos below!

From Rodger Combs: Let me stress this: the Hackmii installer (1.0) does NOT WORK. There may eventually be a version released that does work (I've been testing different beta exploits, to no success so far), but for now, nothing that requires Hackmii, uses current kernel exploits, or uses AHBPROT will work. That includes Devolution, USB loaders, cIOS installers, and Wii linux.

Nintendo can NOT patch Stack Smash using their current architecture. While it's definitely technically possible, it'd require a lot of work on their part, and could result in SSBB being unstable for all users. Plus, they most likely already knew Stack Smash worked before this video, so this isn't going to cause it to be fixed.

Potentially upcoming Nintendo Wii U upcoming games include the following:

  • Donkey Kong
  • Dragon Quest 10
  • Final Fantasy 3
  • Flipnote Studio
  • Metal gear solid
  • Metroid
  • Resident evils
  • Soul Hackers
  • Super Mario WiiU
  • Wii Fit
  • Yoshi’s Land Wii U
  • Zombie

To quote: Well, I was messing around in Miiverse trying to find out how the hell to do the initial set-up of my friends list to no avail. In doing so I accidentally found the "debug" menu on Miiverse.

At first I thought, "Hey, neat!" thinking it was just a legit secret or something. I can even access something with the name "prototype" that seems to be the actual prototype Miiverse in Japanese.

Apparently John Lennon is still alive and is posting on the Japanese Miiverse. Most buttons that I tried don't work (Acid_Test?) so I thought, hay, maybe GAF could have fun with this or translate it. That is when I found the admin list.

At first it asked me to sign in, because my login information didn't match. Then I pressed a button and it sent me to a list of admins anyway. They had buttons in the same row as the names, and I could "regenerate password" or "Delete Admin" or something along those lines. I didn't do it it because I didn't want to risk getting my god damn Wii U banned on day 1.

What should I do with this information? Is there anyway I can contact Nintendo about this directly without going through their customer service email crap? Should I let everyone know how to do it? Am I an idiot and this is already well known somehow? I can post pics, but they are going to have to be shitty cellphone pictures. Unless The Wii U has a built in snapshot thing.

I may be able to avenge Jim Sterlings Batman review post by deleting admins, what should I do?

Secrets revealed. Summary of events from my end.

I found out I could access the debug menu on Miiverse by hitting the "X" button on the gamepad while hovering over the exit button. I found an admin access list or something to that effect. I couldn't really do anything from there though.

I could view different messages from a developer though. One mentioned that there would be big games coming out (announced?) on the 10th of December. A different said "POKEMON" and "SUICIDE". Sorry, bro.

I went to another link that lead me to some test messages. I thought they were real when I found them, because they were posted 20 minutes ago from the time I accessed them. I could flag them for prohibited content, spoilers, and something else that I forget.

Then I went to a different link on the debug menu and it showed three different Miiverse subforums I could access that would be coming out on December 20th. I clicked on the "games for teens, kids and blahblah" (forgot the other two, I think family games was one of them?) and it lead to some sort of dispute between Timelord celebrities Tom Cruise and Brad Pitt.

There were even more subforums for games specifically, including Yoshi's Island Wii U and Soul Hackers, and less specific ones like "Metal Gear Solid" and "Resident Evils". By the time I stopped posting on gaf to check for more it was fixed, and someone pointed out that Nintendo put up a tweet ( about a miiverse fix.

I don't know if I really could flag posts to be deleted or whatever, but I know I could not make myself an admin or delete admins. At least when I pressed the buttons nothing happened.

Kotaku has cracked open Nintendo's Wii U revealing the System Memory and Speed as follows to quote:

The crew at PC Perspective raced home and opened a launch-day Wii U up on a livestream. While they didn't solve all the system's mysteries, like what its GPU is like, they did claim to ascertain how much system memory the Wii U is packing, and how fast that memory is.

According to PC Perspective's teardown, the Wii U has 2GB of DDR3 memory (provided by Samsung). User AlStrong on the Beyond 3D forums says this means the memory runs at a maximum speed of 17GB/s.

For reference, NeoGAF user Durante writes for comparison's sake:

  • 360: 22.4 GB/s + eDRAM for framebuffer
  • PS3: 25.6 GB/s main memory BW + 22.4 GB/s graphics memory BW, no eDRAM
  • GTX 680: 192.2 GB/s

The Wii U's North American launch today (November 18, 2012) offers consumers an 8GB model for $300 and for $350 the 32GB version which includes a copy of Nintendo Land.

Finally, crediar has leaked the WiiMode Keys and shared some Wii U Files for those interested!

Update: Nintendo officially stated the following to CVG regarding the Debug Menu: “It has come to our attention that some people were able to access a mock up menu on Miiverse following the launch of Wii U in the US.”

“Please note that this was only a mock up menu and has now been removed and is not accessible.”

Nintendo Wii U Miiverse Debug Menu Uncovered on Launch Day

Nintendo Wii U Miiverse Debug Menu Uncovered on Launch Day

Nintendo Wii U Miiverse Debug Menu Uncovered on Launch Day

PlayStation Follow us on Twitter, Facebook and join us at our new site WWW.PSXHAX.COM!

#32 - PS4 News - August 15, 2014 // 2:41 pm
PS4 News's Avatar
Below is a video of Unbuntu successfully running on Nintendo Wii U vWii from TeamScriptKiddies / Ninja_Carver (via as follows: (trinux-0.5a.7z) - write to sd card using dd or Win32DiskImager (trinux-0.6.tar.bz2) - lastest filesystem with ubuntu 12.04/triforce. To upgrade delete the contents of the linux partition, and extract this in the root.

For those who may not already know, our relentless developers finally managed to piece together the puzzle, and have some proof (yes, solid evidence) that the 'race attack' as described by fail0verflow is nearing completion. This portion of the overall 'hack' is far from finished, but is close enough to the point where it's time to branch off and begin working on the Linux portion of the over-encompassing project.

At this time, ONLY 2GB SD CARDS ARE KNOWN TO WORK. You are more than welcome to try with an SDHC card of larger size, but don't cry when it doesn't work. Though, you never know, it might work!

What you need:

For the manual installation, you can extract the above archive, then the trinux_0.5.7z file inside of it, and write it to your SD card using one of the many available programs. 'dd' if you're cool, or if you prefer GUI, Win32DiskImager (sourceforge), This SD image is broken up into three sections.

  • fat16 partition to store our app, you can place others in the sd:/apps/ folder if you'd like.
  • ext3 Linux filesystem
  • Linux swap space (not activated at this time)

After writing the image to your SD, you will only see partition 1. Windows is incapable of reading ext3 partitions. If you are lucky enough to successfully log in, you can try activating the swap space by typing:

  • ls /dev/mmcblk* (since the swap space is on the last partition of this device, make note of this, it will probably be /dev/mmcblk0p3
  • to activate type: swapon /dev/mmcblk0p3
  • If that succeeds, let me know and I'll issue a patch that will automount the swap partition on bootup.

Trinux Ubuntu 12.04 lts with LXDE as a G


Update: WiiU System Update 5.1.2 Released

Nintendo has released another system update which brings the Wii U to 5.1.2 and as usual it doesn’t change much. The full update changelog states:

  • Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience.

For now, nothing seems to have been changed or patched but as usual avoid updating until a developer gives the OK.

Finally, from TeamScriptKiddies: Hey all TSK here, Sorry for the delay in registering and dropping in. I'm happy to see that Ninja_Carver was on the ball at least .

I'd like to personally thank Bobbybangin for covering this on PS3Hax! He saw the work we were doing over at GBAtemp with the Wii U and decided to cover it over here too .

I first got a Wii U in March of this year, and for a while was only aware of the existing hacks for the vWii, but was unaware of the Trinux project. I stumbled across Ninja_Carver's (then abandoned thread) about Trinux and I was immediately inspired to offer to lend a hand with this.

Being experienced in linux, assembly language, and microprocessors, I knew I could offer Ninja_Carver help with this! So even though he had abandoned the project at this point, I contacted him offering my help. I also have a Wii U which he know longer has, so we set off to keep this project alive!

Ninja_Carver knows far more about linux then myself, so most of what you see in this beta release is all him (and the previous alphas were 100% him too). I was more of a tester for this then anything.

Going forward, when we're ready to start writing the instructions to utilize the additional cores of the espresso processor I will be more a lot more helpful.

Of course NONE of this would be possible if it wasn't for the discovery of the hardware flaw we're using to boot Trinux which was discovered by Maxternal and he wrote the code to execute the race attack we're using.

Furthermore, the exploit we're using currently to boot Trinux CANNOT be patched with software. It would require a major overhaul and redesign of the Wii U's hardware. The worst thing Nintendo can do, is block the trinux launcher and/or the homebrew channel, but even then, a simple change of Title ID's would unblock it . Nintendo really botched this one up!

As for when this is ported over to Wii U mode, that's a different story. Depending on how full kernel access is achieved in CafeOS, it maybe be patchable. All of the methods that are publicly being discussed as possibilities are all software based, meaning that they would be easily patchable, so think twice before updating. But as for the altered vWii state we're running Trinux under, there's nothing nintendo can really do about it . Kudos to Nintendo for their epic fail

Having more fun with Trinux:

Wii U Trinux, Teaser of What's To Come in Later Beta Versions (and NES emulation!) Part 1

Wii U Trinux, Teaser of What's To Come in Later Beta Versions (and NES emulation!) Part 2

Trinux Ubuntu 12.04 lts with LXDE as a GUI

Me showing off FCE Ultra (NES emulator) running on our very first beta release of Trinux for the Wii U! Also showing off some features coming soon in later beta versions! WIN!

Download: trinux-10b.7z

[Register or Login to view code]

Sorry guys, I didn't realize that seeding wasn't enabled in my bittorrent client and then I accidentally deleted the torrent info from it to make matters worse XD. Seeing as I was the only person who could potentially seed that link is now dead and I've since removed it.

Here's the new magnet link:

[Register or Login to view code]

And I verified that its seeding right now as we speak off my desktop. I'm going to reattempt to download this onto my laptop as well to help with seeding until this (hopefully) takes off, or at least until BobbyBangin gets the mediafire link up. Thanks again for that man!

Download: trinux-1.4b.rar (566.85 MB)

Rumblpak over at GBATemp, has managed to successfully truncate the image of the latest beta release (1.4b) so that it fits on sd cards between 2gb-8gb. No need for cards 8gb and up anymore.

Download: trinux-1.4.tar.gz

Hey all, just dropping in for a quick update. Unfortunately, my free time is very limited at the moment to work on the Trinux project as school has started up for me again. That being said, rumblpak and others have stepped up to help with this project.

I'm still working on getting the trinux start page functioning and helping to improve usb mass storage compatibility (when I have time) as is rumbplpak among others. Maxternal and rumblpak are also working with Ninja-Carver to rebuild the current linux kernel we're using to improve it overall.

From 2haloes: Hey all, So I have created an img file for Trinux that fills out 8GB of flash storage, it also includes some apps and a couple of wads needed/to help run Trinux, currently it is being hosted on my personal web server for now.

Until I can upload the file to a proper site, you can find it at:

I will attempt to compress it to .zip and .7z (There is a lot of empty space still, I just blew up the partition space)

From TeamScriptKiddies: (via Hey everyone, just had a chance to try out trinux on my new 16gb sd card and its working fine. Everything is A okay. I'm also downloading/installing Freemat (Engineering tool and development environment/programming language), to see if I can get it running (as mentioned previously).

I'm using the synaptic package manager to do this and due to this, the time its going to take to download/install is pretty excruciating due to the limited RAM and the low clock speed we're using..... This could take a while...

UPDATE: Installation complete, just rebooting the Wii U and back into Trinux as a lot of resources were taken up by the installation itself lol

UPDATE 2: I just finished making a video of FreeMAT running just fine under Trinux. I'm uploading it to youtube right now

UPDATE 3: Youtube video added. Script file coming soon...

#31 - PS4 News - July 31, 2014 // 7:01 am
PS4 News's Avatar
From Gary Wayne Bowser (aka garyopa) who is peddling the Wii U UDE/ODE devices to profit off the scene once again:

Only been a day since MarioNumber1 updated the Wii U's Browser Exploit to handle latest firmwares

And already great things are happening at amazing speed in the newly formed Nintendo Wii U's scene, here is exclusive image of new app being developed to will allow you to launch Homebrew & Dump Keys!

A picture they say is worth a thousand words, and this one is worth millions I think, it was given to me by developers that wish to remain for now 'uncredited' and don't ask for ETA, but its been worked on daily, and we will post more good news regarding the growing Wii U scene over the next few weeks, so stay tuned for some ball-busting amazing action found right here.

For that to happen we need the Wii U Common Private Key released so we can resign new iOS modules, there is testing underway to find this key, but it has not happen yet, for now with the current keys possible we can only explore and unpack code and study it, we need either to find an exploit to bypass signing/checking of modded kernel running code that loads on bootup, or the 'private key' to resign our new modules to look legit.

But it will come, one step at a time, at least now with Browser Exploit we can continue to explore the userspace and poke around seeing what we can access at run-time and change things on fly, and explore the latest firmwares to find more holes and possible exploits.

From pcm: It took me four minutes to do this, and anyone can do it yourself.

From steplay29: Pretty sleazy way to try and get followers to your site gary. photo shopped and as seen by pcm above very easy to do. remove thread and dont resort to cheap and dirty tricks.

Finally, from Marionumber1 himself: Just like pcm said, an image like that incredibly easy to fake. You can use OSFatal() to print whatever you want to the TV and Gamepad screens. A video of this in action would be much more believable.

#30 - PS4 News - July 30, 2014 // 6:43 am
PS4 News's Avatar
MarioNumber1 updated the official 'Browser Exploit' today. Now Wii U console owners on v5.0.0 and latest v5.1.0 firmwares can now enjoy the 'Browser Exploit' as it been recently updated by MarioNumber1 from the previous v4.x codes, so now everyone can use it!

Download: Wii U Bitbucket / / (Pre-compiled files by zecoxao)

The world-famous Wii U Browser Exploit is no longer stuck in the land of v4.x firmwares, as MarioNumber1 along with some trusted code testers have now updated the official release to handle v5.0.0 and v5.1.0 firmwares, so now amazing enough the WebKit Bug Exploit is fully working and been tested on both those console firmwares, thanks in part to all the testers and of course MarioNumber1.

Thanks to some work by Chadderz and me, we were able to get memory dumps on a 5.0.0 Wii U. I then used these memory dumps to rebuild the ROP chain, which as it turns out, also works on 5.1.0. This means that all versions of the Wii U system software above and including 4.0.0 are supported.

Here is the updated from Mario's BitBucket, please visit it for all the latest commits and to get cracking on your Wii U:

This repository contains a way to run code inside the Wii U's web browser. It provides a means to execute arbitrary code in the Cafe OS userspace on the Espresso processor. It does not allow running code in Espresso kernel-mode or provide any access to the Starbuck. We hope to implement this in the future, but the exploit is currently limited to userspace only. Right now, all current Wii U system software versions above and including 4.0.0 are supported.

What's inside?

Inside this repository, you will find a set of tools that allow you to compile your own C code and embed it inside a webpage to be executed on the Wii U. There are also a few code examples doing certain tasks on the Wii U. Most notably, there is an RPC client which allows your Wii U to execute commands sent over the network from a Python script. Nothing in this repository is useful to the general public. You will only find it useful if you are a C programmer and want to explore the system by yourself.

How do I use this?

C build system

This repository contains a C build system, which allows you to compile your own C code and embed it inside a webpage to be executed on the Wii U. The webpage contains some Javascript code that triggers the WebKit bug and passes control to your C code. Running your own C code on the Wii U gives you full access to the SDK libraries. Any function's address can be retrieved if you know its symbol name and containing library's name (more on this below).

Before using the C build system, you must have the following tools:

  • Unix-like shell environment (use Cygwin to get this on Windows)
  • devkitPPC (needed to compile and link the C code)
  • Python 3.x

Navigate to the root of the repository in the shell. Then enter the following command at the command line:

[Register or Login to view code]

where [filename] is the name of a C file inside the "src" directory, and [version] is the Wii U system software version you're building for. Supported version strings are 400 (for 4.0.x), 410 (for 4.1.0), 500 (for 5.0.0), and 510 (for 5.1.0). Not supplying a version string will cause it to default to 5.1.0.

Accessing the SDK libraries

When you're writing C code on a PC, you have the standard library, a set of useful functions that you can call without caring how they work. For writing code on the Wii U, there's something similar: the SDK libraries. The SDK libraries provide access to graphics, audio, input, filesystem, and network functions. The SDK libraries are accessible from any application, including the web browser, which means that code running inside it using an exploit also gets access. All SDK libraries have full symbols available for every function. Aside from making reverse engineering easier, this means that you can get the address of any function by its library and symbol name.

Before using the SDK, it's important to understand the Wii U's linking model. Some of these details were provided in comex's part of the 30c3 talk, but it only touched on it. Each executable on the Wii U uses the ELF format, with slight modifications (this format is called RPX). RPX files contain a list of imports, which specify a symbol being imported from an external library along with the name of the library itself. The libraries referenced by imported symbols use the same modified ELF format, but are named RPL instead. When an RPX is loaded, the executable loader will also load its RPL dependencies.

Every SDK library is an RPL file. For example, gx2.rpl is the name of the graphics library, vpad.rpl is the name of the Gamepad input library, and nsysnet.rpl is the name of the BSD sockets library. There is also a special RPL called coreinit.rpl, which is quite interesting. coreinit provides direct access to many core Cafe OS services, including memory management and threading. coreinit was also quite useful for providing the functions we needed in our ROP chain.

Now that I've spent 3 paragraphs telling you how the SDK works, let's actually get around to using it. So how do you use it? The SDK libraries expose many functions, but how do you get their addresses? You could just hardcode them, obviously, but that's both lame and not portable to later exploit versions. Plus how do you find the address to hardcode in the first place? There's a much better method available, which allows you to get symbol addresses dynamically, in the form of the coreinit OSDynLoad functions. You can access these functions by including coreinit.h in your C file.

There are two functions involved in getting a symbol, splitting the process into two parts. The first function is OSDynLoad_Acquire(), which loads the RPL you specify. OSDynLoad_Acquire() takes two arguments: the RPL name as a string and a pointer to an integer. The RPL name is pretty straightforward, the pointer to an integer is where coreinit will store the library's location. OSDynLoad_Acquire() can also be used to get the location of a library that's already loaded. The second function is OSDynLoad_FindExport(), which finds a symbol given a library's location. It takes four arguments: the integer (not the pointer to it) used in OSDynLoad_Acquire(), just zero, the symbol name as a string, and a pointer to where the symbol address should be stored.

Here are the function prototypes:

  • void OSDynLoad_Acquire(char *rplname, unsigned int *handle);
  • void OSDynLoad_FindExport(unsigned int handle, int always0, char *symname, void *address);

Just as an example, let's say I wanted the VPADRead() symbol from vpad.rpl. If I have an integer called "handle", I first call OSDynLoad_Acquire("vpad.rpl", &handle); to get the RPL's location. Next, if I have a function pointer for VPADRead() called "VPADRead", I call OSDynLoad_FindExport(handle, 0, "VPADRead", &VPADRead); to retrive VPADRead()'s address. Simple. For more examples, look at rpc.c.

RPC system

In addition to letting you write your own C code to run on the Wii U, this repository also includes an RPC system to interactively experiment with the Wii U. It allows you to send commands over the network for your Wii U to execute. The two components of the RPC system are the server, a C program running on the Wii U listening for commands, and the client, a Python script that sends the commands.

To use the RPC system, first ensure that your PC and Wii U are connected to the same network. Once they are, find out your PC's IP address using the "ipconfig" command (Windows) or "ifconfig" command (Linux and OS X). Modify PC_IP in socket.h to be your PC's IP address (rather than, which it currently is). Build rpc.c and it will go in your htdocs.

Next, start in an interactive Python session (IDLE or IPython is a good choice). Once you've started, navigate to the browser exploit you just made on your Wii U. It should appear to finish loading the page, and the UI will continue to be responsive, but web browsing will be disabled. At that point, the Python shell should say something along the lines of "Connected by" followed by your Wii U's IP.

Now you can control your Wii U with these commands:

  • rpc.read32(address, num_words) - Read num_words words starting at address, returning a list of words
  • rpc.write32(address, words) - Write each word in the list words to memory starting at address
  • symbol(rplname, symname) - Get the symbol symname from RPL rplname and turn it into a callable Python function
  • rpc.exit() - Exit the browser and go back to the menu


  • Marionumber1 - ROP chain design/implementation
  • TheKit - WebKit bug finding, ROP chain implementation
  • Hykem - Finding ROP gadgets
  • bubba - Testing WebKit bug candidates
  • comex - Access to the coreinit and WebKit binaries
  • Chadderz - Blind memory dumping on 5.0.0
  • Relys - Testing exploits

Note: Today (August 4, 2014) version 5.1.1 was released and they did patch the exploit so do NOT update to that version!

OLD ONE v5.1.0: Mozilla/5.0 (Nintendo WiiU) AppleWebKit/536.28 (KHTML, like Gecko) NX/ NintendoBrowser/

NEW ONE v5.1.1: Mozilla/5.0 (Nintendo WiiU) AppleWebKit/536.28 (KHTML, like Gecko) NX/ NintendoBrowser/

#29 - PS4 News - February 23, 2014 // 8:19 am
PS4 News's Avatar
Wii-U Bootrom Dumped, Welcome to the Wii-U Scene

It’s one small step for man , one giant leap for the wii-u scene. I can exclusively reveal that the first step to a wii-u hack has been completed & tested & working. I have personally tested the exploit and it is 100% REAL.

Here are the Hashes of My Bootrom.bin

sha-256 (B3DEDC6CA2C411F54F1BFEAC07D6F57DBB06D3CB7AB9A331CF5A7CBF2A50AF69)
sha1 (3D331B3165F9638C6CD6221702B2F736F7FCF931)
MD5 (388726887621220A888E9F22E6DB1788)

They match Failoverflows

Many people have worked on bringing this to you , so please give all credit to Bubba , MarioNum1 , Hatax2 , Odcd007 , Joostinonline , Maxternal , Crower & Marcan

FILESIZE is 16,384 Bytes


Finally, from Maxternal and MarioNumber1:

As the person behind this, I should point out that Nintendo can't patch this exploit through firmware updates. What I (and fail0verflow before me) did was take advantage of a design flaw in the Boot ROM, and the Boot ROM can never be updated. Nintendo could change the Boot ROM with newer Wii U's, but all current Wii U's are vulnerable.


Dumping the Boot ROM is the first step of reproducing what fail0verflow did to hack the Wii U.


Yes, all you need to do is run a DOL in vWii mode with AHBPROT access.

From bubba: This is where we are at... this is the steps to take...

1. Bootrom Done (Boot ROM just teaches us how the OTP works)
2. Once We know how it gets the keys, We need to do the HRESET hack
3. Exploited Wii U mode and later used the keys to exploit Cafe OS
4. From IOSU, you basically have full control of everything

From delroth (via

Wii U Bootrom “dumped” – what it means in practice

Two well known media-whores from the console warez scene recently revealed via posts on several websites that they got hold of the plaintext of the Wii U Espresso Bootrom. Because these people have no idea about console hacking and are just good/bad at overhyping things they don’t understand and didn’t write in the first place (props to Maxternal & MarioNum1 for the work on implementing fail0verflow’s exploit revealed back in December), I thought I would write a quick article about what having an Espresso Bootrom dump does.

TL;DR: Nothing. It’s just a first step towards potentially implementing a more complex exploit that allows getting PowerPC ancast decryption keys. In itself it is completely useless.

The Espresso bootrom

This bootrom which was dumped is the first code that runs on the Wii U PowerPC “Espresso” CPU. Its role is to check the signature of a PowerPC binary, decrypt it, lock access to decryption keys and bootrom code, then run it. It is a new security measure that did not exist on the Wii “Broadway” CPU, which simply ran unsigned binaries.

In practice, this bootrom is useless because of a stupid TOCTTOU vulnerability. It is possible to run any unsigned code on the Espresso, and this was disclosed by fail0verflow back in May 2013. Getting the bootrom plaintext does not provide any more information towards that since it is already broken.

On top of that, fail0verflow described in great details how the bootrom works internally in their talk at 30c3. Getting the plaintext of the bootrom is not really any help there since you could just read the slides and know everything it does. The only useful information that was not (as far as I know) provided is the location of the keys (SPRs/MMIO addresses?), but since the bootrom lock access to keys after it has run, this is not useful information in itself.
So what does it provide?

For the developers working on this hacking project: a step forward that allows them to implement the more interesting HRESET race attack. This attack was also described by fail0verflow in their 30c3 talk and allows corrupting the internal state of the CPU using short hardware reset pulses. It is way more difficult to implement than the basic SRESET race used to get a bootrom dump so at the current speed I wouldn’t expect anything new in that area for a few weeks/a month.

For users, pirates, etc.: nothing. While this small step was overhyped by media-whores using fake images of Wii U GamePads with cool pictures on them, it does not provide any more access to the console than was previously possible. The only new useful information from that dump is the location of the keys, which is not useful by itself. It is far from being “one giant leap for the wii-u scene” as announced. Don’t trust stupid people.

From JonathanD: Well they dumped it, but it is still encrypted. So really what this has done was to enable them to read the ROM from the Wii-U's system. So until they discover the key or a weakness in the encryption this is almost useless. (Not useless but for 99.9999% of the population it is useless lol)

I guess the best analogy to this would be they made a photo copy of a book in Russian but they don't read Russian, now they need to find a translator...

From devram0 (via

AES on the Wii U bootrom

Update 2: Ok, it's not an 'obfuscation' as i said. I'm an idiot! as a man, i am, i make mistakes. This post was about the problem i had on finding where the aes function was called, and i just wanted to share with the people! Errors makes people happy!

So these are the correct things: They save some addresses into the memory somewhere after this offset 0xE0000000 then when they call a function to save the address of the AES implementation, then they call it via a function as a function pointer.

AES obfuscation on the Wii U bootrom

I've read the whole bootrom code and i have to admit, that big N has done a good job on hiding where and how it calls the AES code. Finding the AES implementation is easy, it's just before the ancast header check function and after the most useless function. Finding how the AES implementation is called, is a little bit hard, for two reasons:

  • there are no cross references in the text segment; This means you will not see something like: bl AES_Decrypt
  • there are no addresses saved in the data segment: AES_offset: .long AES_Decrypt

So how to find it? you have to read the code, because the value is hardcoded and saved into a memory on an unknown address (like 0xE0000000); then a function will load that addresses to the count (CTR) register and jumps there. I'll make an example:

How normally should be:

view plainprint?

[Register or Login to view code]

How is obfuscated on the Wii U: view plainprint?

[Register or Login to view code]

The last thing: I had a lot of fun on reverse the whole bootrom. You'll find interesting stuff, there (but not keys ).

Update 1: Some said that it's a function pointer. Yes, it's true, but the 'obfuscation' that i'm talking about is quite different. When you create a function pointer, you can have the following things:
view plainprint?

[Register or Login to view code]

On the Wii U ths is a little bit different. The address is stored in the register, but it's relatively static to the copy of the bootrom, not to the bootrom itself. this means, the addresses was coded by thinking that the rom was going to be loaded at another offset.

In this simple way you obscurate partially of the code. There is no reason to make a function pointer that you are going to use just once. Function pointers are useful, if you are going to use callbacks, arrays, etc., but not in this case. In fact if you change the loading offset to the 'suitably one' of the bootrom you will get the cross references..

By the idiot who has wrote a stupid thing

#28 - PS4 News - December 28, 2013 // 2:19 am
PS4 News's Avatar
Here is some of slides from tonight's talk at 30C3 by Team Fail0verflow in regard to their attempts to pwn'ed the latest Nintendo Wii U console, inside find also a link to the video from their talk.


30C3 Console Hacking WII U

Reverse Engineering the Wii U Gamepad

It looks like you'll soon be able to play PC games and emulators directly on your Wii U GamePad. That's right, the Wii U GamePad hacking conference by 'delroth' happened today at 30c3.

Basically, he and his team cracked it, and got it streaming from a PC. They showed off emulators (including Dolphin) running really great on the device.

The libraries and documentation about their findings are located at Just keep in mind that this is currently Linux only, so someone will have to port it to Windows in the future.

You can watch the full conference on the YT video below (demos at around min. 47). Also, take a look at the slides from the talk here:

Update: The Fail0verflow team released a big long write-up to cover up some technical questions regarding their recent 30C3 talk, at the end of this long blog post (, they re-print and talk about each key they found and released over the last year, and end the update with why [boot0] is not really needed, and even without they did hacked the Wii U!

The hardware

First, two corrections: the second core (core 1) of the Espresso contains 2MB of L2 cache, and the GPU is a member of the R7xx family, but not specifically the RV770. Sorry, I was tired and sleep-deprived when putting together that slide and had two brain farts. The slide has been corrected in the online version above.

There has been a lot of speculation about the hardware, mostly before the talk, and even after it some people continue to be skeptical of our findings. How do we know what makes the Wii U tick? The answer is simple: inspection of the system firmware and runtime logs, and a little bit of common sense.

We used a simplified block diagram of the hardware for the presentation. Here's a more detailed one which you might find more interesting (there may be a few minor mistakes, but in general it should be pretty close). Hover over to see the equivalent Wii block diagram, for comparison.


Let's look at the Espresso. Why a PPC750? Well, first of all, the Espresso has to be fully compatible with the Broadway to run Wii software. Several people have pointed out that many PowerPC cores are essentially fully backwards compatible for user software. However, Wii games run on the bare metal, without any OS.

This means that the CPU needs to be 100% compatible at the system/OS level too, down to the smallest detail of the highly model-specific special-purpose registers. Wii software regularly messes with registers such as HID0-HID4, which are Hardware-Implementation Dependent registers. Additionally, the PPC750 line is the only range of PowerPC processors that implement Paired Singles, an (outdated) SIMD implementation that was introduced with the Gekko on the GameCube and which is not compatible with modern PowerPC SIMD, such as AltiVec.

These processors also implement other GameCube/Wii-specific features, such as the Write-Gather Pipe (used to send commands to the GX) and the locked L1 cache and DMA that were discussed in the talk. On top of that, because the Espresso runs at the clock rate of the Wii in vWii mode (and no faster), instruction timings must be identical (or possibly better) in all cases, lest some Wii games run slower on vWii mode than on a real Wii.

Now, it is true that the Espresso implements some new features - most obviously, it is a multi-core, and thus SMP, system. I am not aware of any other SMP PPC750 implementation (although that is possible with vanilla PPC750, but inefficient). However, the Espresso was clearly commissioned by Nintendo specifically for the Wii U, and they had the freedom to make significant changes to the design. Most importantly, although the individual Espresso cores are almost identical to the standard PPC750CL core, the L2 cache subsystem and bus-interface subsystem have been significantly redesigned.

The design philosophy seems to have been to keep the 750 core as untouched as possible, but graft in support for efficient SMP around it. As a result, they've tacked MERSI support onto the cores and the new L2 subsystem fully supports cache coherency between cores (and cache intervention). Incidentally, the 60x bus seems to have been upgraded as well (they call it 60xe now, and judging by the die shots, it looks wider).

In fact, the SMPization of the 750 in the Espresso is not perfect. There appears to be a bug that affects load-exclusive and store-exclusive instructions (an explicit cache flush is required), which means that using SMP Linux with them will require patching the kernel and libpthread to work around it (and possibly other software that directly uses these instructions to e.g. implement atomics).

They would've never shipped such a blatant bug on a general-purpose CPU, but I guess they called it good enough for a game console since they can just work around it in the SDK (which they do: the Cafe OS locking primitives have the workaround).

Since I mentioned MERSI and cache coherency, you may be wondering about the point in the talk where I said that the Wii U is not a cache-coherent system. In fact, the Espresso fully supports cache coherency, and there is coherency between cores.

However, as far as I can tell, the Latte does not implement this, and memory is not coherent with regards to the Starbuck and other hardware peripherals when performing DMA (although I have not verified that there really is absolutely no support - but it's at least certainly true of memory during bootrom execution, and since the Wii didn't implement coherency either, it sounds like the kind of thing Nintendo wouldn't care about).

Recently, an anonymous contributor e-mailed me what appears to be a screenshot of the introduction page of the Espresso User Manual, which seems to confirm most of what we had deduced. Please don't ask where it came from; I was only sent the screenshot and the sender used an anonymous e-mail service.

Oh, and that whole out-of-order execution debate? The confusion arose due to the myth that the PPC750 is in-order. It's a superscalar core: it does dispatch up to 3 instructions per cycle and they can complete independently (and the results are placed in a completion queue). That qualifies as out-of-order. It's not particularly wide and definitely isn't nearly as aggressively out-of-order as modern Intel and POWER cores are, though.

The Espresso is just as out-of-order as the Broadway and previous members of the 750 family. There's no upgrade there: it's a (simple) out-of-order core and it always was. Go read the PPC750CL User's Manual if you want all the gory details (it also has information on the formerly-Nintendo-proprietary stuff like Paired Singles, DMA, Locked L1, Write-Gather Pipe, etc.).


What about the GPU? RV770 snafu aside (that was just a brain fart; I meant R7xx), how do we know that it's of that family? As it turns out, the Cafe OS firmware is littered with references to the R6xx. However, the R6xx and R7xx are almost identical. ATI even published open documentation of their 3D engines together, as a single document, and the only real differences are a few details of the shaders.

The register information that we've looked up does mostly match the published open docs. R7xx is clearly a minor evolution of the R6xx. Cafe OS also has references to "GPU7", which seems to be another name that Nintendo uses for the GX2. With the R7xx available (and as, essentially, a mostly compatible step up), there would be no reason for Nintendo not to go with the R7xx as a base instead of the R6xx.

Together, all of these strongly imply that the GPU is indeed an R7xx core and not an R6xx core. To those claiming that it supports newer features (e.g. I've heard Tesselation and Stream Out support listed as "evidence" of a newer core): go read the 3D engine doc linked above. Those features were already there on R6xx/7xx.

Now, the Latte is a fully custom SoC that has nothing to do with any particular member of the R7xx family, so there is no easy way to draw a parallel to any particular released AMD GPU. Maybe the specs (shader count, etc.) match an existing AMD chip, or maybe they don't. We're not particularly interested in the GPU prowess wars, so we haven't poked at the GPU to try to figure out its specs.

Clock frequencies

This one's easy: the clock speeds that I tweeted (CPU 1.243125GHz, GPU 549.999755MHz) came straight from the Cafe OS system log. The Espresso doesn't support dynamic clock scaling (it only has one PLL and it is configured via external pins and only reconfigures itself on hardware reset), and I haven't seen any evidence of them using power saving / clock scaling on the GPU. Both clocks rates are what you'd expect for a modern relayout of the 750 core on a 45nm process, and a power-savey R7xx at 40nm.

The talk about clockspeeds being raised with a software upgrade is nonsense. I have no idea where that silly rumour came from, but there's no truth to it. While it is possible for the clocks to be reconfigured in software (like on most modern systems - and this is used for vWii mode), it would make no sense for Nintendo to test and ship a living room system at one clock speed and then later raise it (this only makes sense on portable systems, where cores are often underclocked to save battery, but tested at higher clock speeds). It certainly hasn't happened on the Wii U.

vWii mode

vWii mode is actually pretty interesting, because different parts of the backwards compatibility are implemented in different ways. Some of it is pretty obvious (e.g. the RAM controller is reconfigured and only 64MB of RAM are visible as MEM2), but some parts are much more interesting. Hover over the block diagram above and see if you can spot the interesting ones!


Why is the GX a separate block and not a compatibility mode of the GX2? To be fair, I don't have hard evidence that they do not share absolutely any hardware, but this goes back to common sense. The GX is completely different from the GX2/R7xx. Adapting the R7xx to look like a GX and be fully compatible at the register level (remember, Wii games run on bare metal) is a humongous task, and completely unrealistic to do and validate. If they were to do it that way, you'd expect some kind of complex configuration, perhaps involving firmware or special shaders, to switch to vWii mode - none of which is present in cafe2wii.

Meanwhile, the process node upgrade means that they can easily fit in the entire GX. On the Hollywood, the 3MB of 1T-SRAM took up half of the die. On the Latte, they're just two small blocks in the corner (and one of them is even SRAM now). They could easily fit in the rest of the Hollywood in the remaining logic area above the big MEM1 block, and have the entire right hand half of the die left for the R7xx and the new SoC peripherals.

Instead of the impractical task of implementing perfect hardware emulation on a completely different GPU architecture, they did the easy thing: throw the old hardware in there, and reuse the easy bits (TMEM and EFB) as handy MEM0 memory in Wii U mode. MEM0 is even mapped at the same address where the direct EFB access used to be on the GC and the Wii, so it probably is the same hardware, with the pixel format mapping turned off and instead presenting the memory as flat RAM. In Wii U mode, it is used mainly for the Cafe OS kernel.


You may have noticed that good old VI (the display controller / Video Interface of ye olde GameCube and Wii) is gone. Huh? How does that work? Turns out they're emulating that in software and translating its configuration to the R7xx's CRTC registers. But where does this emulation software run? Sneaky: they added a special microcontroller to the Latte just for this purpose.

The DMCU is a 68HC11 compatible 8-bit CPU whose sole purpose is to perform VI emulation. It has a frontend hardware shim that looks like VI to the Wii software, and behind the scenes it translates those registers to the Radeon's, including upscaling configuration. cafe2wii loads the DMCU's firmware (the DMCU doesn't seem to be active in Wii U mode).

It has its own dedicated RAM and access to both the faux-VI back side and the Radeon's register area. There is also a little mailbox to talk to it from vWii mode: the System Menu and IOS use this to configure the 4:3 stretch mode for Virtual Console games (which is why The Homebrew Channel accidentally ends up in the wrong mode: after a recent update, the System Menu thinks it's a Virtual Console title due to its title ID starting with 'L' and sets up that special mode). Presumably it also got an update when gamepad support for vWii showed up, though I haven't looked at the firmware again since then.

Font ROM

The GC had a few bitmap fonts in its firmware ROM, for use by the BIOS / firmware and by games. This ROM was an external chip connected to the EXI (SPI-like) bus (actually the same chip as the RTC). The Wii got rid of the firmware part, but had to keep the fonts for backwards compatibility (and they were still in there in the RTC). The Wii U finally gets rid of the ROM, but Wii games might still use the fonts. What to do? Easy: they have an extra 8MB of MEM1 sitting around doing nothing in vWii mode. cafe2wii actually loads the old fonts into this area, and then presumably there's a shim in front of the EXI hardware in the Latte that pulls the ROM data from there.


The GC had a proprietary disc drive bus called DI. The Wii kept it, with minor changes. However, the Wii U finally switched to a more modern SATA port. The SATA peripheral is actually bog-standard AHCI to the Wii U software. However, vWii mode needs to talk to good old proprietary DI mode. How is this implemented? This one seems to be pure backwards compatibility hardware. cafe2wii turns on a DI compatibility mode in the AHCI controller.

Presumably that enables the old DI registers and either funnels the old commands through SATA (which the drive then supports) or also translates commands (though the drive still needs to implement them - for example, the GC/Wii support reading on arbitrary 4-byte boundaries, not aligned with sectors, so the new drive must support that too).


The Wii U has a different WLAN chipset. How could they possibly emulate an older Broadcom chipset in vWii mode (eeew, Broadcom)? They don't. vWii IOS contains a totally new WLAN driver. This one leaks straight into the vWii sandbox and there's no backwards compatibility. They can get away with it because (thankfully!) the WLAN driver is entirely contained in IOS, and IOS is also the sole manager of WLAN configuration (well, and the System Menu, but those settings are configured from Wii U mode on a Wii U), so games don't know or care that it's all different. On the plus side, that means that vWii mode should support 802.11n.


The Wii U has 4 USB ports. The Wii had 2. How does this work? No, it's not a built-in hub. Actually, the OHCI/EHCI controllers have registers that indicate the number of available ports, and the old drivers are perfectly happy with 4 ports instead of 2. This also goes for GhettOHCI: I wasn't sure what to expect, but thankfully I didn't hardcode the number of ports, and it Just Worked on the Wii U, reporting 4 ports instead of 2.


Everyone knows that vWii mode has the same old NAND flash storage as always, a dedicated 512MB of NAND just like on the old Wii, on a dedicated NAND Flash chip, containing the same old filesystem (but not boot1 or boot2, since they don't need those in vWii mode, as cafe2wii boots it straight into IOS). What most people don't know is that the "dedicated" part is a lie: Cafe OS also boots from and uses SLC NAND flash in addition to the 8GB or 32GB of eMMC storage. But there's only one NAND flash chip. Is there?

Kind of: there's one NAND flash chip, but it has two NAND flash dies inside: 2x512MB, one for vWii mode, one for Wii U mode. There's a separate chip enable pin for each. This is actually a pretty common arrangement for a NAND flash chip, though using each bank for a totally different OS is cute. This was confusing to figure out at first because the Samsung NAND flash datasheet for this part also applies to the single-bank 512MB version and others, and it is rather unclear about the specific layout of each particular part number (even iFixit got it wrong and listed it as 512MB, while in fact the specific part used is 1GB - or 8Gbit, hence the "08" in K9K8G08U1D).


It is not shown in the block diagram above (because I ran out of space and I skipped miscellaneous hardware connected to GPIOs), but the Wii had a small serial EEPROM die built into the Hollywood multi-chip package (for mild security) and connected to some GPIOs. It was used to store the console's certificate signature (signed by Nintendo, which cryptographically certifies the console as a real Wii), a few miscellaneous things (like the boot2 version number and the random number generator nonce counter), and, on Korean Wiis, the new Korean common key.

The Wii U still has a SEEPROM, but its contents have nothing to do with vWii mode. The old certificate data is actually in a new OTP memory bank on the Wii U, and cafe2wii just reads this and throws it at the end of the Starbuck's SRAM where there was some free space. Then they hacked up vWii IOS to read the data from there instead of the real SEEPROM.

Keys, keys, keys

The Wii U has lots of keys: its OTP is 8 times the size of the Wii OTP (1KB in 8 banks of 128 bytes, instead of a single bank of 128 bytes). Incidentally, bank 0 is the vWii bank (and all the other banks are disabled in vWii mode, so it only gets to see the keys that it needs, which are the same ones that were present on Wiis). We posted SHA-1 hashes of a few of the important keys in the presentation slides, but here's a more detailed description of what they are used for:

Espresso vWii ancast key (11 days)


Found in the Espresso's key fuses/OTP. Used to decrypt the vWii System Menu and the new NANDloader binaries (1-512 and 1-513) at load time. Disabled by the boot ROM until reset.

Espresso Wii U ancast key (11 days)


Found in the Espresso's key fuses/OTP. Used to decrypt the Cafe OS kernel at load time. Disabled by the boot ROM until reset.

Note that the previous two hashes are contained in this file, and it is the SHA-1 hash of that file that we posted on the 11th day.

Wii U common key (30 days)


Found in the Starbuck's OTP. Used to decrypt the specific title key for every Wii U application (this is done at installation time for system firmware and installable titles, and at load time for disc games). Note that Cafe OS and Starbuck binaries are double-encrypted with their own ancast keys too.

vWii common key (30 days)


Found in the Starbuck's OTP. Used to decrypt the specific title key for vWii system updates (since the key is only needed at installation time, vWii mode doesn't actually have access to it). Note that the System Menu and NANDloaders are double-encrypted with the vWii ancast key too.

Wii U ancast key (Clarification)


Found in the Starbuck's OTP. Used to decrypt Starbuck binaries (Wii U IOS and cafe2wii). Unlike the Espresso keys, this one is enabled forever (except in vWii mode, of course), as the Starbuck boot0 really only runs at boot time, and Starbuck ancast binaries are simply parsed and decrypted by IOS itself when reloading.

Wii U boot1 key (not yet!)

Found in the Starbuck's OTP. Used by boot0 to decrypt boot1. This key, and it alone, is selectively disabled in a special clear-only OTP mask register by boot0, and is not available after boot. We don't have it yet, but we're trying to get it with some cute side-channel attacks.

A few people have claimed that our work doesn't qualify as having hacked the Wii U since we do not have this key yet. That doesn't make any sense, though: We have full code execution in kernel mode in both the Espresso and the Starbuck, access to every other key (including the aforementioned ones as well as per-console storage encryption keys and the like), unrestricted access to Wii U mode hardware, etc.

Stating that we haven't hacked the Wii U because we don't have the boot1 key is like saying that nobody has ever hacked any iPhone because nobody has ever extracted the GID Key. Either way, there's a good chance we might be able to fish it out soon .


That's all for now! If you have any other technical questions, feel free to give us a shout in the comments and we'll try to answer them if we can.

#27 - PS4 News - December 14, 2013 // 2:20 pm
PS4 News's Avatar
Here is some updated news on the Nintendo Wii-U hacking from Wii-U scene profiteers Max Louarn and GaryOPA (aka Gary Wayne Bowser) alongside marcan42, as follows:

Coming Soon to a Wii-U Near U

What is it? Wait and see

Four Horseman Set Sights On Wii-U

Yep, it is finally upon us, but lucky for us humans the Apocalypse is happening to just Nintendo

A year in making, the rumors claim, but end is in sight for the Nintendo Wii U, as the Four Horsemen have been enlisted to bring the second coming to Nintendo in the form of Homebrew finally for Wii U.

BannerBomb Version 2, the Second Coming is happening for Nintendo on its latest flagship next-gen console the Wii U, roughly a year after its launch, it seems four unknown well at least this time around they are hiding their online nicks from the big 'N' band of happy pitchfork lawyers, and coming together as the Four Horsemen, along with secret hand-picked group of five beta testers, one of whom seem to have loose lips and sent off some 'anon' emails with teasers to a 'scene site' as such the Four Horsemen have quickly gather up their gear, and rumored to be sending their fury off to video camera to prove the the world the second coming is happening to Nintendo and it might be as early as this Wednesday we see a release to make sure the big 'N' does not patch this 128x128 graphical overflow exploit that been uncovered which the rumor claims of 'Hello World' has already been done.

So stay tuned to this channel as time is ticking fast, and this U Bomb by the Four Horsemen is just around the corner.

Update: Below is another picture attached and videos, as follows:

Four Horsemen Deliver The Video

Showed a Wiiu Brew icon on both the main display and the gamepad, they pressed the icon on the game pad then a WiiU Brew Screen (similar to the Wii screen when you launch the Wii) then the video faded out.

So the did manage to install something on the Wii U and launch it. What it actually does, no one knows but it does lend some credence to their claims that they've hacked the Wii U.

#26 - PS4 News - June 1, 2013 // 9:17 pm
PS4 News's Avatar
(Proof of Concept) GameCube games in vWii on Wii U

First of all no this isn't DIOS MIOS because that would never work.

This is written pretty much from scratch and there are still many issues especially with the sound that's why I overlayed a nice music track.

There is obviously no way to use a GC controller on a Wii U and getting wiimotes/CC to work is way too complicated, so what I am using here is a PS3 controller connected via USB.

The Mega Man 10 channel is just my lazy way of loading sneek, don't need any fancy banners

HyperDuck SoundWorks - Hoy, Small Fry!

Wii U Dev Console Photos

From assbasket (via I bought a used wii u from an online ad in San Francisco just a few days ago. Met up in a public place with an outlet so I knew it worked before I paid.

I was told I'd need to connect to the internet and update it before it would play games.

I might have screwed up before I got that far, but it's a rare piece of gear and I'm not really worried. Minorly frustrated maybe.

Pictures are included below. It has a green face plate like the wii dev unit did. The controller has a boxy bit sticking out of the middle top edge.

I tried booting NSMBWu and it won't recognize the disc.

I clicked something called DEVMENU but it wouldn't let me get back out of it.

That was when I had a 1080p HDTV to test it on.

Now I'm at home with only a 720p and it doesn't seem to give a signal to that tv.

Looking for help online. Internet hasn't been much help.

I've hammered search engines and searched this forum and lots of others looking for help, reference, images, anything. There doesn't seem to be any available public information about this. At least not yet anyway.

I spoke with a guy who said he'd helped test a sega title for wiiu, he said the menu looks very old. TVii? He may be right.

I'll keep messing with it whenever I can get my hands on a 1080p monitor, tv, screen, whatever. But my current tv isn't showing me the DEVMENU screen in the pic below, so I'm stuck for tonight.

#25 - PS4 News - May 2, 2013 // 7:48 am
PS4 News's Avatar
Another brief Wii-U related 29C3 update from fail0verflow (via below:

Never underestimate the power of one guy with 29 guys cheering him on:

30 Days and a Congress

Brought to you by 30 hackers and 3 tables:


Update: The first WiiU dumps have also been spotted in the wild, as follows: The_Avengers_Battle_for_Earth_PAL_WiiU-VENOM / The Avengers Battle for Earth PAL WiiU VENOM (via Max Louarn and GaryOPA aka Gary Wayne Bowser)

Game Title ID: 02 7C 95 57 64 8A 1A 99 9A A7 84 83 19 BB 5E F2

[Register or Login to view code]

This dump weighs in at a hefty 23.256GB, and what’s extra interesting is the AES key that is included in the read me.

From Fail0verFlow's blog (via to quote:

The future of console homebrew (and a shot of Espresso) by marcan

It’s been almost 7 years since the Wii was released. Back in 2006, not many owned a living room PC. PCs were still relatively bulky, and the Chinese offerings were limited to horrible media players. At the time, the prospect of having a game console double as a HTPC and being able to browse the web, play games for older platforms with emulation, and run homebrew games on a device which you already had in the living room was rather appealing.

Fast forward to today. Mobile SoCs have made huge advances - you can get a quad-core chip in a phone these days - and have made the jump to the living room. Spend $25 and you can get a Raspberry Pi, which is about on par with the Wii at 1/10 of the launch price and 1/7th of the power consumption (with HD video). Spend $100 and you can get an Ouya, which beats the Wii U’s CPU and doesn’t have too shabby graphics at one third the cost.

These mobile-derived devices aren’t quite a replacement for game consoles yet, but they’re catching up fast. They’re cheap enough that they’re almost disposable. The software ecosystem is much larger and wider than any console has ever had. More importantly, they’re open, and the development tools and environments are way better for open development than any game console ever was.

The Wii U isn’t a particularly interesting device. It has the same old Wii CPU, times three. The GPU is a standard, and somewhat outdated Radeon core. The peripheral hardware is standard - SD, USB, SATA, WiFi, etc. The Wii hardware has been either kept as-is or replaced with compatibility shims. The only interesting bit is the controller, but there is already significant work underway to be able to use it with a PC (all you need is a wireless card capable of 5GHz 802.11n AP mode and special software). Even on the Wii U itself, the gamepad is managed by an independent Broadcom SoC that has its own firmware and communicates with the rest of the system via bog-standard USB and one of the video output heads on the Radeon.

The same goes, by the way, for the Xbox Durango and the Playstation Orbis. They’re both glorified PCs. With Valve’s Steam Box coming up, there will be little advantage to either of the first consoles other than potentially new input devices and exclusive games. And the Steam Box will almost certainly be hackable with trivial to no effort.

So where does that leave us? When the Wii U came out, our hacker instincts kicked in and we started looking into ways of breaking into the hardware. A few days before launch we had a firmware update scraper going. Over the next 30 days, we reached most of the milestones required to be able to say that we hacked the device; without going into details, there is basically no security left to break into, other than a mostly unimportant step of the boot process.

What would remain is the tedious work of developing the open frameworks required to bootstrap a homebrew community, documenting everything, reverse engineering all of the new hardware, developing a persistent exploit (think tethered vs. untethered iPhone jailbreak, except without any extra hardware or cables), and packaging it all up.

Over the next few months, interest faded. I took a break to work on other projects. There wasn’t much of a reaction from the Wii homebrew community. Is it really worth going through all that effort when we already have open devices that are affordable and widely available? About 31 trustworthy people, most of them well-known people in the homebrew community, have access to what we developed, yet nobody stepped up to start working on a homebrew platform for the Wii U.

At the same time, there is an eternal clash between the homebrew community and those interested in pirating games. Writing homebrew software and frameworks is rather difficult - it requires new code to be written to support the hardware, which must be reverse engineered first. Convincing a game console to load copied games is comparatively simpler, as only the bare minimum amount of code patches required to convince the game/OS to load the game from alternate storage media are required.

For example, on the PS3, the kernel payload of the first game loaders was a tiny system call patch, and I wrote an (unreleased) Wii USB loader using existing homebrew frameworks in a couple hundred lines of code, as a proof of concept. Every console after the PS2 was initially broken to run open homebrew code, and only later did piracy show up (excluding disc-drive-based hacks, which I consider a different category).

I think we may have reached the point where homebrew on closed game consoles is no longer appealing. The effort required to develop and maintain an environment for a big, complex modern game console is huge. The cat and mouse game with the manufacturer requires ongoing effort. There is a very real threat of litigation. Game pirates would become not just big users of the result of those efforts, but by far the overwhelming majority (not because there are more pirates, but because there are fewer homebrewers). The fact that the Wii U isn’t selling nearly as well as the Wii did doesn’t help drive enthusiasm either.

I could be wrong, of course. Maybe it’s just that I have a full-time job now and less of a chance to spend all-nighters staring at assembly code. Maybe there are tons of prospective Wii U homebrew developers quietly waiting in the sidelines for a release. Maybe we’ve just gotten lazy.

We could just release everything as-is, of course. However, we tried that with the PS3, and the results were not only disappointing, but we actually ended up in an undeserved legal mess. Homebrew for the PS3 is basically nonexistent, and all anyone cares about is piracy. This is not a situation which we want to see happen again.

So, instead, we can go for a compromise. Our original idea for Wii U homebrew was to “escape” from the Wii mode sandbox and enable the new Wii U hardware. This appeared possible initially, but unfortunately, it turned out that a few critical hardware registers were irreversibly disabled in Wii mode. However, due to the design of the Wii U’s architecture, a few things can be re-enabled. One of those is the multicore support of the Espresso CPU.

On the Wii, the Broadway CPU had no built-in security: games ran on the bare metal and the Starlet handled all security. The Starlet was responsible for kickstarting the Broadway and feeding it code to run. The Wii U extends this architecture by putting some extra security inside the Espresso CPU: now, the Espresso has its own secure boot ROM, like the Starbuck, and will only boot a signed and encrypted code package. This package (which we call an ancast image) is delivered by the Starbuck and verified and decrypted when the Espresso is reset.

This happens in Wii mode too. However, Wii mode software knows nothing of this mechanism. Nintendo worked around this by transparently replacing the NANDloader (which is usually the first code that runs on the Broadway when it boots) with a modified version, encrypted and signed using the new format. The Starbuck (running vWii IOS) loads the new NANDLoader to RAM as it normally would, but when the Espresso is reset, it instead runs its boot ROM.

The ROM decrypts the NANDLoader in-place and verifies it against its hardcoded ECDSA public key. If the verification succeeds, it jumps to its entrypoint. The very first thing that the NANDLoader does is turn off the Espresso features and put it into Wii compatibility mode. The new NANDLoader is stored in dedicated vWii mode titles 1-200 and 1-201 (there are two variants, but 1-200 is equivalent to the “normal” NANDLoader).

Incidentally, for vWii mode, we made a minor tweak to HBC so that its binary can both be loaded standalone as was the case on the Wii, and also works together with a NANDloader - this means we can use the same binary for both platforms, and we don’t have to ship a separate NANDloader that would be replaced in vWii mode.

Thankfully, even though the Espresso has ROM security now, unlike the Starlet/Starbuck, it has no memory firewall or similar protection (i.e. AHBPROT). This means that we are free to mess with the contents of memory while the Espresso boots. We can perform a completely trivial and reliable race attack and gain control before the NANDloader has a chance to disable anything. Here’s how. You will have to be able to run code on the Starlet: you can either use Mini or hotpatch IOS using the AHBPROT feature of HBC.

Load the NANDloader to RAM (it is a standard DOL binary and should be loaded as indicated in its header). Note that you’ll have to gain access to 1-200 or 1-201 for this. Don’t bundle it in your app; that would not be redistributable and wrong. Instead, read it from NAND directly (mini), or patch IOS to let you access it, or use the existing title boot functionality in IOS (that already loads the NANDloader from 1-200) and just patch the part where the PPC is reset (see below).

Perform the standard PowerPC reset sequence (this is Mini code, see hollywood.h for the constants):

[Register or Login to view code]

Note that it is not necessary to load any EXI bootstrap code, as the Espresso always boots from ROM.

Immediately start watching memory location 0x1330100 (0x81330100). Make sure to either use an uncached mapping or invalidate the cache every time. You may need to perform an ahb_flush_from(AHB_1) every time to make sure the AHB buffers don’t bite you. Look for a change in the data at that address: it is the first instruction of the NANDloader, and the ROM will start decrypting there. Verification happens simultaneously with decryption.

Replace the (now decrypted) instruction at that address with a jump to your own PowerPC code. Make sure to flush if not using an uncached mapping. The timing is pretty lenient here; the ROM is busy decrypting and verifying the rest of the NANDloader at this point, so you have plenty of time to detect and swap the instruction before the ROM jumps to it.

[Register or Login to view code]

To be able to use the extra cores, you will have to initialize them. There are also a number of settings related to the bus and memory coherency. Some of these may not be applicable to Wii mode, so you will have to experiment. These are the important steps (in pseudo-C), reverse engineered from the early initialization code of the Cafe OS (Wii U mode) kernel (this runs initially for core0, and then every other core also runs this code as it is bootstrapped):

[Register or Login to view code]

Note that cores 1 and 2 will start at the system reset vector, which should jump to code equivalent to the above. It is currently unclear what controls whether the cores end up with MSR[IP]=1 (high vectors) or MSR[IP]=0 (low vectors), but I’m pretty sure that at least in Wii mode you end up booting with IP=0 by default (vector 0x100 in MEM1), although one of the above settings might change that. Experiment. Just flipping the two boot bits in SCR is enough to get the two other cores up without doing anything else, although coherency will probably be broken/disabled. Also, keep in mind that this trick gets you access to all 3 cores but they still run at the old Wii speed (729MHz). Speeding up the Espresso probably requires full access to Wii U mode.

The important SPRs are these:

[Register or Login to view code]

So what can you do with this? Well, libogc is probably near impossible to turn into an SMP-capable scheduler (and there are so many other problems with it that trying to keep using it for Wii U mode would be a terrible plan). However, it should be possible to port Linux to have tri-core support on the Wii U. It might also be possible to use the two extra cores in libogc apps purely for number crunching, with carefully designed locking (outside of libogc) and without calling any libogc functions from the other two cores (or any non-reentrant libc functions).

Personally, I’d like to see a Linux port taking advantage of this (using Linux was my initial goal in Wii U mode, though I never got around to starting the port). Linux is the ideal choice for Wii U mode, as it has native drivers for most of the remaining hardware, and most importantly, it should be a lot easier to port the existing open source Radeon drivers to work on the Latte than to write one from scratch. The Wii U has tons of RAM, unlike the Wii, and natively runs a multitasking OS with paging and memory protection anyway, so there’s little advantage to not just using Linux.

Getting multicore support into some kind of homebrew platform is one of the many steps required to get to a Wii U homebrew ecosystem, so consider this a test to gauge the interest of the homebrew community. If there ends up being significant interest and progress is made, we will reconsider working towards a Wii U-mode homebrew ecosystem (or perhaps just pass on what we have to those who are more motivated than we are).

One final note: on the Espresso, the exclusive load and store instructions (lwarx and stwcx) are subtly broken and need a workaround. If you are seriously interested in this, and you have started working on it, ping me on IRC and I’ll let you know about the specific workaround that is required (I’m just too lazy to write it all out right now) and also gladly answer any other questions.

Finally, from IRC:

[Register or Login to view code]

Update: To clarify, this only yields access to the extra cores, not the extra RAM and the rest of the hardware. For that, you’ll need a Wii U mode exploit. We do have such an exploit, but right now I believe that, if it were released, there wouldn’t be enough developer interest to kickstart a healthy homebrew ecosystem; if e.g. a Linux port to vWii-mode Espresso is developed, I will gladly stand corrected (and such a Linux port would be directly applicable to Wii U mode, modulo a few minor memory mapping differences, so it’s not wasted effort).

I think it's apparent that he is trying to drum up interest or see who, if anybody, is interested in this work. So far it seems as if only end users are showing interest.

#24 - sacredshinobi - December 21, 2012 // 11:12 pm
sacredshinobi's Avatar
All this new info makes me happy to be a nintendo gamer

#23 - PS4 News - December 18, 2012 // 6:43 pm
PS4 News's Avatar
Below is a guide on how to get Nintendo Wii game backups working on the Wii U (via , as follows:

How to Get Nintendo Wii Backups Working on the Wii U Guide

CAUTION! Read these instructions carefully, at least twice before proceeding. Never mix and match Wii and Wii U WAD files. The two are separate things. Failure to follow instructions or warnings may result in brick. Following this tutorial may result in voiding your system warranty. This Web site and its authors are NOT resposible for any damage or loss that may occur by following this tutorial.

Step #1: Follow the .Wad Manager Tutorial if you haven't already done so. (If you've run it before and are having problems getting backups working after this tutorial, follow that tutorial again and start this one from the beginning.)

Step #2 (optional): Backup your Wii Mode NAND.

Step #3: Download D2X cIOS Installer 2.2 ( and ( You should have a folder 'd2x-v10-beta53-alt-vWii' in the d2x cios installer v2.2 folder. So it should look something like this: /apps/d2x cIOS Installer 2.2/d2x-v10-beta53-alt-vWii. Also download the latest version of WiiFlow (

Step #4: Extract the D2x cIOS 2.2 installer first. Move to the APPS folder on your SD card. Then extract and move the files to the D2X Installer folder in your \apps\ Extract the latest version of WiiFlow to your \apps\ folder too

Step #5: You need the following THREE files in the root of your SD card:

  • IOS56-64-v5918.wad
  • IOS57-64-v6175.wad
  • IOS58-64-v6432.wad

How to get them:

  • Download Bluedump 0.3 ( and extract the files to folder titled Bluedump 0.4a
  • Rename bluedump-alpha04.dol to boot.dol and place it in a folder titled Bluedump 0.4a in your /apps/ folder of your SD card (You should have /apps/Bluedump 0.4a/boot.dol)
  • Launch BlueDump via HBC. With the arrow on "00000001 - SYSTEM TITLES" Press the A Button. Using the D-PAD press DOWN until you are on the desired system title and then press the '1? Button on your Wii Mote. Using the D-PAD change the bracket selection to "Save as WAD" and press the A button, press A Button again for "Save to SD".
  • Go to the \BlueDump\WAD\ folder on your SD. Rename the 56, 57, 58 WADs according to the filenames: IOS56-64-v5918.wad, IOS57-64-v6175.wad, and IOS58-64-v6432.wad Move them to the ROOT of your SD card.

Step #6: Boot into Wii Mode, launch HBC, and from there launch d2x cios installer. Press A to get past the intro screen, and press A again when prompted about selecting IOS 236.

Step #7: You should now be at the INSTALLATION PROCESS screen. There should be an arrow under SETTINGS on "Select Cios".

  • Using the D-PAD press RIGHT until you can see "d2x-v10-beta53-alt.vWii" in the "Select cIOS" brackets. Once that is selected, press DOWN on the DPAD, moving the arrow to "Select cIOS base". Press RIGHT until "56? is in the brackets. (leave "Select cIOS slot" at "249?) With "d2x-v10-beta53-alt.vWii" under "Select cIOS" and "Select cIOS base" on "56? Press A.
  • Once it installs press A to continue. Now change the "Select cIOS base" to "57? and Press A, then Press A again to continue.
  • Now finally change the "Select cIOS" base to "58? and Press A then press B to quit once the installation successfully completes.

Step #8: Return to HBC, plug in your USB device to the Wii U's back upper-most USB port, launch WiiFlow and enjoy playing Wii Backups on your Wii U!

That's it! You should now be able to launch WiiFlow and load Wii Backups. (NOTE: as of the time of this writing USBLoader GX does not appear to work, future updates should fix this)

A special thanks to bubba for his contributions to this tutorial.