Hacking Wii U Hacking & Homebrew Discussion

[Deleted User]

Ok guys I'm a total noob about Wii U, I don't own one but I'm willing to get one soon. If I got it right, by reading some threads here, it's possible to fully hack the system even on the latest firmware. Is that correct?

Not really fully. You can't have EmuNAND , homebrew on home menu , run code on boot (like with A9LH on 3ds) but we can load ROMs, run VC games, load homebrews, use emulator, region free, etc...

 

[EclipseSin]

I may or may not be a little blind, but can I ask where did you hear that news if it wasn't from here nor from SALT?
I haven't been in the Wii U scene for a while due to the sheer toxicity it got to at one point, but I'm willing to follow it again since things seem to be more toned down and mellow surrounding news and hype and stuff...

Every scene is Toxic if you pay attention to scrubs.

@shinyquagsire23 Anyway, I've been watching wut on github for a while, I guess you are saying we should start preparing homebrew apps as RPX instead of HBL elfs? I thought loadiine could load RPX homebrew anyway. So what exactly is new here? Not being rude, just trying to understand the difference here than loading them under loadiine.

Meh, I'm just going to assume it's the same thing I mentioned. Hope everything is going good for you guys though.

 

[Deleted User]

Every scene is Toxic if you pay attention to scrubs.

That is understandable; I know exactly where you're coming from because I did sort of focus a little more on the haters/shit-stirrers back then (it's hard not to, most of the time here), but when I mention that I left after "the sheer toxicity it got to at one point", I'm referring to the fact that it was literally unavoidable and they were riddling in the majority of biggest news/shit/clickbait/development threads, where the big bulk of the community would mostly gather daily.

But I digress anyways - those days are over, things are definitely more calm than what they originally were, and SALT are still silently working on the IOSU exploit and tools, delivering the progressments professionally without generating much over-hype.
I suppose most of the trolls and general annoyances just leapt back into their caves and bunkers when things died down... It's been proven to happen in every other scene one time or another as well, so feel free to ignore me if I'm stating the downright-painful obvious.


Going off-topic- I'd also like to mention that the UI showcased in that PoC video looks absolutely ace! Also really looking forward to the file browsing as well; and I understand there'll be some even greater tools on the horizon soon too! SALT really have outdone themselves this time; a massive kudos to them indeed!

 

[davetheshrew]

That is understandable; I know exactly where you're coming from because I did sort of focus a little more on the haters/shit-stirrers back then (it's hard not to, most of the time here), but when I mention that I left after "the sheer toxicity it got to at one point", I'm referring to the fact that it was literally unavoidable and they were riddling in the majority of biggest news/shit/clickbait/development threads, where the big bulk of the community would mostly gather daily.

But I digress anyways - those days are over, things are definitely more calm than what they originally were, and SALT are still silently working on the IOSU exploit and tools, delivering the progressments professionally without generating much over-hype.
I suppose most of the trolls and general annoyances just leapt back into their caves and bunkers when things died down... It's been proven to happen in every other scene one time or another as well, so feel free to ignore me if I'm stating the downright-painful obvious.


Going off-topic- I'd also like to mention that the UI showcased in that PoC video looks absolutely ace! Also really looking forward to the file browsing as well; and I understand there'll be some even greater tools on the horizon soon too! SALT really have outdone themselves this time; a massive kudos to them indeed!

il pm you voxel

 

[shinyquagsire23]

Every scene is Toxic if you pay attention to scrubs.

@shinyquagsire23 Anyway, I've been watching wut on github for a while, I guess you are saying we should start preparing homebrew apps as RPX instead of HBL elfs? I thought loadiine could load RPX homebrew anyway. So what exactly is new here? Not being rude, just trying to understand the difference here than loading them under loadiine.

Meh, I'm just going to assume it's the same thing I mentioned. Hope everything is going good for you guys though.

RPX is important if you want to launch applications natively, with multitasking, as a standalone app (like the System Settings app or whatever). I have no doubt that forwarders and whatever could possibly work, but RPX is much more optimal here. Don't have to deal with dynamically pulling in every single function you want to use and there's larger limits on code size. If you were porting something like, say, ScummVM, you would have a lot more breathing room with RPX. If someone wants to work on some kind of RPX->.elf bootstrap then they can go right ahead with that, but I'd rather focus on wut.

 

[vgmoose]

If anyone's interested in .tga code or a good button interface let me know, I might put up another sample project from what I have.

Me! I am interested. Although, I've had no real complaints using dimok's libraries for creating buttons.

