Hacking Coding vWii 3-core support - everything you need to know.

[Shadow LAG]

I wouldn't worry about bricking unless I was messing with the NAND. Or messing willy-nilly with IOS-U, the way I bricked my first Wii U

Well as state above it was never confirmed rather or not the fans would behave properly when the status of cores change. Excess heat and CPU degradation is definitely something to be worried about. IMO that could be a lot more serious than a soft brick.

 

[comex]

I do not know for sure, but the fan thing sounds highly implausible to me.

 

[Shadow LAG]

I agree but its best to confirm before wasting hardware
Better safe than sorry I always say.

 

[Shadow LAG]

I seriously doubt the Wii U is using anywhere near the encryption that Xbox 360 is using. If it was everything would be encrypted by this public key and so far from the progress I have seen such as reading/writing to memory I seriously doubt it. Also he said his first Wii U so I don't assume he fixed it, but if he did it was most likely due to the fact he had his nand dumped.

 

[the_randomizer]

The more testers, the better; just say the word.

 

[comex]

How did you fix it?

I didn't!

 

[Maxternal]

Okay, I finally found a moment to update the OP code with some of the feedback I've been getting. Hope it's a little more readable now, too. I downloaded libogc's code but I haven't taken the time to dig through it and figure out where the _init() is (or where ever the pre- main() init code is) so it's still missing that. Finding time is always the hard part with me.

I didn't!

Okay, I guess we'll have to be careful when we get to the part where we have to run ARM code for a bit. Patching code in memory (although a very interesting challenge) sounds tricky. I had originally thought of just packing the Wii's bootmii IOS into a WAD and try installing to to mix a modded nSwitch and modded mini ...
BUT
if playing with the IOS is that risky like that, though, I think I'll try my hand at replacing and calling some IOS function in memory instead. (sounds fun ... but a little tricky with my lack of experience)

EDIT : it's either that or add something to D2X's code and install another cIOS for this. ... not as exciting as memory patching, though.

 

[Maxternal]

Maybe if he had dumped his console-specific keys first they could have made a replacement NAND dump for him or fixed the one he already had. Without the keys before hand, though it's kinda hard to do anything. The fix you write to the NAND chip would have to be encrypted with that key for it to be accepted and if it's bricked you can't really run an app on it to GET the keys anymore so you're screwed.

 

[Shadow LAG]

being able to decrypt it is powerful. Lol, concealment? You may not have fixed it but I bet it WAS fixed, lol.

You do realize that even if a NAND is encrypted if you have a raw dump of it you don't need to decrypt it to re-write it if something goes wrong right? I'm guessing he did not have a raw backup considering he said his "first wii U" which means he probably has another which means he no longer retains his old one. Just my take on it.

 

[comex]

I saw Sven's pictures of playing with what looked like eMMC (nand) stuff. Lol, if you crashed your Wii U, surely Marcan could have fixed it. Nand, a way to write/read it, being able to decrypt it is powerful. Lol, concealment? You may not have fixed it but I bet it WAS fixed, lol.

Not concealment. I was not able to dump keys at the time and soldering would be no easy job in any case.

edit: in fact, I'm not totally sure that restoring the NAND would fix it.

 

[Shadow LAG]

edit: in fact, I'm not totally sure that restoring the NAND would fix it.

Curious?

 

[comex]

I am shocked though, you of all people would warn about messing with IOS stuff. My mind would think the best way is to dump nand, all ios stuff, find vulnerability, have keys, have way to recover, then play.

Well, I personally can't solder to a target the size of a barn, so I of all people ought to be especially careful with IOS - doesn't mean I can't mess with it, just that I should have been a bit more cautious. Or less unlucky - what I was doing wasn't supposed to be dangerous...

 

[comex]

I wonder if Wii U has like the efuse crap on it? Once you have one version, cannot go back (blows fuses)? Never looked at this or looked around for it. Marcan would know, lol. Wonder if there is other security also, like that checks the nand specifically to see if it has been modded?

Not as far as I know.

 

[cory1492]

Great little exploit to gain access to the vwii loader, I guess it explains why that gecko was hacked onto the mobo. Does the region become RO or something after verification is complete thus limiting the time you have to patch it in? I'd think it'd be simpler to patch out the offending instructions that disable the other cores, then proceed to load a wii binary (via the existing loader) that handles putting them into a wait loop instead of trying to bypass and reimplement the loader all together..?

I downloaded libogc's code but I haven't taken the time to dig through it and figure out where the _init() is (or where ever the pre- main() init code is) so it's still missing that. Finding time is always the hard part with me.

http://sourceforge.net/p/devkitpro/libogc/ci/master/tree/libogc/ogc_crt0.S
http://sourceforge.net/p/devkitpro/libogc/ci/master/tree/libogc/system_asm.S
Most of what you'd be looking for can probably be found in there and the other .S files in libogc\libogc\, crt0 is typically the entry point (_start that inits things like heap and stack (bss/sbss) and any common hardware that needs to be set up, before it eventually calls main().

 

[Crewman]

The updated code looks pretty awesome.

But the if(core==1) line make me think, there should be a 3 times loop, one for each core.

You should jump from

// Core is now initialized. Check core ID (upir) and jump to wherever

to

endif1

Edit:
Increment upir before you jump back

 

[comex]

I'd think it'd be simpler to patch out the offending instructions that disable the other cores, then proceed to load a wii binary (via the existing loader) that handles putting them into a wait loop instead of trying to bypass and reimplement the loader all together..?

1-200 is big, but only because it does a lot of work involving loading the relevant files for a new application from NAND or DVD and whatnot, none of which you want. You don't even want to 'load' anything, just do some basic reinitialization and jump back to the already-loaded application.

Increment upir before you jump back

The same code runs once on each core. You use upir to distinguish which core you're currently on; you can't change it.

Maxternal, your signature made me swat at my beautiful laptop screen for a while. You are evil. As punishment, please read http://jasonwoof.org/rlwinm. Also stop trying to load constants directly into SPRs, it won't work.

 

[Andy A]

Comex, have you actually come up with an exploit for wii u mode or is this (tri core in vWii) all you have at the moment. Just be interesting to if I should still be looking for possible code exploits.

 

[Cyan]

Maxternal, I didn't know you knew that much and could write ASM codes.
Thanks to everyone stopping here and giving him advices too.

 

[Crewman]

Sry guys my last statement was not correct, as I recognized today.

It is true, that the code has to be executed 3 times, but you don't have to create a loop.
The better way is to put the code inside a function and then call the function at memory address 0x1330100.

The other two calls had to be at the reset vectors of core 1 and core 2, witch should be at memory address 0x100 in mem1.

 

[Andy A]

I'm starting to get a little confused here, does the code on the front page actually work or is the implementation still being made?