Following the earlier leak, an official release has been posted with more info on its proper usage.
This release 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.
A few days ago, unofficial files for 'browser exploit' on the Wi U was getting passed around, and we got a copy of it via random-generated email and we decided to post it as news, and this started alot of 'scene drama' as usual, but now an official release has been posted up on BitBucket with a complete 'readme' on what it is and how it works and what you can and can not do with it on your v4.1.0 Nintendo Wii U console.
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, the only Wii U system software versions supported are 4.0.x and 4.1.0. 5.0.0 has the WebKit bug, but there is no exploit for it yet.
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
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) and 410 (for 4.1.0). Not supplying a version string will cause it to default to 4.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:
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:
So opal reported about the leaked Wii U Webkit exploit (gbatemp.net/threads/wii-u-browser-exploit-leaked-for-v4-10.367458/) and that thread boot flooded pretty fast by *well lets say say inexperienced people* so I wanted to take my time to create this Thread for discussion about where to go from here.
According to experienced hackers v5 still haven't patched the exploit its just a matter of binary change, which results in us having to develop a ROP chain for v5.
WiiU Browser Exploit Leaked, Possible Vita Compatibility?
WiiU Browser Exploit Leaked, Possible Vita Compatibility?
To quote from heleius (via wololo.net/2014/06/20/wiiu-browser-exploit-leaked-possible-vita-compatibility/):
The Wii U scene has been up in arms over a web browser exploit that was recently leaked (then later on, officially released). Though the files were only recently leaked, Nintendo had already partially patched the exploit in firmware 5.0.
The files are readily available to the public, but won’t do anyone without access to a web server any good (though it’s reasonably easy for anyone to set on up on their local network. If required, some tools will definitely show up). I personally don’t own a Wii U but we all know that leaks hurt any scene more than they help.
That being said, since the files are readily available I decided to test them out. On the PC the exploit simply shows up as an empty iframe, but when tested on on the Vita, this exploit appears to put the Vita into an infinite loop on the browser. I made a YouTube video of the exploit in action on my Vita you can watch below.
For those of you reading this on your Vita you can check out the Wii U browser exploit in action by following this link: hackinformer.com/p/wiiu/index.html
So what does this mean for the Vita, could a possible native Vita hack come from this? In the hands of the right devs could this lead to the first Vita CFW? Or is it little more than an auto reloading browser?
Don’t get your hopes too high: Fail0verflow had explained a while ago that the reason such exploits can run on the Wii U is because the NX bit is not set within the browser on the Wii U. This, as far as we know, is not the case on the PS Vita (and has been confirmed at least by Yifan Lu here).
Nonetheless, it is interesting to see this Wii U hack running on our beloved handheld, and people might find additional vulnerabilities on the Vita that could make this useful eventually.
UKey Images Released, Wii U Browser Exploit Leads To Mario Kart 8 Hack ?
UKey Images Released
From GregoryRasputin: Well it probably doesn’t come as a surprise to any of you, that i HATE ODDE devices, so i see this cancellation as good news, others may disagree with me and say it’s bad news, because its release might have forced the consoles hackers to release a software version.
Anyhow, BobbyBangin posted the news on our site PS3HaX, here is a quote from his thread:
Today I received a couple pictures of the Wii Ukey. I received them from a non-native english speaking source, so I had a little trouble understanding the exact situation.
From what I understood, the device is no longer being manufactured and is under new ownership, that is why it’s being released now. As to what purpose this will serve, I have no idea. There is a new device being manufactured and it’s going to be called the WiikeyU. They are being manufactured by two completely different people.
I’m confused as to why this device is being cancelled, since it is fully operational and functional. The blue Ukey dev board is the ripper. It allows for the ripping of Wii U games. This is how all the games have been ripped and released.
I generally have a very harsh non-ode stance, but am hoping that one can be released, so that it can be reverse engineered and released to the public.
Disclaimer: This is NOT to be considered an endorsement. I am only releasing the info that I received. I do not own nor promote ODDE devices.
Update: Well it seems that i mistook BobbyBangins post, he actually stated that the device had changed hands and that it isn’t actually cancelled, sorry for the confusion, if you keep an eye on the discussion thread, you will be kept up to date with changes.
Wii U Browser Exploit Leads To Mario Kart 8 Hack ?
A group of guys have released a video showing modded tracks and other neat tricks, here is a quote from the video description:
This work is based on the recently released browser exploit, and some additional code that Chadderz wrote to get arbitrary kernel reading and writing, to allow the browser to edit Mario Kart 8′s memory on-the-fly.
All of this may not look impressive, but it’s merely because we don’t even know where to start; we can do anything now, anything at all! Custom tracks, custom songs, you name it. We just have to decipher the RAM and work out how.
I hope you enjoy this quick look into what we’ve been up to recently, and hopefully more to come soon!
Here is a complete list of what they have accomplished:
Making Moo Moo Meadows play its final lap music immediately
Making the final lap play no music at all
Making the lap 1/2 song into the opening camera fanfare
Renaming Moo Moo Meadows to “Hello!”
Renaming it again to “Shittyluck course!”
Renaming Toad’s Turnpike to Deathpike...
Corrupting a font
Crashing the Wii U
Altering the Wii U menu fonts
And here is the video:
From the WiiKey Team: The pictures recently posted depicts a PCB we designed to interface the WiiU drive with a PC. The only thing this good for is dumping games, and this requires that you have the unique key of the drive being used. None of the exploits we have seen going public allows you to read the OTP fuses - in other words, there is no (public) way to extract drive keys.
Finally, from the device manufacturer / promoter garyopa (aka Gary Wayne Bowser) on the above story:
That story is so full of 'bullsht'.... I traded emails with wiikey since their very first start in the scene, and the main people running it are still the same people.
Only thing changed recently, is development of the 3k3y firmware has been turned over to a new coder to update the firmware, reason why suddenly there was updates to 3k3y with beta releases for fixes for 4.55 after months of nothing.
Because the previous coder was no longer working for them and not getting things done ontime, so all his works has been bought out and the coding turned over to new coders that are willing to complete things. Upper management and operators are still the same.
As for wiiukey there is still some discussion on the final product name, and those ripper pictures I could have leaked a while ago, the ripper was completed for a while ago, and was given out to two testers to help fine-tune the software on the PC to rip original wii u game discs.
As for WiiKey U itself, its still coming along, there has been no change of owners, all tho some other team members have been moved around and are now working other projects, the ODE itself is still coming along slowly, with a possible name change and other key improvements to the overall design.
I hope this kills any rumors about cancelled devices, sure there will be short delay in getting the new coders up to speed on finishing some of fpga coding and firmware, so most likely they will miss the End of July/Early August date, but that was bound to happen anyway, look for how long it took PS3 ODE's to be finalized, even the Cobra UDE will take another 6 months or so to be completed.