Hacking Wii U Hacking & Homebrew Discussion

[FR0ZN]

You don't need a hack for that ... Nintendo provided this feature from the start.

 

[Hykem]

Indeed.

If I can help with my still 2.1.0E Wii U, I wield my iron, and write my codex with great Qapla'! (Meaning: I can solder and code just fine )

Edit:
Again, though, how and at what moment do you guys make a memory dump, to port/create the ROP chain?

Don't worry, I'm porting the UAF bug to firmwares 2.x.x as well. All I need is coreinit's and libwkc's base addresses, which I've already requested to someone who has a unit on the exact same firmware.
Either way, I would really appreciate if you could give it a try on your 2.1.0 after I implement it since not many people are still on such a low firmware version.

Regarding your question, the memory dump is almost always the first step. From firmware 4.0.0 to 5.1.0 we went straight to ROP chain building thanks to analyzing crash logs from a devkit.
However, back porting the bug to 3.x.x was not that straightforward since I couldn't find anyone with a devkit on that firmware range. Luckily, using a combination of blind exploitation (guessing the addresses of several functions by analyzing the binaries from NUS) and a heap-overflow exploit (similar to comex's) I could analyze just enough of the memory to find the base addresses of the modules needed for the ROP chain.
The whole process required combining a total of 3 different exploits: 2 use-after-frees and 1 heap-overflow.

You won't have to go through this tedious process since the WebKit source code used on 3.x.x is the same in use on 2.x.x. Which means, the same exact exploit plan can be applied and the UAF bug can be ported in hours (specially if the same ROP gadgets still exist, which is unlikely).

 

[Deleted User]

Are we getting anything tommorow.
Just curious.

 

[naxil]

it's possible use devkit with retail console?

 

[Adr990]

Don't worry, I'm porting the UAF bug to firmwares 2.x.x as well. All I need is coreinit's and libwkc's base addresses, which I've already requested to someone who has a unit on the exact same firmware.
Either way, I would really appreciate if you could give it a try on your 2.1.0 after I implement it since not many people are still on such a low firmware version.

Regarding your question, the memory dump is almost always the first step. From firmware 4.0.0 to 5.1.0 we went straight to ROP chain building thanks to analyzing crash logs from a devkit.
However, back porting the bug to 3.x.x was not that straightforward since I couldn't find anyone with a devkit on that firmware range. Luckily, using a combination of blind exploitation (guessing the addresses of several functions by analyzing the binaries from NUS) and a heap-overflow exploit (similar to comex's) I could analyze just enough of the memory to find the base addresses of the modules needed for the ROP chain.
The whole process required combining a total of 3 different exploits: 2 use-after-frees and 1 heap-overflow.

You won't have to go through this tedious process since the WebKit source code used on 3.x.x is the same in use on 2.x.x. Which means, the same exact exploit plan can be applied and the UAF bug can be ported in hours (specially if the same ROP gadgets still exist, which is unlikely).

Thanks for your extensive answer.
And sure, count me in for some testing.

About the memory dump, I see, sounds like it can be tedious indeed.
I assume the memory dump would be made directly after the browser is fully loaded? And would require special hardware to flip over the memory and read it out? (or even write to it)

I know the USB/TCP Gecko make it easy to do on a already 'hacked' system, but I don't know how to go about it without that if I wanted to. hah

 

[zecoxao]

what's the size of the OTP, in case anyone knows? been wondering how many attempts it'd take to get the keys judging by the size of the otp

 

[Marionumber1]

what's the size of the OTP, in case anyone knows? been wondering how many attempts it'd take to get the keys judging by the size of the otp

We already have every key except for the vWii common key and the ARM ancast key. Both of those are AES128 (16-byte) keys, which are very implausible to brute-force the hashes of.

 

[mustafag32g]

so when do we get a release :** lol

 

[Marionumber1]

so when do we get a release :** lol

We have code execution on CPU0, and there's just one more apparent hurdle to overcome, getting it on CPU1. It shouldn't be long, stay tuned.

 

[zecoxao]

We already have every key except for the vWii common key and the ARM ancast key. Both of those are AES128 (16-byte) keys, which are very implausible to brute-force the hashes of.

i'm asking because i'm in talk with Hykem and he said he's in the OTP part. the function can read 0x20 bytes of the OTP, but he doesn't know the exact size of it, hence why i asked. we believe it's 0x200, but we're not sure

 

[Marionumber1]

i'm asking because i'm in talk with Hykem and he said he's in the OTP part. the function can read 0x20 bytes of the OTP, but he doesn't know the exact size of it, hence why i asked. we believe it's 0x200, but we're not sure

