Sponsored Links

Sponsored Links

Nintendo Wii U Miiverse Debug Menu Uncovered on Launch Day


Sponsored Links
96w ago - 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 [Register or Login to view links] 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 ([Register or Login to view links]) 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 (twitter.com/NintendoAmerica/status/270333253729271808) 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.





[Register or Login to view links] 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, [Register or Login to view links] has leaked the WiiMode Keys and shared some [Register or Login to view links] for those interested!

Update: Nintendo officially stated the following to [Register or Login to view links] 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.”








Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

Comments 32 Comments - Go to Forum Thread »

• Please Register at PS3News.com or Login to make comments on Site News articles. Thanks!

PS3 News's Avatar
#32 - PS3 News - 5w ago
Below is a video of Unbuntu successfully running on Nintendo Wii U vWii from TeamScriptKiddies / Ninja_Carver (via gbatemp.net/threads/vwii-tri-core-linux.351024/page-18#post-5071853) as follows:

[Register or Login to view links] (trinux-0.5a.7z) - write to sd card using dd or Win32DiskImager
[Register or Login to view links] (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:

  • WiiU with Homebrew channel installed in Wii Mode.
  • A 2GB SD Card
  • BootMii IOS 254 [Register or Login to view links]
  • The Trinux archive from [Register or Login to view links] (trinux-0.5a.7z)
  • USB Keyboard (the older the better, it seems)
  • (optional) a USB LAN adapter, if you wish to use the Internet.

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





I RECOMMEND MANUALLY WRITING THE IMAGE TO YOUR SD CARD.

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: [Register or Login to view links]

[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: [Register or Login to view links] (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: [Register or Login to view links]

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.

PS3 News's Avatar
#31 - PS3 News - 7w ago
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.

PS3 News's Avatar
#30 - PS3 News - 7w ago
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: [Register or Login to view links] / [Register or Login to view links] / [Register or Login to view links] (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 README.md 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 192.168.1.4, which it currently is). Build rpc.c and it will go in your htdocs.

Next, start rpc.py in an interactive Python session (IDLE or IPython is a good choice). Once you've started rpc.py, 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

Credits

  • 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/3.0.3.12.12 NintendoBrowser/3.0.0.9561.EU

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

PS3 News's Avatar
#29 - PS3 News - 30w ago
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

MORE TO FOLLOW

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 blog.delroth.net/2014/02/wii-u-bootrom-dumped-what-it-means-in-practice/)

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 devram0.blogspot.com/2014/03/aes-obfuscation-on-wii-u-bootrom.html):

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

PS3 News's Avatar
#28 - PS3 News - 38w ago
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.

  • wtf.muling.lu/30c3/Saal_2/Day_1/5290-30C3_-_5290_-_en_-_saal_2_-_201312272030_-_console_hacking_2013_-_sven_-_marcan_-_nicholas_allegra_comex.webm
  • fail0verflow.com/media/30c3-slides/#/
  • twitter.com/fail0verflow

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 libdrc.org. 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: [Register or Login to view links]

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 (fail0verflow.com/blog/2014/console-hacking-2013-omake.html), 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.

Espresso

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.).

Latte

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!

GX

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.

DMCU

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.

DI

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).

WLAN

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.

USB

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.

NAND

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).

SEEPROM

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)

ce3641b2660253f5a7e789db297be2c1585b3054

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)

2ba6f692ddbf0b3cd267e9374fa7dd849e80f8ab

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)

6a0b87fc98b306ae3366f0e0a88d0b06a2813313

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)

2b30b703c6676c8124c7347b30c7972ffeae2b39

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)

d8b4970a7ed12e1002a0c4bf89bee171740d268b

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 .

EOF

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.

Sponsored Links

Sponsored Links
Sponsored Links

Sponsored Links







Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News