We haven't ported HBL to wut, although if anyone were to do it it would probably end up being me since I've been working on userland for the most part. HBL would be nice for legacy apps I suppose, although it'd be better to see ports to .rpx

I guess this along the same vein, demonstrating what an HBL port looks like would help tremendously for a lot of homebrew that is based on dimok's libraries. For example, I have a wut branch of Space Game, which works fully except it has no music. This is because I don't know how to play music without using code from dimok, which I had trouble getting to compile under wut (maybe having to do to it being C++?).

EDIT: Or should loading music be done by opening files from other folders instead of embedding them into the RPX?

 

[shinyquagsire23]

Me! I am interested. Although, I've had no real complaints using dimok's libraries for creating buttons.


I guess this along the same vein, demonstrating what an HBL port looks like would help tremendously for a lot of homebrew that is based on dimok's libraries. For example, I have a wut branch of Space Game, which works fully except it has no music. This is because I don't know how to play music without using code from dimok, which I had trouble getting to compile under wut (maybe having to do to it being C++?).

EDIT: Or should loading music be done by opening files from other folders instead of embedding them into the RPX?

I'd personally suggest loading assets from content/ since it's a lot cleaner. I haven't managed to get any of dimok's stuff to compile with wut, but chances are a modified version of wut or dimok's libs would be required for that to work (specifically libcrt conflicts with its devoptab and coreinit/GX2 almost definitely conflicts), mostly because wut's function definitions and structures are derived from decaf which has to derive everything without any use of the SDK whatsoever. So there's a funky incompatibility there and I've moved to avoiding dimok's libraries because they're, frankly, pretty sketchy and almost definitely derived from the SDK, and for public release tools I would like to be in the best legal standing as possible.

 

[vgmoose]

I'd personally suggest loading assets from content/ since it's a lot cleaner. I haven't managed to get any of dimok's stuff to compile with wut, but chances are a modified version of wut or dimok's libs would be required for that to work (specifically libcrt conflicts with its devoptab and coreinit/GX2 almost definitely conflicts), mostly because wut's function definitions and structures are derived from decaf which has to derive everything without any use of the SDK whatsoever. So there's a funky incompatibility there and I've moved to avoiding dimok's libraries because they're, frankly, pretty sketchy and almost definitely derived from the SDK, and for public release tools I would like to be in the best legal standing as possible.

To clarify, the dimok libraries I'm referring to are the userland things, for example SoundHandler.cpp and GameSound.cpp have both been adapted from libwiigui/WiiXplorer. And comparing the GuiButton.cpp used in HBL with the gui_button.cpp from libwiigui the similarities can be seen. It's my understanding that these same libwiigui-style APIs should be compatible/portable with/to wut if they are implemented correctly, which would make transitioning for HBL-based apps much easier.

If that's off the table, however, I personally don't have a real issue switching to use new libraries (and helping port some legacy ELFs to RPX), but would need some examples, like the button/layout one that you've demonstrated/mentioned, or one that shows how sound can be played from content/.

(btw thanks for the answer, I had been wondering why dimok's contributions had oddly been mostly ignored. (although I choose to believe they're legit)).

 

[EclipseSin]

RPX is important if you want to launch applications natively, with multitasking, as a standalone app (like the System Settings app or whatever). I have no doubt that forwarders and whatever could possibly work, but RPX is much more optimal here. Don't have to deal with dynamically pulling in every single function you want to use and there's larger limits on code size. If you were porting something like, say, ScummVM, you would have a lot more breathing room with RPX. If someone wants to work on some kind of RPX->.elf bootstrap then they can go right ahead with that, but I'd rather focus on wut.

Yes, I figured that is what you were saying after I had read it again, thanks for clarification though.

 

[epicmartin7]

Huh.

https://www.reddit.com/r/WiiUHacks/comments/55o9fq/wii_u_otp/

Someone is claiming that they dumped the Wii U's OTP with team SALT's tools. Kinda' cool.

 

[SciresM]

