Hacking Wii U Hacking & Homebrew Discussion

[Billy Acuña]

#2 - "Help me IOSkaku, you're our only hope!"

yes I'm actually doing this now; here's a list. Feel free to edit in whatever opinions you come across although you must tell the poster of the opinion about the list and their opinion's ID number so they can just use that in future.

No, seriously, I'm not motivated to develop stuff for Wii U and test it on a very shitty and unstable exploit from browser, and HBL is unstable too. So IOSUhax and Coldboothax will make things easier for developers.

 

[VinsCool]

No, seriously, I'm not motivated to develop stuff for Wii U and test it on a very shitty and unstable exploit from browser, and HBL is unstable too. So IOSUhax and Coldboothax will make things easier for developers.

Woah define how HBL is unstable? I'm on 5.5.1, Exploit works 100%, and HBL runs 100%.

 

[Billy Acuña]

Woah define how HBL is unstable? I'm on 5.5.1, Exploit works 100%, and HBL runs 100%.

Randomly freezes, but I think that is more an entrypoint's issue than a HBL's issue

 

[VinsCool]

Randomly freezes, but I think that is more an entrypoint issue than a HBL issue

Most likely an issue on your end. Because the 5.5.1 move was the best thing ever.

5.3.2 -> 30% to 50% working
5.5.1 -> 99+% working (I mean, it probably failed like once)

 

[QuarkTheAwesome]

No, seriously, I'm not motivated to develop stuff for Wii U and test it on a very shitty and unstable exploit from browser, and HBL is unstable too. So IOSUhax and Coldboothax will make things easier for developers.