fail0verflow's blog post claims that it's 1KB (0x400 bytes).

 

[kardus]

After a kernel/iosu exploit for a particular version (lets say 5.3.2) is released, how likely is it that something like Emunand will be released soon after? I'm sure most people want USB loading etc but something like emunand should be high priority because it will allow people to still enjoy the console whilst waiting for other stuff to be developed for the older firmware.

Emunand will also be nice because assuming there's no way to downgrade, the people who updated for 5.4 or beyond will presumably be able to just buy new consoles and do a system transfer to emunand on one of the splatoon 5.3.2 native consoles.

 

[Slartibartfast42]

Hahahahahaha! Omg hahahahahahahah!!!

You realize that even after the exploit is released, backup loaders are still like 6 months away. There is no IOSU exploit yet, and of course, no loader software.

 

[2Hack]

After a kernel/iosu exploit for a particular version (lets say 5.3.2) is released, how likely is it that something like Emunand will be released soon after? I'm sure most people want USB loading etc but something like emunand should be high priority because it will allow people to still enjoy the console whilst waiting for other stuff to be developed for the older firmware.

Emunand will also be nice because assuming there's no way to downgrade, the people who updated for 5.4 or beyond will presumably be able to just buy new consoles and do a system transfer to emunand on one of the splatoon 5.3.2 native consoles.

Sooner than the 3ds exploit I think. Gateway was closed source and that slowed it down so much I expect. Since this exploit will be open source iirc, then I presume we will have some nice pace on it but I still think it will take awhile for it

I totally see a backup loader being released within a week of the exploit though. That will have more demand; at least for the first months.

 

[VinsCool]

You realize that even after the exploit is released, backup loaders are still like 6 months away. There is no IOSU exploit yet, and of course, no loader software.

My laughtiung was exactly about this...

 

[Willemoke]

I'm thinking of buying a Japanese WiiU after playing taiko no tatsujin on it at a convention last weekend. I've wanted a japanese WiiU for a long time, but I've been waiting ( and hoping ) that someday a Region Exploit would be released. I already own 1 US console on the latest firmware and 1 Pal console on the latest firmware, 1 pal console on firmware 1.0.0E and 1 pal console on 1.0.3E. I've kept 1 since launch, hoping for a region hack ( the firmware 1.0.0E version).

My question is, could this hack lead anywhere near a region hack, or should I just import a Japanese WiiU ( which I rather don't, because importing one to the Netherlands would cost me around 400 euros).

Thanks!

 

[NWPlayer123]

I'm thinking of buying a Japanese WiiU after playing taiko no tatsujin on it at a convention last weekend. I've wanted a japanese WiiU for a long time, but I've been waiting ( and hoping ) that someday a Region Exploit would be released. I already own 1 US console on the latest firmware and 1 Pal console on the latest firmware, 1 pal console on firmware 1.0.0E and 1 pal console on 1.0.3E. I've kept 1 since launch, hoping for a region hack ( the firmware 1.0.0E version).

My question is, could this hack lead anywhere near a region hack, or should I just import a Japanese WiiU ( which I rather don't, because importing one to the Netherlands would cost me around 400 euros).

Thanks!

Yes, but it might take a while to get out. Also, 1.X firmware is pretty useless as it doesn't even have a usable browser for easy exploitation. I admire your dedication though Could probably trade in one and just get a Japanese one if you really wanted. All our stuff is targeted to be as high of a firmware as possible (which at this moment is 5.4.0), Hykem's just on a lower version for the moment because there is proven stuff on that version that he's using to get info for the latest versions.

 

[the_randomizer]

Yes, but it might take a while to get out. Also, 1.X firmware is pretty useless as it doesn't even have a usable browser for easy exploitation. I admire your dedication though Could probably trade in one and just get a Japanese one if you really wanted. All our stuff is targeted to be as high of a firmware as possible (which at this moment is 5.4.0), Hykem's just on a lower version for the moment because there is proven stuff on that version that he's using to get info for the latest versions.

So is 5.4.0 still a firmware we should avoid, i.e. still confirmed as unsafe to update to?

 

[NWPlayer123]

So is 5.4.0 still a firmware we should avoid, i.e. still confirmed as unsafe to update to?

Well considering how much all of you complained about how we don't even have code execution, I'm gonna just say stay on 5.3.2 until we tease you with a 5.4.0 Webkit exploit

 

[the_randomizer]

Well considering how much all of you complained about how we don't even have code execution, I'm gonna just say stay on 5.3.2 until we tease you with a 5.4.0 Webkit exploit

This is one of many times that we deserve being called out and ridiculed, it would seem. C'est la vie...