This could technically mean CFW on cold boot if legit (which I wouldn't really doubt considering people have had time to figure out this kind of thing.)

Ugh. OTP dumping does not imply CFW on cold boot. OTP dumping on the 3ds enables one to exploit a vulnerability in Kernel9loader that gives coldboothax on the 3DS -- the OTP itself has nothing to do with coldboothax outside of that context. It stands for One Time Programmable -- it's just some data that's written on a per-console basis at the factory that you need privileged execution to read. The wii u does not use Kernel9loader for obvious reasons (namely that it does not run Kernel9 or other 3DS firmware files), and so dumping OTP on the wii u would in *no way* enable coldboothax.

Please don't spread misinformation.

 

[VinsCool]

Huh.

https://www.reddit.com/r/WiiUHacks/comments/55o9fq/wii_u_otp/

Someone is claiming that they dumped the Wii U's OTP with team SALT's tools. This could technically mean CFW on cold boot if legit (which I wouldn't really doubt considering people have had time to figure out this kind of thing.)

That totsnotryan guy though.

 

[epicmartin7]

Ugh. OTP dumping does not imply CFW on cold boot. OTP dumping on the 3ds enables one to exploit a vulnerability in Kernel9loader that gives coldboothax on the 3DS -- the OTP itself has nothing to do with coldboothax outside of that context. It stands for One Time Programmable -- it's just some data that's written on a per-console basis at the factory that you need privileged execution to read. The wii u does not use Kernel9loader for obvious reasons (namely that it does not run Kernel9 or other 3DS firmware files), and so dumping OTP on the wii u would in *no way* enable coldboothax.

Please don't spread misinformation.

Sorry for the misinformation. I was just basing it off of this reply in the Reddit thread.

I did see this reply before it was extremely downvoted, so I thought it had some merit to it. I'll look into it more when I post things next time. My bad.

 

[KungFuzion]

We'll just have to see what Team Salt have up their sleeves. I'm sure it's all going to be worth while

 

[Bug_Checker_]

Huh.

https://www.xxxxxx.com/r/WiiUHacks/comments/xxxxxx/wii_u_otp/

Someone is claiming that they dumped the Wii U's OTP with team SALT's tools. Kinda' cool.

That totsnotryan guy though.

You both realize that you are linking to a page that has a link to a paste bin page that has Wii U keys(some which have not been publicly released before)?

 

[shinyquagsire23]

You both realize that you are linking to a page that has a link to a paste bin page that has Wii U keys(some which have not been publicly released before)?

Yeah and ReiNAND links to a Github which has a crappily encrypted Nintendo key. The mods here don't care as long as they get their ad revenue. They only actually start taking things down if they get a DMCA request. Gotta love GBATemp's crap morals.

 

[Bug_Checker_]

Yeah and ReiNAND links to a Github which has a crappily encrypted Nintendo key. The mods here don't care as long as they get their ad revenue. They only actually start taking things down if they get a DMCA request. Gotta love GBATemp's crap morals.

Actually, some are better than others.
In one of the Wii U Amiibo NFC threads, they actually delete 2 posts because someone mistakenly ( or it was reported and they didn't know better) thought a sha1 hash of one of the key bin structures was a key and not a hash.

p.s.
btw for others not aware:
20 bytes usually a hash (most likely sha1)
16 bytes usually a key.

 

[VinsCool]

Yeah and ReiNAND links to a Github which has a crappily encrypted Nintendo key. The mods here don't care as long as they get their ad revenue. They only actually start taking things down if they get a DMCA request. Gotta love GBATemp's crap morals.

Well to be fair, it was not posted directly here. It was on Pastebin, that was linked on Reddit. At this point it wasn't linked directly here, therefore not illegal.

It's pretty much like saying "the rom is found at that iso site you could retrieve from Google". It's mentioned, but not directly.

 

[Quantumcat]

Yeah and ReiNAND links to a Github which has a crappily encrypted Nintendo key. The mods here don't care as long as they get their ad revenue. They only actually start taking things down if they get a DMCA request. Gotta love GBATemp's crap morals.

My understanding was that gbatemp does not want any analytics to show up that there are links to copyright material on its site. So you're free to talk about it all you want and hint about where to find it as long as there's no actual link. I don't think it has anything to do with morals.
Second-hand links must be OK because firmware.bin is downloadable from a link in Luma's wiki and of course there's plenty of links to Luma's GitHub on gbatemp.

 

[TheZander]

so going by tjis http://wiiubrew.org/wiki/Hardware/OTP which keys wernt public?

 

[ZambieVu]

If WiiU is a new venture for you, you should also look into blocking the WiiU update servers (there's several threads here that mention them). There's 6 in total but I don't remember them off hand. A forum search should turn them up. Optionally there's also TubeHax DNS you can look for, but I'm not sure if it's still usable or not as the first method I mentioned is more "full proof".

Thanks, I just did both TubeHax DNS and OpenDNS following by this tutorial:

https://gbatemp.net/threads/tutorial-blocking-wiiu-update-domains-with-opendns.385996/

However there is 1 suggestion of installing OpenDNS Dynamic IP updater into 1 PC (Not a laptop that bring around) but I dont have one so is there any problem without having that software?