

No, just people being impatient while we fix stuff. For one, this isn't how the exploit is meant to work, and it causes a lot of weird corruption. For another, we should have never pushed it out unfinished in the first place, maybe then there wouldn't be so many whiny fools.So just like that? The Wii U hacking scene is dead in the water, never to be picked up again? F*cking unbelievable.

No, just people being impatient while we fix stuff. For one, this isn't how the exploit is meant to work, and it causes a lot of weird corruption. For another, we should have never pushed it out unfinished in the first place, maybe then there wouldn't be so many whiny fools.
I can confirm this, also running 5.3.2J.http://crediar.no-ip.com/wiiuhaxx/ work
http://wiiulib.arndroid.nl/ not work
http://nwplayer123.bplaced.net/hello.html not work
5.3.2J
4.1.1.9601
Honestly hoping you take your words back.No, just people being impatient while we fix stuff. For one, this isn't how the exploit is meant to work, and it causes a lot of weird corruption. For another, we should have never pushed it out unfinished in the first place, maybe then there wouldn't be so many whiny fools.

I am exploring all avenues for Reading and Writing the Flash (FW). The DevKit contains an eeprom_writer and a flash_writer utility so I might try to go with what is probably made to work. Going to see if a standard FTDI breakout (GND, RX, TX) will let mewrite it. but I have no image to write, as the FW in the kit is for a devkit unit, and any image I make is really going back on as an image of.
the exit one worked and the helloworld showed %u0000%u393chttp://nwplayer123.bplaced.net/hello.html
http://nwplayer123.bplaced.net/exit.html
Both verified to work. Try it a few times and if it doesn't work then you're SoL and we'll need to fix some stuff.

Wait what, how does that even work. I'm guessing the string pointer got messed up and it read part of the HTML ??? That's a dummied out part of the code we're injecting (it has to be a certain size so we just pad the rest as file offsets)the exit one worked and the helloworld showed %u0000%u393c

I'll try to replicate it if its interesting enough. It only happened once, the second time I tried mostly I get the black screen.Wait what, how does that even work. I'm guessing the string pointer got messed up and it read part of the HTML ??? That's a dummied out part of the code we're injecting (it has to be a certain size so we just pad the rest as file offsets)
Good idea!Okay, enough picking on each other, back on topic.
#include "loader.h"
void _start()
{
long long myRPLHandle = 0;
char cArr[40];
OSDynLoad_Acquire("coreinit.rpl", &myRPLHandle);
__os_snprintf(cArr, sizeof(cArr), "%x, %x, %x, %x", &myRPLHandle, &myRPLHandle + 4, &myRPLHandle + 8, &myRPLHandle + 12);
OSFatal(cArr);
}

coreinit.rpl on 5.3.2 is at 0x101c400, so read from there and you should get everything. Here's the first little bit from IDA:Good idea!
I tried to "dump" the header of the coreinit.rpl (at least I wanted to check out whether it works ^^) but the program just spit out some pointers.
Any idea for improvements?Is it even possible to access the rpl binaries from userspace?
-snip-
Oh!? RPLs don't have a string to identify it? (like MZ for Win32 executables)coreinit.rpl on 5.3.2 is at 0x101c400, so read from there and you should get everything. Here's the first little bit from IDA:
The first "function" is start and the second is __PPCExit at 0x170. Also, OSDynLoad_FindExport gets you the address of any function with a symbol in the RPL you check.