The majority of people can get 100% browserhax success rates through methods like selfhosting and using specific websites (depends on distance so I can't recommend any without knowing locations and things). Try the usual troubleshooting methods if you aren't hitting that nmber. I've personally never had any stability issues under HBL; and I intentionally try to crash it. (now if only it was bad-stack resilient...)

As a developer, you can probably trust me when I say that it's not that bad. Sure, waiting for the console to boot back up is a little annoying but what it really ends up doing is driving you to code in a way that (probably) won't crash. You'll spend more time in front of the computer than the console is what I'm saying.

 

[the_randomizer]

Most likely an issue on your end. Because the 5.5.1 move was the best thing ever.

5.3.2 -> 30% to 50% working
5.5.1 -> 99+% working (I mean, it probably failed like once)

Seconded, have had nothing but high success rates with 5.5.1 exploits. That's hardly a valid excuse not to develop for the Wii U.

 

[Quantumcat]

Oh boy, a callout post!
Everything's coming along well. Userland UI is getting locked in and we're starting to implement those features. In the last few days I've personally done a heap of RE to unlock a bunch IOS-side resources for use in PPC homebrew, as well as mostly rewriting our entry code from scratch to cut boot time (by like 15 seconds!) and get stability up to 100% under all conditions.
Tangentially related - debugging is a breeze on our stuff since you can get very verbose post-crash logs even after the entire PPC-side system has seized up. We're super excited to get that functionality in developers' hands. Here's an example of some random browser crash I still have open in notepad++ as an example. We've actually fleshed out logging with our own additions too, but we'll talk more about that later.
Sorry things are taking so long, but the good thing is we're definitely starting to get a good grip on exactly what still needs to be done still before we can release!

Thanks!

Best->honest news <- what this is
OK->nothing until release day
Worst->hypy news with little truth in it

 

[adamnewy]

 

[VinsCool]

just a few days late

 

[WulfyStylez]

Randomly freezes, but I think that is more an entrypoint's issue than a HBL's issue

It's indeed an entrypoint issue. It seems to stem from a misunderstanding of the exploit in use along with the execution environment it's being run in. I've actually had that code fixed up (largely rewritten) for some time since we used to launch thru HBL's loader, but I can't pull-request it because I ripped out the OSDriver sploit when I forked it.
The real solution here is to find KERN_DRVPTR for 5.0.0 and lower, since it's the missing piece to support those old firmwares. Ideally it'd be best to completely kill the OSDriver sploit off, you know? @dimok what's your take?

 

[fatsquirrel]

Most likely an issue on your end. Because the 5.5.1 move was the best thing ever.

5.3.2 -> 30% to 50% working
5.5.1 -> 99+% working (I mean, it probably failed like once)

This so very much.
Im extremely glad that I left 5.3.2 behind and upgraded. I had literally like one in ten chance for 5.3.2 to work. And god help me if it bugged and had to clear cache. Then sometimes Id had to spend hours retrying for some odd reason, until it worked.

 

[Maximilious]

Most likely an issue on your end. Because the 5.5.1 move was the best thing ever.

5.3.2 -> 30% to 50% working
5.5.1 -> 99+% working (I mean, it probably failed like once)

However one thing I am noticing since upgrading to 5.5.1 is that launching the web browser from a fresh boot will cause the console to lock up on the home screen. After hard reboot (holding power) it comes back up fine. It's probably something in my method, but my conditions for this to happen are the following:
1. After running Loadiine 3.0 over XAMPP local network
2. Shutting down the console while Loadiine was still running in game (Color Splash in this example), or even closing out of the game and going to home screen
3. Turning the console back on and it will lock up about 50% of the time

I'm not sure if there's a way to properly close out of HBL in this example, but I have seen this happen a couple of times now.

 

[dimok]

It's indeed an entrypoint issue. It seems to stem from a misunderstanding of the exploit in use along with the execution environment it's being run in. I've actually had that code fixed up (largely rewritten) for some time since we used to launch thru HBL's loader, but I can't pull-request it because I ripped out the OSDriver sploit when I forked it.
The real solution here is to find KERN_DRVPTR for 5.0.0 and lower, since it's the missing piece to support those old firmwares. Ideally it'd be best to completely kill the OSDriver sploit off, you know? @dimok what's your take?

Yeah from what I saw it was the entry point. It never got to the code that is supposed to be executed. I did several versions for users to test and it didn't matter what I did there was no change. After some users added a sleep before building up the mvplayer in php everything worked with almost a 100% success rate with no change on the code side. I agree with the finding KERN_DRVPTR for all lower systems version being a way better solution but I am busy with other stuff and its not my top priority right now to support the old firmwares. Especially since everything that is being worked on is for 5.5.1 at the moment. I would though remove the OSDriver once all firmwares are supported by gx2sploit.
Anyway people on 5.5.1 that still have instability issues are probably not using the php in their browser but the mp4 file directly and that is instable because it is missing that necessary delay.

 

[Bug_Checker_]

It's indeed an entrypoint issue. It seems to stem from a misunderstanding of the exploit in use along with the execution environment it's being run in. I've actually had that code fixed up (largely rewritten) for some time since we used to launch thru HBL's loader, but I can't pull-request it because I ripped out the OSDriver sploit when I forked it.
The real solution here is to find KERN_DRVPTR for 5.0.0 and lower, since it's the missing piece to support those old firmwares. Ideally it'd be best to completely kill the OSDriver sploit off, you know? @dimok what's your take?

KERN_DRVPTR address should be for firmware
5.0.0 0xFFEA9BE0
4.1.0 0xFFEB8D94 I tested it, doesn't work ("Gadget not found!")
4.0.x 0xFFEB7BC4 see above

I attached a zip file with new payloads for these firmwares. Please report back if they are working

 

[Kafluke]

Yeah from what I saw it was the entry point. It never got to the code that is supposed to be executed. I did several versions for users to test and it didn't matter what I did there was no change. After some users added a sleep before building up the mvplayer in php everything worked with almost a 100% success rate with no change on the code side. I agree with the finding KERN_DRVPTR for all lower systems version being a way better solution but I am busy with other stuff and its not my top priority right now to support the old firmwares. Especially since everything that is being worked on is for 5.5.1 at the moment. I would though remove the OSDriver once all firmwares are supported by gx2sploit.
Anyway people on 5.5.1 that still have instability issues are probably not using the php in their browser but the mp4 file directly and that is instable because it is missing that necessary delay.

Is this a good enough reason to take the mp4 page off my AIO Self host package and force users of 5.5.1 to use php only?

 

[EclipseSin]

Is this a good enough reason to take the mp4 page off my AIO Self host package and force users of 5.5.1 to use php only?

Hmm, not to contradict dimok as he knows better than I, but the PHP method on 5.5.1 really does not like my Wii U. It always freezes at the mvplayer, even on nightly. The brewed MP4 gives me 100% though, even after save data reset. Sooo... *shrug* Could put both, mp4 as alt.

 

[ShadowOne333]

Hmm, not to contradict dimok as he knows better than I, but the PHP method on 5.5.1 really does not like my Wii U. It always freezes at the mvplayer, even on nightly. The brewed MP4 gives me 100% though, even after save data reset. Sooo... *shrug* Could put both, mp4 as alt.

Weren't you using the usual http://wiiubru.com for the mp4 exploit and http://wiiubru.com/x for the php method?

 

[the_randomizer]

However one thing I am noticing since upgrading to 5.5.1 is that launching the web browser from a fresh boot will cause the console to lock up on the home screen. After hard reboot (holding power) it comes back up fine. It's probably something in my method, but my conditions for this to happen are the following:
1. After running Loadiine 3.0 over XAMPP local network
2. Shutting down the console while Loadiine was still running in game (Color Splash in this example), or even closing out of the game and going to home screen
3. Turning the console back on and it will lock up about 50% of the time

I'm not sure if there's a way to properly close out of HBL in this example, but I have seen this happen a couple of times now.

I never had this issue, I have my page set up to load the exploit page every time.

 

[WulfyStylez]

That wait can actually be moved to the browser payload! Once I get a chance I might just look into integrating my stuff so I can PR it.
BTW, the new public iosu kernel code exec doesn't really mean much regarding our release plans/timeframe. Everything will still drop when it's done. I wouldn't personally spend too many hundreds of hours working on it tho since the work is already done! Of course it's not fair to say that while our stuff is still private and in development so... do whatever you want tbh.

 

[JaceCearK1]

@WulfyStylez At this point I wouldn't be surprised if your "IOSU-exploit+other stuff" release happened before Nintendo's NX-reveal!