Hacking Wii U Hacking & Homebrew Discussion

[Rinnux]

Hey guys, this may be completey useless but on 5.0 in the web browser, turning the system off with the gamepad causes the system to freeze %99 of the time. Again, probably useless but just incase its not then yeah.

Must just be your wii. I have tested it several times and mine powers down just fine.

 

[koalaboy13]

So I'm looking through any 2013 webkit bugs that have proof-of-concept code or good write-ups, and I come across a bug patched in March 2013. Seems good, try it on the console, and ... nothing, behaves perfectly. I look at the 5.0 GPL source code Nintendo provides and the last entry in the ChangeLog is October 2012. The User-Agent string also reports a 2012 build of webkit. Looking at the relevant source however, there is the fix committed to the webkit svn in March 2013. That patch was not present in the source in Oct 2012. It seems as though Nintendo (or NetFront) is applying important patches to the old source. Not sure what this means for browser-based homebrew, but it doesn't bode well. Also seems strange that they would manually apply patches and not just update webkit.

 

[wallee]

This morning an idea me trotted in the head by seeing usendmii you know now that there is an exploitable weakness(fault) in the browser of the wiiu in 4.1.0 and 5.0.0 is usendmii wiiu thus l is based on the browser idea is if it is possible to modify usendmii to throw(launch) of the code via the weakness(fault) browser to think you that it is possible as we have a young slim with pc impute, video, image, information why not to put homebrew etc. here is his(her,its) l idea is this possible?
Thank you has all

 

[CarlKenner]

Anyone here knows which type of file Cafe SDK generates?
Also I guess we don't by any means have a chance of actually run that file using the webkit anytime soon?
(Sorry as stated before I only have access to my Phone and my Surface, so I can only code and speculate I can sadly not test the code myself)

The Cafe SDK generates .elf files, but with a few differences and with the extension .rpx or .rpl for libraries. There is a custom flag (0x08000000) in the section table that I believe indicates a section is compressed (deflated) with zlib, with the first 4-bytes of the section being the length after decompression, then the rest is the compressed section. Even the section that contains the names of the sections is compressed. .rpx files are not marked as executable (even though they are and therefore should not be relocated), but they do include an entry point, unlike .rpl files.
My dolphin branch can now load .rpx files (see my dolphin thread).

I believe the webkit exploit can and does load .rpx and .rpl files. It has to in order to call any function besides OSFatal, OSDynLoad_Acquire, OSDynLoad_FindExport, and __os_snprintf, which they found the addresses of manually. The problem is that we have no way (as far as we know) of putting custom rpx or rpl files anywhere that OSDynLoad_Acquire can find them, since the SD card is not mounted. Also because the process is running in the web browser, it doesn't have permissions to do many things that homebrew might want to do, and any SDK-built file we executed would have the same restrictions.

Has anyone tried loading non-RPL files with OSDynLoad_Acquire, since it obviously has some access to the NAND?

Also... is Webkit used by any other Wii U applications that might be better targets for exploits? For example, the shop, or the updates?

 

[Marionumber1]

The Cafe SDK generates .elf files, but with a few differences and with the extension .rpx or .rpl for libraries. There is a custom flag (0x08000000) in the section table that I believe indicates a section is compressed (deflated) with zlib, with the first 4-bytes of the section being the length after decompression, then the rest is the compressed section. Even the section that contains the names of the sections is compressed. .rpx files are not marked as executable (even though they are and therefore should not be relocated), but they do include an entry point, unlike .rpl files.

Mostly correct, but RPX executables are actually relocated, since their dependencies are loaded before it.

I believe the webkit exploit can and does load .rpx and .rpl files. It has to in order to call any function besides OSFatal, OSDynLoad_Acquire, OSDynLoad_FindExport, and __os_snprintf, which they found the addresses of manually. The problem is that we have no way (as far as we know) of putting custom rpx or rpl files anywhere that OSDynLoad_Acquire can find them, since the SD card is not mounted.

Well, we technically don't load any RPLs, as OSDynLoad_Acquire() will fetch the address of a module if it's already loaded. OSDynLoad_Acquire() will only look for RPLs in two places: the core OS files code directory and the current app's code directory.

