Hacking Wii U Hacking & Homebrew Discussion

[jammybudga777]

So Kernel Exploit 5.5.0 is more STABLE than we thought and near to release, thank you for your leak..

???? He hasn't leaked anythin. And where was it mentioned about "near release"????

 

[Antonio Ricardo]

Ok

 

[AboodXD]

I'm just kidding. You guys dont have sense of humor.
A each day pass of corse is more near to release or im lying?
A smart guy will understand.

You mean stupid guy, days passing don't necessarily mean the release is near, that's what the smart guy will understand.

 

[oPolo]

Pretty dumb question but:
Is there any indication a method will be discovered allowing to skip cumbersome exploit steps to basically boot into a homebrew enabled state on the Wii U? 3DS discovered a method involving the Themes. I know the Wii U bootrom was dumped (along with some drama) something over a year ago, but does that even have any relevance with what we have now?

Not really permanent CFW which as I understand it is most likely impossible, but how unlikely is the 'next best thing' so to speak?

The Wii U checks the signatures of any application, whenever it runs them. This is unlike the Wii, which only checked them at installation time.
That gives the problem that even if we find a userspace, kernelspace or IOSU exploit, whenever we reboot the machine, we will have to run said exploit again first, in order to disable the signature checks.
If I am not mistaken of how IOSU fits in, an IOSU exploit will not allow us to dodge this, so therefore even with the IOSU exploit, we are still in the same boat whenever we reboot with regards to your question, and thus the odds are, well, not that great.
There is a slight hope though that via IOSU exploitation, we might tingle around with the chain of trust during boot, and thus disable that these checks are ever set in place. The chances are slim though, if I should personally guess.

 

[daicon]

The Wii U checks the signatures of any application, whenever it runs them. This is unlike the Wii, which only checked them at installation time.
That gives the problem that even if we find a userspace, kernelspace or IOSU exploit, whenever we reboot the machine, we will have to run said exploit again first, in order to disable the signature checks.
If I am not mistaken of how IOSU fits in, an IOSU exploit will not allow us to dodge this, so therefore even with the IOSU exploit, we are still in the same boat whenever we reboot with regards to your question, and thus the odds are, well, not that great.
There is a slight hope though that via IOSU exploitation, we might tingle around with the chain of trust during boot, and thus disable that these checks are ever set in place. The chances are slim though, if I should personally guess.

Well then I can only hope some interesting developments occure kind of like with the 3DS scene. Booting into wii u "emunand", what a dream!

 

[Sumea]

Sorry to just make a noob question and whatever but what currently seems to be prospects for Wii U hacking for near future? Say, possibility to install own apps on main screen and whatever else.

Say; if IOSU is released what would that enable beyond current kernel exploits and whatnot?

thanks for oPolo informing the security in Wii U again, sucks that everything cannot be PS3; A.K.A. The best worst security ever.

 

[Deleted-355425]

Sorry to just make a noob question and whatever but what currently seems to be prospects for Wii U hacking for near future? Say, possibility to install own apps on main screen and whatever else.

Say; if IOSU is released what would that enable beyond current kernel exploits and whatnot?

thanks for oPolo informing the security in Wii U again, sucks that everything cannot be PS3; A.K.A. The best worst security ever.

Everything! full access, all the way down to giving you head.

 

[Marionumber1]

Say; if IOSU is released what would that enable beyond current kernel exploits and whatnot?

You get full control of the system hardware, which allows things such as:
-Getting keys
-SD access in any app
-USB storage access
-emuNAND
-An easier way of running custom PPC kernels
-Modification/backup of vWii mode from within Wii U mode

 

[MrRean]

Waaaaaaait... you got the 5.5.0 exploit working? I could have sworn that NWPlayer123 said that he's the only one that got it working.

It's been working for a while now, uh...

anyways, link.ld is full of addresses I need to port...waaaaahhh

 

[LoganK93]

Wait wait wait, does this mean 5.5.0 is coming "soon"?

 

[Xinaman]

Soon™

 

[Azel]

Sorry to just make a noob question and whatever but what currently seems to be prospects for Wii U hacking for near future? Say, possibility to install own apps on main screen and whatever else.

If you can boot in emunand without sign checks, you can prolly install apps on emunand. (will have to boot through sysnand webrowser each coldboot though)

 

[Sumea]

If you can boot in emunand without sign checks, you can prolly install apps on emunand. (will have to boot through sysnand webrowser each coldboot though)

That would be VERY cool.

 

[oPolo]

