Hacking Wii U Hacking & Homebrew Discussion

  • Thread starter Thread starter filfat
  • Start date Start date
  • Views Views 5,122,351
  • Replies Replies 21,104
  • Likes Likes 29
But will it be possible to develop, say, a USB loader and run it using your exploit? (i'm a pirate in case you couldn't tell)


I don't think a USB loader is possible without IOSU access, but even if it is, that would be contingent on the exploit being deobfuscated.
 
More Smash:
  • I tried to see if having no phtcache.bin creates the new phtcache.bin out of the current .dat file
  • It still said my data was corrupted, which doesn't happen when the only difference is a lack of phtcache.bin
  • If anybody thinks Smash verifies the .dat a different way or has a logical explanation to what happens wit the .dat, phtcache.bin, and the images with their corresponding .bins please feel free to reply with your explanation
  • I know I said I was done with this project, but it actually sounds fun to do in my free time you can find the project at http://github.com/IbbyCode/SmashStackU
  • Feel free to make new branches with the files from your SD named your gbatemp username
  • Also, github can't read phtcache.bin for some reason
  • The way I plan to attempt to make the exploit goes: Find a way to modify .dat file without it getting replaced, Make .dat file pointing to a file named boot.dol/boot.elf (the traditional name of a hombrew app's boot code), make boot.elf/boot.dol, crack the encryption for the .bin files that correspond to the images, give boot.elf/boot.dol it's very own .bin file, run smash and load the album menu
  • After following all those steps, the exploit would either boot automatically, or there would hopefully be a corrupted looking thumbnail/image preview that would run your code when tapped on
 
How do you plan to crack the encryption? (Sorry if this is obvious, I'm a noob that doesn't really belong here.)

That my friend, is one of the many reasons why this hasn't already been done. I need other people to help me because if someone is still on exploitable firmware I'm pretty sure the kernel exploit will allow them to find the key that the game uses to encrypt the .bin files and then decrypt the files and help make the exploit. Even if the keys are game specific and you need to open smash to view them, the browser exploit will later be ported to 5.1.1 and up. people on a version of the firmware that has the kernel exploit (since 5.3.0-5.3.2 might block it) and can open smash can obtain the key. build their exploit, then update their Wii U (to regain online functionality), and run the exploit (which will still work). Even though this exploit may be pointless now that there is soon to be a kernel exploit, people can use the exploit without internet connection (to prevent updates if they are having trouble doing so) and it will be easier to add apps to the possible hombrew channel.
 
  • Like
Reactions: Gruntzer
OK, whatever. I take everything back I said about piracy (even though I still want it). It's great that we will soon have 5.3.2 WiiU homebrew.

Unless I missed something, he said nothing about 5.3.2...

Also, remember that no one here is by any means obligated to share ANYTHING with us, so give them at least a shred of respect with their decisions regarding their releases

Edit:
While it is true that our kernel exploit couldn't even be executed on 5.3.2 right now, once we have a browser exploit for that (and that is our plan), it should work.

Thank you for clarifying, this is good news
 
  • Like
Reactions: night_hawk
If I had a push in the right direction I might be able to help with the browser thing (not loading stuff, just freezing the browser) since I have access to a web server, but tbh I don't know what to do.


comex's part of the fail0verflow presentation sort of explains it, but I have more detailed instructions. The first part of the browser exploit would be to identify a bug that crashes the Wii U. A crash would exhibit itself as the console freezing. Finding bugs can be done by either looking through WebKit commit logs, or searching bug tracker forums (like Google Code). Commit messages often contain unit tests to reproduce the bug that they fix, and bug tracker posts sometimes do. Here's my recommended strategy for finding bugs in the commit log:
  • Obtain the most recent copy of the WebKit repo (yes, you'll need SVN) and use svn-log to get the commit logs
  • Write a shell script to parse the log into separate commit entries
  • In each commit entry, look for a link to https://bugs.webkit.org/show_bug.cgi?id=<num>, where <num> is some number. Pull the HTML from that link, and see if it contains "You are not authorized". If it does, store that commit entry away for later.
  • Once you have a pool of commit entries, look at each of them. Most commit entries reference files in LayoutTests, which are unit tests designed to trigger the bug. You want to try each of these unit tests, and see what happens. If the Wii U crashes, that's a good sign. Sometimes, the bug may trigger but not crash, which is still good. If it doesn't exhibit any buggy behavior, move on to a new commit.
I'd recommend hosting the entire LayoutTests directory on a local web server.
 
  • Like
Reactions: Coto
Which is interesting. It could either indicate that it was a bug Nintendo ended up patching, or something entirely different that doesn't work on 5.3.2 by a coincidence.

I imagine due to Plex being a dynamic streaming service that Plex could have fixed the problem on their end. Best way to test would be to see if it still works on 5.2.0 when it was confirmed working.
 
I can probably write one when I have some time outside of doing the kernel exploit.
Then please do so.

comex provides the script that does bullets 2&3 in his slides of the 30c3 talk. i had posted a list of the commits we're not allowed to see a few pages back and was asked to remove the post.

you can use git and clone from their git mirror of svn:
Code:
git clone git://git.webkit.org/WebKit.git WebKit

and you'll only want to include commits after 89c9ced37bb855c72ebde678d6f54fb492233af9, as this is the commit that fixes the currently used public webkit exploit
 
  • Like
Reactions: VinsCool

Site & Scene News

Popular threads in this forum