Also because the process is running in the web browser, it doesn't have permissions to do many things that homebrew might want to do, and any SDK-built file we executed would have the same restrictions.

Correct.

Has anyone tried loading non-RPL files with OSDynLoad_Acquire, since it obviously has some access to the NAND?

It can only load RPLs, since the executable loader will check the validity of the file.

Also... is Webkit used by any other Wii U applications that might be better targets for exploits? For example, the shop, or the updates?

Miiverse and eShop also use WebKit, but since we have no way of putting our own HTML and Javascript on them, they're not viable targets. The browser is our best option.

 

[ehnoah]

From a Noob, but shouldn't it work, that you can insert your Code to the Shop by redirect URLs?

For example: Game X/Y/Z. Calls URL X, you Redirect to your Y Url with Malware Code? So you can insert it?

 

[NWPlayer123]

From a Noob, but shouldn't it work, that you can insert your Code to the Shop by redirect URLs?

For example: Game X/Y/Z. Calls URL X, you Redirect to your Y Url with Malware Code? So you can insert it?

Yes except we have no way of putting any URLs/content in the eShop, even if we wanted to. Miiverse MIGHT be possible with XSS (cross site scripting) but the chances of Nintendo leaving a bug like that is slim to none.

 

[uyjulian]

Also Nintendo uses SSL so it's hard to replace page.

 

[PhyChris]

can you do the old trick where you put executable code in a corrupt .PNG that is loaded in memory before the exploit and have the exploit jump there?

 

[uyjulian]

can you do the old trick where you put executable code in a corrupt .PNG that is loaded in memory before the exploit and have the exploit jump there?

Nope.

We got No Execute... except for the javascript JIT stuff.

 

[Goku Junior]

I know it is very early to ask this, but the 32MB eDRAM would help in homebrews apps? I was wondering how the apps could get better performance using this RAM, like a DS emulator, or a N64 emulator, or maybe a PS2 emulator, it could be useful the Wii U eDRAM for homebrew apps?

EDIT: Maybe custom games like a homebrew Minecraft for Wii U too.

 

[Deleted User]

...or maybe a PS2 emulator...

A PS2 emulator would be awesome

 

[jammybudga777]

Ps1 emulator is definatly possible but not a ps2 or I highly doubt it anyway

 

[Deleted User]

Ps1 emulator is definatly possible but not a ps2 or I highly doubt it anyway

Yeah my laptop cant even handle a PS2 emulator, runs at like 20fps

 

[SirByte]

Just trying to recap here; please point out where I am in error (and not trying to be negative here, just to get a feel of "where we stand" compared to f0f):

1. Team f0f claims to have FULL control of the Wii-U. They have ALL keys, except for one, for which they say it is not really relevant (comparing it to an as-yet unknow iPhone key). Team f0f member comex at first tried to use the browser to get in, achieving a lot of things (see talk) but Marcan came up with the keys.
2. We currently have a Browser-exploit, but no further progress like read/write from arbitrary memory (needed to dump RAM), circumvent that BAT Execute register that is preventing the Kernel from being dumped, etc. (this requires Wii U internal bugs/exploits, not webkit-exploits).
3. No one is publicly trying to use Marcan's approach to get the missing keys (incl. Common key).
4. We know next-to-nothing about what is running on the Starbuck and how to access it.

 

[Marionumber1]

Just trying to recap here; please point out where I am in error (and not trying to be negative here, just to get a feel of "where we stand" compared to f0f):

1. Team f0f claims to have FULL control of the Wii-U. They have ALL keys, except for one, for which they say it is not really relevant (comparing it to an as-yet unknow iPhone key). Team f0f member comex at first tried to use the browser to get in, achieving a lot of things (see talk) but Marcan came up with the keys.

comex used the browser to get initial code execution, exploited the loader and PPC kernel, exploited the ARM userspace and kernel, then dumped the common keys and Starbuck ancast key. Meanwhile, marcan used the SRESET hack in vWii mode to dump the Boot ROM and then used the HRESET hack in vWii mode to dump the PPC ancast keys.

2. We currently have a Browser-exploit, but no further progress like read/write from arbitrary memory (needed to dump RAM), circumvent that BAT Execute register that is preventing the Kernel from being dumped, etc. (this requires Wii U internal bugs/exploits, not webkit-exploits).

