Hacking Wii U Hacking & Homebrew Discussion

[Marionumber1]

To be more specific, boot2 is what's writing to it, and it does so every time a new IOS is loaded. Doesn't mean it won't work, as the function is still unknown, but it could just be an OS key switch for the CPU to check the Wii's signature instead of the Wii U's signature on loaded software while in vWii mode.

boot2 wrote to it on the original Wii, but there is no boot2 in vWii mode, so the register could mean something completely different.

 

[Gadorach]

boot2 wrote to it on the original Wii, but there is no boot2 in vWii mode, so the register could mean something completely different.

Fair enough. By the way, after looking through libWiiU's source, it seems the only real step involved in getting the OSDriver exploit going on 5.1.2 is finding these memory locations:

#define KERN_SYSCALL_TBL 0xXXXXXXXX
#define KERN_CODE_READ 0xXXXXXXXX
#define KERN_CODE_WRITE 0xXXXXXXXX
#define KERN_ADDRESS_TBL 0xXXXXXXXX
#define KERN_HEAP 0xFF20000

Do you have a usermode RAM dumper for finding these, or do you use hardware or something? If you send me the required dump code, I'd be happy to look into finding these offsets.

EDIT: Ah, kept reading, and now I know that the gadget search function is just based on pre-found gadgets on a per-firmware basis, loaded from the ropkitxxx.txt files. Lots more addresses to find then. I'm still game though, if you have the tools for me to use to dump and search for the addresses anyway.

 

[Marionumber1]

Fair enough. By the way, after looking through libWiiU's source, it seems the only real step involved in getting the OSDriver exploit going on 5.1.2 is finding these memory locations:

#define KERN_SYSCALL_TBL 0xXXXXXXXX
#define KERN_CODE_READ 0xXXXXXXXX
#define KERN_CODE_WRITE 0xXXXXXXXX
#define KERN_ADDRESS_TBL 0xXXXXXXXX
#define KERN_HEAP 0xFF20000

Do you have a usermode RAM dumper for finding these, or do you use hardware or something? If you send me the required dump code, I'd be happy to look into finding these offsets.

EDIT: Ah, kept reading, and now I know that the gadget search function is just based on pre-found gadgets on a per-firmware basis, loaded from the ropkitxxx.txt files. Lots more addresses to find then. I'm still game though, if you have the tools for me to use to dump and search for the addresses anyway.

That would have to be done, but the main obstacle in getting the OSDriver exploit working on 5.1.2 is getting user-mode code execution there first. Our 5.3.2 exploit should work fine on 5.1.2, but we've had no reason to backport it. Those kernel addresses can just be found through looking at the Cafe OS kernel from version 5.1.2 (downloadable with NUS), and all ROP gadgets for used in the exploit are dynamically found.

 

[Gadorach]

That would have to be done, but the main obstacle in getting the OSDriver exploit working on 5.1.2 is getting user-mode code execution there first. Our 5.3.2 exploit should work fine on 5.1.2, but we've had no reason to backport it. Those kernel addresses can just be found through looking at the Cafe OS kernel from version 5.1.2 (downloadable with NUS), and all ROP gadgets used in the exploit are dynamically found.

The main reason to backport it in my eyes would be that the IOSU exploit in development for pre-5.2.0 firmwares works on 5.1.2, which is the only firmware installable from a disk-update that's both on 5.x, and before 5.2.0. If you do decide to back-port it, I'd be willing to donate my time to help test it.

 

[SkyDX]

So probably a dumb question, my Wii U is already at 5.5.0E since I was pretty much in a situation where I was forced to update and I don't mind keeping it on 5.5.0 for the time being and hoping there will someday be a solution for this firmware. However I wanted to uploaded a Smash replay to YouTube and my Wii U said I have to update my System Software. I presume it's related to the new NNID Sign-in Checks implanted on the 3DS site of things, however neither the official Nintendo website nor Wikipedia have a update listed beyond 5.5.0?

Is this 5.6.0 or just a 5.5.x update? If so, would it be safe to update since I'm already on 5.5.0 anyway or will I further push myself back from Homebrew if I update?

 

[M tha MaN]

You just might need a new Super Smash Update

 

[Gadorach]

Decrypted the kernel for 5.1.2 and found out the addresses are the same as 5.0.0

+ #define KERN_SYSCALL_TBL    0xFFEA9520
+ #define KERN_CODE_READ    0xFFF021f4
+ #define KERN_CODE_WRITE    0xFFF02214
+ #define KERN_ADDRESS_TBL    0xFFEA9E4C
+ #define KERN_HEAP    0xFF200000

What's the next step anyway @Marionumber1 ? Just compiling a new version of the 5.3.2 WebKit exploit with these offsets instead of the 5.3.2 Offsets?

 

