Despite all of the anti-reverse-engineering tricks we put into our last installment of the HackMii Installer, Nintendo managed to find the IOS exploit we used to install The Homebrew Channel and fix it sometime within the last two years. There never was a Wii system update for this, the fixed IOS versions can only be found on a Wii U.
They also blocked our old title ID. Consequently, we have a new release with a new version of The Homebrew Channel; this will install on both Wii consoles, and inside the virtual Wii sandbox inside the Wii U. The currently used IOS exploit is courtesy of tueidj.
Please note that this is not running in full Wii U mode; running this on a Wii U will probably work just like on a Wii. (See if you can find any differences, we can all try to hack the Wii U together from inside Wii mode!)
Also, due to technical limitations of the virtual Wii mode, BootMii will not work on a Wii U. If we are able to resolve this, we will make a new release with BootMii support.
As usual, grab the new installer here (linked above). If you’re unsure what do to with the installer, see this wiki page (wiibrew.org/wiki/Homebrew_setup) for a general tutorial on how to setup homebrew on your Wii, and this one at the brand new wiiubrew.org for savegame exploits that still work on a Wii U.
How to install .WAD files in WiiMode on your Wii U (via wiiuhax.com/wiiuhax-com-tutorial-how-to-install-wad-files-in-wiimode-on-your-wii-u/)
WHAT YOU NEED:
(A) 1 or 2GB SD card FAT32 formatted
(B) boot.elf from [Register or Login to view links] in the root of your SD Card
(C) Smash stack hack (wiiubrew.org/wiki/Smash_Stack) files on your SD (link)
(D) MMM in your \apps\ folder
(E) [Register or Login to view links] folder in your \apps\ directory
(F) [Register or Login to view links] file in your SD root
(G) Your other desired *.WAD (games, emus) in \WAD\ on your SD CARD
* IMPORTANT: Do NOT insert your SD card before STEP #3 below *
WHAT TO DO:
#1 Power on your Wii U, insert SSBB disc and launch Wii Mode.
#2 Once in Wii mode launch the Wii Disc Channel
#3 When the health warnings appear, insert your SD card
#4 Navigate in the menu to VAULT, and select STAGE BUILDER.
#5 Follow the instructions on screen and select INSTALL HOMEBREW CHANNEL.
#6 Launch IOS236 Installer MOD v6 Special vWii Edition from HBC
#7 Launch MMM, press the LEFT direction once on the DPAD, and then navigate to “236″ and press A.
#8 Install your favorite WADs
Credit: bubba (big thanks for walking me through all the steps!), damysteryman (modified IOS236 installer for use on Wii U vWii)
I have now updated the main article with the latest teaser from fail0verflow (via fail0verflow.com/blog/2012/8days.html) as follows:
8 Days: 3d331b3165f9638c6cd6221702b2f736f7fcf931
From marcan42: Pro tip: 40 character hex strings are usually SHA1 hashes, not encryption keys.
Update: Another brief update from fail0verflow (via twitter.com/fail0verflow/status/281164792000045057) of a picture showing output to the Wii U's control pad with their logo and a picture of Nintendo of America President and COO Reggie Fils-Aime with the caption:
"The Wii U is a system we can all enjoy together" - Reggie Fils-Aime (twitter.yfrog.com/gymu6fjp)
How to Get Nintendo Wii Game Backups Working on the Wii U Guide
Below is a guide on how to get Nintendo Wii game backups working on the Wii U (via wiiuhax.com/wiiuhax-com-tutorial-how-to-get-wii-backups-working-on-the-wii-u-step-by-step-noob-friendly/) , 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 (d2x-cios-installer.googlecode.com/files/d2x%20cIOS%20Installer%20v2.2.rar) and d2x-v10-beta53-alt-vWii.zip (d2x-cios.googlecode.com/files/d2x-v10-beta53-alt-vWii.zip) 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 (code.google.com/p/wiiflow/downloads/list).
Step #4: Extract the D2x cIOS 2.2 installer first. Move to the APPS folder on your SD card. Then extract and move the d2x-v10-beta53-alt.vWii.zip 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:
How to get them:
Download Bluedump 0.3 (bluedump.googlecode.com/svn/trunk/HBC/BlueDump%20Alpha%203/boot.dol) 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.
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
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 fail0verflow.com/blog/2013/espresso.html) 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):
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.
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):
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.
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.
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.
(Proof of Concept) GameCube games in vWii on Wii U
(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 gbatemp.net/threads/wii-u-developer-console-wont-boot-retail-disc-pics-help.358882/): 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.
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.
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!
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.
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 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.
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.
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.
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:
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:
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..