Sorry to just make a noob question and whatever but what currently seems to be prospects for Wii U hacking for near future? Say, possibility to install own apps on main screen and whatever else.

Say; if IOSU is released what would that enable beyond current kernel exploits and whatnot?

thanks for oPolo informing the security in Wii U again, sucks that everything cannot be PS3; A.K.A. The best worst security ever.

Everything! full access, all the way down to giving you head.

Honestly, do not expect to be able to install anything on the mainscreen for the foreseeable future and run it. even if IOSU exploitation is achieved (and it would seem some bright minds either are looking or have looked into that), then that would still be some steps down the road.
I would not say anything (and thank God for that -- If my Wii U could give me head, I would have to sleep with my bedroom door locked in utter terror).

Maybe its worth it to explain shortly the difference between the IOSU and kernel to shine a light at, what can be done with IOSU. (Note: I might be wrong here and there, I have NOT looked much at the Wii U, so mostly just stating what I have understood based on what others have researched!)

• A userland exploit gives you access to execute your own code within the userspace of the running application.
• A kernel exploit gives you access to the memory outside the userspace of the running application. You could say that you break out of the userspace-sandbox that the operating system has imposed on the running app. This gives you access to the memory outside the sandbox and thus to new (editable) information and new functions. The name kernel exploit stems from the fact that the bare needed minimum (central component) of an operating system is called the kernel, and you can access that now.
  (This also explains why we need both a kernel and a userland exploit in tandem and not just a kernel exploit. We need to first be able to run our own code (userspace) and then we need a kernel exploit to escalate our privileges to the system.)
  (Fun fact. On the Wii, there was no operating system that isolated the running games from the hardware - the games ran directly on the hardware)

