Hacking Wii U Hacking & Homebrew Discussion

  • Thread starter Thread starter filfat
  • Start date Start date
  • Views Views 5,121,336
  • Replies Replies 21,104
  • Likes Likes 29
So I see people playing around with things at this point. celcodioc How are you getting RAM dumps? I'd like to dump my own RAM for my Wii U audio tool, but I don't have anything I can dump with yet.

Edit: Wow am I blind or what. Looks like I'll have to set up the development software and give that a shot.
 
So I see people playing around with things at this point. celcodioc How are you getting RAM dumps? I'd like to dump my own RAM for my Wii U audio tool, but I don't have anything I can dump with yet.

Edit: Wow am I blind or what. Looks like I'll have to set up the development software and give that a shot.


Make SURE you block Wii U updates!!!
 
  • Like
Reactions: Ryanrocks462
It appears that the GX2 library provides functions to change the TV and Gamepad framebuffers, GX2SetTVBuffer() and GX2SetDRCBuffer() respectively. A while ago, I managed to find an example usage of GX2SetDRCBuffer() in a presentation given by a fail0verflow member. Go down to the slide titled "WiiU DRC", it shows how to allocate and then set the framebuffer for the Gamepad. We could probably use this same method.


1dWL2fB.png
 
I got this to work using the first source of an image I could think of - the one we were pulling screenshots from earlier. So now my TV can display the image for... my TV. Incredible.


Source code bro? :)
 
I'm actually dumb and I had my source format wrong. I'm gonna test uploading my own image and displaying it, then I'll explain how it's done and how the render modes work and stuff.
 
I'm actually dumb and I had my source format wrong. I'm gonna test uploading my own image and displaying it, then I'll explain how it's done and how the render modes work and stuff.


Awesome! :) We should be able to throw together a nice little graphics lib.
 
Whenever I try to send my framebuffer to the Wii U, I have the system crash with 'Invalid RPC command'. I'm opening my file as binary, reading its data to a variable, and then trying to write that variable with rpc.write32(address,thatvariable). Any clue what's going on?

EDIT: Seems to be I'm outpacing rpc.write32. Putting a sleep in works, but obviously makes the whole ordeal take much longer. Will look into it more and finish tomorrow.
 
A little update on the website for those who are wondering: I'm about to update the IP records to point to Azure which not only will provide a better experience, but will also provide faster loading times AND auto pull from githup/bitbucket so I can make the website source code public and allow the community to contribute. For example we can do something in style of thehomebrewcomet but allow anyone(with reasonable borders) to add their application to the list of application, it will also allow me to work more easily on the website when I'm not in front of my computer and/or Surface 2(Microsoft Tablet).
I hope everything I setup within 2-3 days, provided that either Hostingitall.com responds and changes the IPs on the cPanel or that I find another nameserver so I can point the IPs to Azure.

Current Azure setup: http://wiiu.azurewebsites.net/ (yes I got the "WiiU" hostname on the website which is hosting some of the biggest websites of the world, eat that Nintendo :P)
 
  • Like
Reactions: celcodioc
I know you guys can't predict anything but I was curious to know your opinion: do you think that with time and after the developers have a big understanding of how the Wii U works we will be able to use the exploit offline?
 
I know you guys can't predict anything but I was curious to know your opinion: do you think that with time and after the developers have a big understanding of how the Wii U works we will be able to use the exploit offline?


You don't need an internet connection to run the WebKit exploit, you can run it off your local network. I think there are other possible exploit vectors, but our team isn't interested in pursuing them for a while.
 
I got an idea for the Auto update problem, i could create and/or host a dns which blocks(redirects to be fair) the nus servers so people who cant block ip's in their router still has an possibility to use their Wii U Online? Any thoughts? :)

sounds like an awesome idea but in the words of most of the people, you better make sure that damn thing redirects the addresses :D
 
  • Like
Reactions: LawnMeower
Whenever I try to send my framebuffer to the Wii U, I have the system crash with 'Invalid RPC command'. I'm opening my file as binary, reading its data to a variable, and then trying to write that variable with rpc.write32(address,thatvariable). Any clue what's going on?

EDIT: Seems to be I'm outpacing rpc.write32. Putting a sleep in works, but obviously makes the whole ordeal take much longer. Will look into it more and finish tomorrow.

I modified your code to display things on the GamePad.

That is... if it actually would work. There are a few issues with it:
  • Random crashes (not OSFatal from rpc.c) when the framebuffer reaches about 500000-600000 bytes, perhaps because I was impatient and set the sleep value to 0.08 (Update: Or are we overwriting something?)
  • MEMAllocFromDefaultHeapEx causes the Wii U to crash (Update: Yep, it always does, at least I think so.)
  • DRCBRun does nothing, not even in a loop, do we need to cancel a thread like in the fail0verflow sample?
If you want to try it out yourself, download these files and put them in the same directory as rpc.py:

https://dl.dropboxusercontent.com/u/72562253/gx2.py
https://dl.dropboxusercontent.com/u/72562253/uc2d.jpg.bin (Uncharted screenshot)

Then connect the Wii U to your computer through RPC and write this in the shell:

Code:
import gx2
gx = gx2.GX2(rpc)
gx.DRCBSetup("uc2d.jpg.bin")
gx.DRCBRun()

If anyone wants the software that I used for converting images to RGBA .bin files, it's ToRGBA from here: https://dl.dropboxusercontent.com/u/72562253/CWRT_v2.zip
Drag and drop into it like my other tools. I also updated FileToBitmap to not add an extra line unless it's necessary :)
 
  • MEMAllocFromDefaultHeapEx causes the Wii U to crash(?)... I only tried once, so I'm not sure. It could be related to the previous one.
MEMAllocFromDefaultHeapEx() is weird, because rather than being a function, it's really a function pointer. This function pointer is still exported as a symbol, but there's a small catch. The prototype for OSDynLoad_Acquire in my README is
Code:
void OSDynLoad_FindExport(unsigned int handle, int always0, char *symname, void *address)
The always0 parameter is actually a parameter that determines whether the symbol you're exporting is data or not. Normally, it is set to 0, since we're exporting functions, but for exporting MEMAllocFromDefaultHeapEx(), you need to set it to 1. A pointer to MEMAllocFromDefaultHeapEx() will be placed at address, which you can deference to get the function address. Basically, you'd need this code:
Code:
unsigned int coreinit_handle;
OSDynLoad_Acquire("coreinit.rpl", &handle);
unsigned int *ptr;
void* (*MEMAllocFromDefaultHeapEx)(unsigned int size, unsigned int align);
OSDynLoad_FindExport(handle, 1, "MEMAllocFromDefaultHeapEx", &ptr);
MEMAllocFromDefaultHeapEx = *ptr;
 
  • Like
Reactions: celcodioc

Site & Scene News

Popular threads in this forum