[FIX94]

I didnt do things for wiiu in quite a while did I? So here is something to help the kernel exploit usage:
added on-screen prints to osdriver kernel exploit to know whats going on and automatically restarting browser on success/entering system settings on failure to speed things up further
Its already up on my webpage if you want to give it a try.

 

[Marionumber1]

Decrypted the kernel for 5.1.2 and found out the addresses are the same as 5.0.0

+ #define KERN_SYSCALL_TBL    0xFFEA9520
+ #define KERN_CODE_READ    0xFFF021f4
+ #define KERN_CODE_WRITE    0xFFF02214
+ #define KERN_ADDRESS_TBL    0xFFEA9E4C
+ #define KERN_HEAP    0xFF200000

What's the next step anyway @Marionumber1 ? Just compiling a new version of the 5.3.2 WebKit exploit with these offsets instead of the 5.3.2 Offsets?

Kernel offsets have nothing to do with the browser exploit. The browser exploit needs its addresses ported.

 

[Gadorach]

Kernel offsets have nothing to do with the browser exploit. The browser exploit needs its addresses ported.

Alright, guess that's the next thing to look into. Still, kernel offsets are important for the actual kexploit, so not like it was entirely a waste of time. Guess I'll be looking for the webkit addresses next then.

 

[Cyan]

I didnt do things for wiiu in quite a while did I? So here is something to help the kernel exploit usage:
added on-screen prints to osdriver kernel exploit to know whats going on and automatically restarting browser on success/entering system settings on failure to speed things up further
Its already up on my webpage if you want to give it a try.

thank you.
I just wondered why it didn't reload the settings automatically and that it would be great to add, and you did it
I also wondered why it can't re-run the exploit right away without reseting the console, but you didn't do it hehe
why can't it reset the changes itself and try again right away without reseting the console?


I tried it and it worked fine (twice in a row, I'm lucky)
though I noticed an issue but it's not important :
run the kernel, it reloads the browser.
run the kernel again, it says "Exploit already succeeded! Restarting browser..." but the browser never restarts, it's stuck on a black screen.

So, it's not very important as nobody needs to reload the kernel a second time, but it can be an issue if it can't reload a different Title after reloading the browser automatically.
this feature could be used (like wup installer, it's run twice), and the second time it won't be able to reload another title.
I don't know why it freezes, I just wanted to report it.

 

[FIX94]

run the kernel again, it says "Exploit already succeeded! Restarting browser..." but the browser never restarts, it's stuck on a black screen.

if you take a look at the code you'll see the code for that is 100% identical and it also works fine on my 3.1.0 so I have no idea at all why it doesnt work for you.

 

[Cyan]

yes, I looked at the code and saw it was identical.
if it works for you, maybe it was a random crash twice in a row. well, like I said it's not very important as it's on the second run.

 

[Reecey]

I didnt do things for wiiu in quite a while did I? So here is something to help the kernel exploit usage:
added on-screen prints to osdriver kernel exploit to know whats going on and automatically restarting browser on success/entering system settings on failure to speed things up further
Its already up on my webpage if you want to give it a try.

@FIX94 I'm loving the new changes to the osdriver, fantastic work my friend! Auto Exit to System Settings on Race Attack & Auto Exit back into the Browser! Really clever stuff, hats off to you sir!

Edit: its ok but way too many race attacks now than ever you need to fix that more than anything else! its 2 boots 1 race attack every go.

 

[CoolAlpha]

The browser exploit needs its addresses ported.

Any tip on how to find/port them?

 

[JaceCearK1]

Any tip on how to find/port them?

Reverse Engineer it!

 

[EclipseSin]

yes, I looked at the code and saw it was identical.
if it works for you, maybe it was a random crash twice in a row. well, like I said it's not very important as it's on the second run.

It happens for me as well. I've tried changing it, but I haven't gotten anything more than a black screen still myself doing that. I might change it to reload the HBM instead, see if it works that way at least.

 

[FIX94]

Edit: its ok but way too many race attacks now than ever you need to fix that more than anything else! its 2 boots 1 race attack every go.

its always random, the worst was like a month ago, it took me 4 hours to get it once, other days I can do it 50 times in a row no problem.

 

[EclipseSin]

I have forked FIX94's libwiiu, and added the selection menu for loadiine or normal. Feel free to change. You can find it here: https://github.com/EclipseSin/libwiiu/

 

[Reecey]

its always random, the worst was like a month ago, it took me 4 hours to get it once, other days I can do it 50 times in a row no problem.

Have you tried working along side WJ44 he seems to have his driver working really well. Not sure what he does to it to change but it does work rather well, maybe you and him can join forces and come out with a super driver together!