So, what is the IOSU then? The IOSU is a small operating system that most importantly enforces the code signing checks I mentioned earlier (i.e. checks when installing and running applications that they are legitly signed by Nintendo) and handles hardware access (apparently not the SD card though, since Loadiine works?).
The reason most probably want IOSU access in the end is so that we gain USB access and thus, we can run our own backups on them ... "own backups" <-- I hope you read that with a clear conscience! (Anyway it has its legitimate use.)
If we gain access to the IOSU, we could also install and run applications, but whenever we rebooted the system, we would have to run our userspace exploit again and escalate it to system privileges and gain IOSU access again to disable the checks. (Fun fact: The reason (I believe) that we normally use the webbrowser as vector to get to run our own code, is because the NX bit (https://en.wikipedia.org/wiki/NX_bit) is disabled for some reason for the webbrowser, so its a lot easier there... Oh, and it should be full of holes compared to the rest of the system).

The reason I said we do not gain access to everything is because, we still need to do this everytime --> there is no thing such as just "start the system and run the homebrew channel". In order to get this access, we would need to exploit the boot of the system so that they are never set in place. The Wii U loads the boot ROM as an ancast image to its processor and then starts the system boot by running that code. Even though we have the ancast decryption keys and thus the decrypted boot ROM, we have no way of signing our own ancast image and then changing the boot process. That's why I said the chances are slim at getting full access and a homebrew channel upon boot. Maybe its possible in some tricky way utilizing EmuNAND though, if the system is never shut completely down and only put to sleep! (can the wii u do that?)

Foods done, gotta go! I'm done doing this:


BTW: Most/all of this is on the wiki, though it does require some prior know-how to understand much of it: http://wiiubrew.org/wiki/Main_Page

Edit: I just read that Marcan some years ago said that a homebrew channel might be possible with a kernel exploit (https://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#comment-1349604346) -- I have no clue how, but take what I wrote with a grain of salt then.

 

[Antonio Ricardo]

Honestly, do not expect to be able to install anything on the mainscreen for the foreseeable future and run it. even if IOSU exploitation is achieved (and it would seem some bright minds either are looking or have looked into that), then that would still be some steps down the road.
I would not say anything (and thank God for that -- If my Wii U could give me head, I would have to sleep with my bedroom door locked in utter terror).

Maybe its worth it to explain shortly the difference between the IOSU and kernel to shine a light at, what can be done with IOSU. (Note: I might be wrong here and there, I have NOT looked much at the Wii U, so mostly just stating what I have understood based on what others have researched!)

• A userland exploit gives you access to execute your own code within the userspace of the running application.
• A kernel exploit gives you access to the memory outside the userspace of the running application. You could say that you break out of the userspace-sandbox that the operating system has imposed on the running app. This gives you access to the memory outside the sandbox and thus to new (editable) information and new functions. The name kernel exploit stems from the fact that the bare needed minimum (central component) of an operating system is called the kernel, and you can access that now.
  (This also explains why we need both a kernel and a userland exploit in tandem and not just a kernel exploit. We need to first be able to run our own code (userspace) and then we need a kernel exploit to escalate our privileges to the system.)
  (Fun fact. On the Wii, there was no operating system that isolated the running games from the hardware - the games ran directly on the hardware)

So, what is the IOSU then? The IOSU is a small operating system that most importantly enforces the code signing checks I mentioned earlier (i.e. checks when installing and running applications that they are legitly signed by Nintendo) and handles hardware access (apparently not the SD card though, since Loadiine works?).
The reason most probably want IOSU access in the end is so that we gain USB access and thus, we can run our own backups on them ... "own backups" <-- I hope you read that with a clear conscience! (Anyway it has its legitimate use.)
If we gain access to the IOSU, we could also install and run applications, but whenever we rebooted the system, we would have to run our userspace exploit again and escalate it to system privileges and gain IOSU access again to disable the checks. (Fun fact: The reason (I believe) that we normally use the webbrowser as vector to get to run our own code, is because the NX bit (https://en.wikipedia.org/wiki/NX_bit) is disabled for some reason for the webbrowser, so its a lot easier there... Oh, and it should be full of holes compared to the rest of the system).

The reason I said we do not gain access to everything is because, we still need to do this everytime --> there is no thing such as just "start the system and run the homebrew channel". In order to get this access, we would need to exploit the boot of the system so that they are never set in place. The Wii U loads the boot ROM as an ancast image to its processor and then starts the system boot by running that code. Even though we have the ancast decryption keys and thus the decrypted boot ROM, we have no way of signing our own ancast image and then changing the boot process. That's why I said the chances are slim at getting full access and a homebrew channel upon boot. Maybe its possible in some tricky way utilizing EmuNAND though, if the system is never shut completely down and only put to sleep! (can the wii u do that?)

Foods done, gotta go! I'm done doing this:


BTW: Most/all of this is on the wiki, though it does require some prior know-how to understand much of it: http://wiiubrew.org/wiki/Main_Page

Edit: I just read that Marcan some years ago said that a homebrew channel might be possible with a kernel exploit (https://fail0verflow.com/blog/2014/console-hacking-2013-omake.html#comment-1349604346) -- I have no clue how, but take what I wrote with a grain of salt then.

But run Exploit every time when turn on WIIU is just like 3ds scene to boot Emunand?
But you & team obcjective is beyond this, i understood right? Is run one time and dont need to do again.

 

[Sumea]

Yeah, most from your facts about kernel exploit and onward I knew, even that Wii U does not have any real Firmware or Operating system and instead has it's iOS system which is like having multiple different bioses on same machine or something among those lines.

What I understand about the non-sandboxing of Browser; My friend knowledgeable about current PPC architectures says the processor itself can lock out a lot of stuff and is physically made to be able protect execution of code; and for whatever reason web browser is not under this. What he surmised; was that it is that way only to keep it working faster; so nintendo opted to lessen the security for user experience in this case.

But yeah I seen presentations from fail0verflow about both PS3 and Wii U. They also explain Wii security a lot in Wii U one so the bottomline is; Wii U just has very solid security so yeah, we may need to do web browser exploits for now.

I mean we know Xbox 360 security is almost idiot proof, piracy has been enabled on it but nothing further and those get patched to hell. eFuses EMBEDDED TO THE CPU, holy heck.

We know PS3 is the way it is because it's security is just botched, most legendary being "generate random number; Random number = 4"


But even without the permanence of it; a IOSU exploit would make me moist, though seems like there is not one being looked to be done on 5.3.2 at least right away. Still what it could enable makes me moist. It also probably would enable... better "Backups" indeed, probably also online too.

 

[oPolo]

Yeah, most from your facts about kernel exploit and onward I knew, even that Wii U does not have any real Firmware or Operating system and instead has it's iOS system which is like having multiple different bioses on same machine or something among those lines.

What I understand about the non-sandboxing of Browser; My friend knowledgeable about current PPC architectures says the processor itself can lock out a lot of stuff and is physically made to be able protect execution of code; and for whatever reason web browser is not under this. What he surmised; was that it is that way only to keep it working faster; so nintendo opted to lessen the security for user experience in this case.

But yeah I seen presentations from fail0verflow about both PS3 and Wii U. They also explain Wii security a lot in Wii U one so the bottomline is; Wii U just has very solid security so yeah, we may need to do web browser exploits for now.

I mean we know Xbox 360 security is almost idiot proof, piracy has been enabled on it but nothing further and those get patched to hell. eFuses EMBEDDED TO THE CPU, holy heck.

We know PS3 is the way it is because it's security is just botched, most legendary being "generate random number; Random number = 4"


But even without the permanence of it; a IOSU exploit would make me moist, though seems like there is not one being looked to be done on 5.3.2 at least right away. Still what it could enable makes me moist. It also probably would enable... better "Backups" indeed, probably also online too.

Hahah yea, the xbox 360 had some pretty impressive security... Apart from being able to activate JTAG on older xbox's, the security were wild from a software point-of-view. However, even the exploit found there, was unable to be completely patched away by them (as it lied in the processor-architecture (= how it handled pulses on the RST pin of different lengths))

Also, I would definitely not say the security of the PS3 was botched. After all, despite the mistake in the signing of their firmware being huge, it after all took 4(ish?) years to break that security, which made the PS3 the longest-lasting non-jailbroken console of the last generation
Honestly, regardless of how big the mistake on Sonys part were (it was (very) big), I still consider the feat by fail0verflow of finding that flaw in the crypto and mapping the PS3 system and chain-of-trust, as one of the most impressive done on the PS3 scene (ECDSA is state-of-the-art cryptology, they just implemented it wrong)...
The counter by Sony (moving everything from the metldr to lv0) was nicely thinking as well ... They were just dun goofed when the lv0 loader was comprised, as they had no more higher modifiable to go on the old ps3's

Note: Yes, that makes me moist as well :3

Edit: Those e-fuses was pretty crazy Made me lose a good Jasper Xbox once due to too high firmware ._. The first console i ever soldered also... And it went horribly, so maybe its good it became useless for me I botched the soldering so much that the solder-pad broke off, and I had to scratch the trace free and solder the wire to that >_< https://dl.dropboxusercontent.com/u/13685979/xBOX SOLDER IMAGES/2012-10-27 02.44.23.jpg
...Something cool came out of the spareparts though! http://www.se7ensins.com/forums/thr...0-controller-wireless-receiver-for-pc.668839/
I can now connect xbox controllers to my PC wirelessly! Each time me and my friends plays Mario Party 3 on an emulator, we do that

 

[Azel]

will iosu available to 5.3.2 or only 5.5 btw?
(I suppose iosu will be patched on 5.6, so 5.3.2 ppl wont have much time to update online to 5.5 once iosu hack is out, I think)

Edit : jtaged my Jasper too, yeah, those pads were a bitch to solder on.. mine is still alive and kicking though, with a digital spdif sound output in the back too^^

 

[Sumea]

Also, I would definitely not say the security of the PS3 was botched. After all, despite the mistake in the signing of their firmware being huge, it after all took 4(ish?) years to break that security, which made the PS3 the longest-lasting non-jailbroken console of the last generation

So what, having official linux is now considered good security measure. I mean yeah but that is all there was for it. From moment sony did not provide linux support on PS3 slim it took just the same time it took to hack wii with PS3. Only reason hackers did not care to dig into PS3 was it having linux support officially so hackers got to use the hardware semi-freely, and from moment sony started locking on that service was the moment hackers got on their knees and it took no time from people to figure out PS3, and it's security IS a terrible, terrible mess. "We have a CPU that has native sandboxing and security to it so let's utilize NONE OF IT" and other great ideas like securing out packages with a randomizer that always returns the SAME "random" number,

 

[gamesquest1]

So, what is the IOSU then? The IOSU is a small operating system that most importantly enforces the code signing checks I mentioned earlier (i.e. checks when installing and running applications that they are legitly signed by Nintendo) and handles hardware access (apparently not the SD card though, since Loadiine works?).

nope loadiine works as it runs under the permissions of a game that does have SD access, i.e smash bros or miimaker, basically the way i understand it is the IOSU loads up the basic "preload/global" config, i.e loading up titleID,miiverse setup, access permissions games title, DLC options if online access is enabled etc etc, then access is handed over to kernel for loading up game specific stuff, memory mapping etc this is where loadiine jumps in and takes control of memory mapping etc, but the "preload config" has already been done by iosu and cant be changed leaving the system thinking its running smash bros or miimaker, but any IOSU settings are locked in already which is why DLC/legitimately installed updates/online/miiverse/ etc doesnt work as its using the meta xml from the originally launched game

which is why loadiine depends on a game that has SD access already as this is also defined by IOSU settings, and currently afaik no games even allow USB access which is why every thing relies on SD cards atm