Wii U Browser Exploit Released for v5.0.0 and v5.1.0
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!
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.
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
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)
Navigate to the root of the repository in the shell. Then enter the following command at the command line:
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.
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
Teaser Image of New Homebrew App/Utility for Wii U
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 MarioNumber1updated 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.
Video: Unbuntu Successfully Running on Nintendo Wii U vWii
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!
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!
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.
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!
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.