Hacking 5.4.0/5.5.0 MP4 Exploit

[ant888]

GOOD JOB GUYS! But... anyway, what am i supposed to do with this folder? lol

You have to build/compile it yourself...

 

[Phantom64]

You have to build/compile it yourself...

okkk thx

 

[memomo]

I think this is the userland exploit, so no Loadiine.

There is already a kernel exploit (PPC Kernel bug) for 5.4 users

 

[AboodXD]

goddamn it...

What has to happen for a Loadiine 5.5 to become available then? It's out there but private...

We need kernel OR IOSU access.

 

[NexoCube]

Did someone compiled something right ?

If yes can you send me it ? I can't compile anything...(I know why but don't want to fix it)

 

[memomo]

Thank you for sharing your work
let's wait for more stable release

I hope you could do some sort of "hello world" so we can test it out

 

[ant888]

Thank you for sharing your work
let's wait for more stable release

I hope you could do some sort of "hello world" so we can test it out

Or maybe you could try Hello World. It's actually not that hard to create one.

 

[NexoCube]

@Mathew_Wi I'm french and i don't really understand you For Devellopers tab (the first part, i understand the second.)

With the payload532.html (for example) we have to let the sprayCode() and the sprayInc version (or delte one of these but id think so) then add the mp4 to the frame ? (The <frame>)

 

[sl0ps]

It didn't contain support for 5.5.0 ... If i compile it with the 5.4.0 format will it work in 550 ?

Mmmmmmm no. Besides, even if you did manage to get userland access in 5.5.0, you would then need to find and implement a means of gaining kernel control. That bit is still private, AFAIK.

 

[moops44]

Did someone compiled something right ?

If yes can you send me it ? I can't compile anything...(I know why but don't want to fix it)

there is a readme file!!
if you want it learn to read!! and do it by yourself !!

 

[NexoCube]

Compiling helloworld doesn't work, gen-mp4 and build.py contains bugs

 

[BootsLoader]

Ok I'm very glad to see some progress at last. This is something. Now because I'm a noob I got some questions.

Is this fake or true.
I'm on 5.4.0 on my wiiu
Can I run homebrew with this, loadiine or something else. Thanks in advance.

 

[Simonwayneee]

And I've updated a few days ago..

 

[loco365]

I can tell you from experience that this exploit does not run too terribly well, it will need much improvement before it becomes functional. I assisted him with testing 5.4.0 access, and 99.9% of the time it crashed.

In addition, I tried someone elses' 5.4.0 code and it also crashed all the time, however, since it works on that other person's console, YMMV.

 

[oumoumad]

Marionumber1 says he planned to fix it, however this was a while ago...

@Marionumber1 So you're still planning to fix it? or is it too long and not worth it with the upcoming Hykem's exploit ?

 

[Deleted User]

I always get this when running build.py:

Building for your linux platform...
mkdir -p ./bin
mkdir -p ./bin/540
mkdir -p ./bin/532/
mkdir -p ./bin/500/
mkdir -p ./bin/410/
mkdir -p ./bin/400/
mkdir -p ./bin/310/
mkdir -p ./bin/300/
mkdir -p ./bin/210/
mkdir -p ./bin/200/
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=540  ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/540
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=532  ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/532
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=500  ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/500
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=410 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/410
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=400 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/400
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=310 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/310
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=300 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/300
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=210 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/210
rm ./*.o
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=200 ./src/*.c
#-Wa,-a,-ad
cp -r ./*.o ./bin/200
rm ./*.o
make: *** No targets specified and no makefile found.  Stop.
  File "/home/billy/libwiiu-540-550/framework/generate_mp4.py", line 35
  if ver == '540':
  ^
IndentationError: unexpected indent
  File "/home/billy/libwiiu-540-550/framework/generate_mp4.py", line 35
  if ver == '540':
  ^
IndentationError: unexpected indent
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code532.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code500.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code410.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code400.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code310.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code300.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code210.bin'
Traceback (most recent call last):
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 174, in <module>
  main()
  File "/home/billy/libwiiu-540-550/framework/generate_html.py", line 72, in main
  code = open(ar1, 'rb').read()
IOError: [Errno 2] No such file or directory: '/home/billy/libwiiu-540-550/bin/code200.bin'
Traceback (most recent call last):
  File "build.py", line 104, in <module>
  main()
  File "build.py", line 68, in main
  rootIndexGen(wwwDir);
  File "build.py", line 95, in rootIndexGen
  f.write(versionsSupported[-1])
IndexError: list index out of range

 

[moops44]

@NexoCube

Spoiler: README FILE!!

# README #

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, almost all firmware versions are compatible:
* Firmware versions 2.0.0 (first instalment of the Internet Browser) to 5.1.0 are supported by exploiting an use-after-free bug (CVE-2013-2842).
* Firmware version 5.3.2 is supported by exploiting a memory corruption bug (CVE-2014-1300).
* Firmware versions 5.1.1 to 5.3.1 are also supported, but currently unimplemented.
* Firmware version 5.4.0 is not supported yet.

### 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](https://cygwin.com/install.html) to get this on Windows)
* [devkitPPC](http://sourceforge.net/projects/devkitpro/) (needed to compile and link the C code), with `C:\devkitPro\devkitPPC\bin` added to `PATH`
* [Python](https://www.python.org/downloads/) 3.x (must add `C:\Python34` to `PATH`) or 2.x

#### Build Example ####
The `osscreenexamples` folder contains projects using `OSScreen` and the `loader.c` from `libwiiu`. The `examples` folder does not use `OSScreen` and uses the `loader.c` in the `projects` local directory.
* `python build.py <project path>`
* `python build.py osscreenexamples/template`

#### 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. They 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. This means that you can get the address of any function by its library and symbol name.

Every SDK library is an RPL file, a modification of the ELF format. 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 provides direct access to many core Cafe OS services, including memory management and threading.

So how do you get the addresses of SDK functions? You could just hardcode them, obviously, but that's both lame and not portable to later exploit versions. 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 and a pointer to an integer handle. `OSDynLoad_Acquire()` can also be used to get a handle to 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 handle returned by `OSDynLoad_Acquire()`, whether the symbol is data or not (usually not), the symbol name, 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 isdata, 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`*
* `rpc.dump_mem(address, length, filename)` - Dump *`length`* bytes from memory starting at *`address`* to *`filename`*
* `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
* TheKit
* Hykem
* bubba
* comex
* Chadderz
* Relys
* NWPlayer123
* Mathew_Wi

 

[VinsCool]

Sweet! Thanks for this.

I think that I'll stay in 5.3.2 haha

 

[Mathew_Wi]

I realize I forgot something. I'll upload a fix in a few minutes. Sorry.

 

[CrispyYoshi]

And I've updated a few days ago..

You may still be on 5.5. Keep your WiiU off the internet. In fact, unplug it until someone compiles a working homebrew channel with this release.