Yes.

3. No one is publicly trying to use Marcan's approach to get the missing keys (incl. Common key).

marcan only dumped the PPC ancast keys, which has already been done. The other keys needed ARM kernel-mode access, which itself likely requires PPC kernel access first. comex was the one who dumped those keys.

4. We know next-to-nothing about what is running on the Starbuck and how to access it.

Other than it being fairly similar in design to Wii IOS, pretty much.

 

[mznova]

Sorry if this is a dumb question but would this exploit work for firmwares below 4.10? I know there was an exploit on 3DS that only worked on 4.5-5.0 specifically.

 

[TeamScriptKiddies]

Hey guys, this is slightly off topic (but still development discussion worthy). I will be expanding my website The Homebrew Cometh to cover the SRESET linux exploit as well. I know that the linux exploit is again, not ideal for the masses, but it gives us far better access to the Wii U hardware then the Webkit Exploit does in its current state. It bypasses the Wii U's operating system altogether (including the IOS Kernel, which is a big part of what is keeping us from getting anywhere with the Webkit exploit at this point). This gives us quite a bit more freedom when it comes to running custom code (designed to run natively in linux of course). This kind of exploit will not enable region free loaders or any of that of course because the Wii U's OS is circumvented entirely, but it "could" potentially lead to the an Integrated Development Environment (IDE) being developed, that we could actually write homebrew with that runs on the hardware itself . Just throwing some ideas out there.

Also people like myself (who would throw linux on their toaster, if it were possible) are going to find this linux exploit pretty neat anyways .

*Of course, just to make everything clear, the Linux Exploit I'm referring to was NOT developed by me or any member of my team. This was created by Trinux Team and they based it off of some of the work of Team Failoverflow (SRESET Hack etc).* Give credit where credit is due .

I have a crappy youtube video of me running this exploit here :


I apologize, I really need to get a decent phone and not rush through these videos..... Anyways it gives you a basic overview of what's going on and shows it executing.

Sorry if this is a dumb question but would this exploit work for firmwares below 4.10? I know there was an exploit on 3DS that only worked on 4.5-5.0 specifically.

The Webkit exploit will work for 4.0.x firmwares. X being a variable, can be any number. You just need to make sure you use the right version of the exploit . Check out my makeshift homebrew menu (link in sig) and click on the appropriate button for that exploit

 

[mznova]

The Webkit exploit will work for 4.0.x firmwares. X being a variable, can be any number. You just need to make sure you use the right version of the exploit . Check out my makeshift homebrew menu (link in sig) and click on the appropriate button for that exploit

So if I had 2.10 I wouldn't be able to use it? Also, do you happen to know if this is the most promising exploit found? Are there any other exploits found in lower firmwares that are stronger than this one?

 

[jammybudga777]

Hey guys, this is slightly off topic (but still development discussion worthy). I will be expanding my website The Homebrew Cometh to cover the SRESET linux exploit as well. I know that the linux exploit is again, not ideal for the masses, but it gives us far better access to the Wii U hardware then the Webkit Exploit does in its current state. It bypasses the Wii U's operating system altogether (including the IOS Kernel, which is a big part of what is keeping us from getting anywhere with the Webkit exploit at this point). This gives us quite a bit more freedom when it comes to running custom code (designed to run natively in linux of course). This kind of exploit will not enable region free loaders or any of that of course because the Wii U's OS is circumvented entirely, but it "could" potentially lead to the an Integrated Development Environment (IDE) being developed, that we could actually write homebrew with that runs on the hardware itself . Just throwing some ideas out there.

Also people like myself (who would throw linux on their toaster, if it were possible) are going to find this linux exploit pretty neat anyways .

*Of course, just to make everything clear, the Linux Exploit I'm referring to was NOT developed by me or any member of my team. This was created by Trinux Team and they based it off of some of the work of Team Failoverflow (SRESET Hack etc).* Give credit where credit is due .

I have a crappy youtube video of me running this exploit here :


I apologize, I really need to get a decent phone and not rush through these videos..... Anyways it gives you a basic overview of what's going on and shows it executing.

maybe a silly thing for me too say but isnt this video just showing something that maxternal and co has been doing?