Hacking [OLD] Loadiine backup loader for WiiU 5.3.2 ONLY (NO 5.4 NO 5.5!)

[Loke]

If you have the spoof, you can run the game from disc or loadiine, and it will not ask you to update. (that's the spoof purpose)
If you don't have the spoof, you can use loadiine to launch the backup, but not the disc (yet).
I think it will be very easy to launch the inserted disc without redirection to bypass the update for users without the installed spoof.


Thanks, I'll add (or replace?) to the first post.
I'll also add these ones
http://spiffyhacks.com/wiiu/
http://wiiuexploit.hoxty.com/

Thanks! So it won't matter what disc i'll buy. I mainly installed the spoof for online play, and i read the spoof is not a update failsafe. Gonna buy mario maker and smashbros for online play then!

 

[Cyan]

that's right, the spoof doesn't prevent a system update from the network, but it's preventing the update from the disc.
always keep online blocked or filtered to prevent auto-update of the system from nintendo's servers.

But attention !
If you have online enable, the game will know that there's an update available and will ask you to update before launching the game.
You can't update the game with the official procedure (while launching the game) because it will need a console update first. Never accept to install updates if the game asks you, the spoof won't protect you.
You will have to use WUP Installer homebrew to update the game's update manually.

SSB update is 2GB, you will have to install it if you want to play online.
Search the forum for Nusgrabber and Wup installer threads to get the tools and help to use them.

 

[Loke]

Yeah i'm using tubedns for blocking the game updates. Works like a charm with mario kart, but was scared to buy mario maker or smash bros because of the 5.4 update. I assume it will try to update (like with mario kart) but prompt out an error because it can't connect to the servers (tubedns).

 

[Cyanopsis]

Could someone please explain the details behind the meaning of "race attack failed"! What is it trying to do, and why is it failing sometimes and why does it suddenly work?

 

[EclipseSin]

Could someone please explain the details behind the meaning of "race attack failed"! What is it trying to do, and why is it failing sometimes and why does it suddenly work?

Here, go learn something.

http://www.cis.syr.edu/~wedu/seed/Labs/Vulnerability/Race_Condition/Race_Condition.pdf

 

[Cyan]

see it like this (it's wrong, but it's just to illustrate the "race" element from a end user view):

The WiiU has multiple cores which are running independently from each others.
one is responsible to check if there's a hack attempt and prevent it happening.
one is used for the hack.

the kernel patcher ask one of the core to hack the console and from here you just hope that this core will do it before the guarding core run its detection function. it needs to be faster and "race" before the other one launch its protection.
if the watching core acts before the hacking is completed, it detects it and the race attack fails.
it's possible because the cores are not synchronous and are doing their things separately.


It's not what's really happening, it's just an easy way to understand the race between two functions.
what's happening is more a cycle issue, both are doing their hacking and protection at the same time, but sometime one is slower than the other and not waiting for a specific register to be set before continuing execution.

 

[Reecey]

Hey, well its not that I think that the compatibility is not important. Just as I said in one of my previous comments, its really not fun developing on something so instable. Its really annoying when it freezes all the time and you have to hard reset your WiiU each time you do a little change. That is why the other stuff, the base implmentations for easy development, is more important to me.

Nevertheless here is a little peek into its development:
I did dig into that stuff. It requires us to revert the "kernel exploits" changes to the kernel memory setup table. At first I though we dont use the setup memory region by those changes anyway anymore so I though we only need to revert the table to its original state and thats it, but I forgot that we actually use the memory setup by it for storing the RPX file temporary into and load it from there in the loader later.
The kernel setups the MMU from that kernel memory setup table. It maps a physical address to an effective (virtual) address with permisisons and gives us (user mode usually) access to some memory regions. Since all 8 DBATs are in use by the system for different purposes and variate in their positions from application to application, we can not just setup a common DBAT to some fix position for our code running. Our code is in background in every application and doing data accesses to the same physical memory area, so it must be a permanent (run time) change which stays there for all applications. Well the other option left is to setup a segment register with the corresponding PTEs in the PTEGs table for our memory access as those do not variate and are fix in overall WiiU run time. This process is relatively complex compared to the setup of the BAT registers which are not very simple themself. Well, I have already implemented the algorithm to setup PTEs for a segment register of my choice and the memory area of my choice. So I can setup us a segment register and we can remove the kernel memory table modifications. And that is the only thing left to implement (its only a few lines of code). But than while testing it I got really pissed when it froze again after having frozen several times in some tests before because of some simple mistakes and I had to hard reset the WiiU again and then the freaken kernel exploit didnt want to work etc....so I though f*ck it for the day and went to bed at like 2 or 3 o'clock in the morning. As that was really annoying and not fun at all and it is only for one game, I started working on something that actually will make my life easier by writing bases for easy development before continuing with stuff that can not be logged and freeze because of every little mistake you do. Stuff that actually are fun to code.... I will continue my work on that eventually but for now I am working on the stuff that me and many developers will benifit from also and not just the users (it might be a bit egoistic but oh well, the other stuff was really annoying me ).

So to sum up, this whole text is just a little peek into how the development is going on and to explain you (and the other that think what I do now is only "nice to have") that it is really annoying to code for the WiiU at the current state with the current kernel exploit and I dont have the time to actually search for a better exploit either as there is so much other more important stuff to do too, so I always say "mah...maybe later..." knowing that another more stable exploit already exist and some people use it but dont give it out to the public (I dont have it). The changes might look from the users side like its a "nice to have" but it is not a "nice to have" for me and probably many other developers, its needed to not go nuts developing with such a crappy development environment and loose the interesst in the work quickly.

Thank you for the run down on that dimok. I probably don't understand most of that but I don't expect you to know that but its one hell of a good read! I picked bits out of that and it does make more sense and it sounds like your having a bloody good go anyway so that's all that matters!. I would imagine doing what your doing and using the exploit many times must be quite annoying to you when your trying to run it multiple times to test out, yeah I can understand that!. Goodluck anyway and thanks again for the low down

 

[Cyanopsis]

see it like this (it's wrong, but it's just to illustrate the "race" element from a end user view):

The WiiU has multiple cores which are running independently from each others.
one is responsible to check if there's a hack attempt and prevent it happening.
one is used for the hack.

the kernel patcher ask one of the core to hack the console and from here you just hope that this core will do it before the guarding core run its detection function. it needs to be faster and "race" before the other one launch its protection.
if the watching core acts before the hacking is completed, it detects it and the race attack fails.
it's possible because the cores are not synchronous and are doing their things separately.


It's not what's really happening, it's just an easy way to understand the race between two functions.
what's happening is more a cycle issue, both are doing their hacking and protection at the same time, but sometime one is slower than the other and not waiting for a specific register to be set before continuing execution.

Fantastic! Thank you! So, what is needed for the controlling core to not see the hack being deployed? What development is needed on loadiine?

I'm all for gui development, but if there was one thing that would streamline the experience somewhat, it would be this issue I think.

 

[oPolo]

Fantastic! Thank you! So, what is needed for the controlling core to not see the hack being deployed? What development is needed on loadiine?

I'm all for gui development, but if there was one thing that would streamline the experience somewhat, it would be this issue I think.

As he said, that is not really what is happening; it only clarified the race attack concept.
I do not use loadine, but I doubt it has to do with it? I guess it has to do with the kernel exploit?

Another race condition example would be, if core1 loads something from the RAM to execute it. Core2 then overwrites core1's memory, before core1 had a change to execute it. Core1 will now instead load the overwritten data from core2. Race attacks are attacks that rely on timing. That's why it sometimes fails and has to be run again.

Read this for the actual 5.3.2 race attack: https://gbatemp.net/threads/osdriver-kernel-exploit-a-technical-description.395444/
The first part describes it without being all too technical.

 

[Cyan]

yes, the race attack issue is from the kernel exploit, not loadiine side.
Though, the way loadiine works (or worked on 1.0a? maybe it changed) is the same principle.

The SSB rpx is read by chunk of 4MB by the IOS, after each loaded chunk loadiine replace the memory with it's own 4MB rpx data from your SD card.
After the cIOS complete its work, the wiiu doesn't check if the data loaded in memory is really the expected rpx and trust the IOS's job, then the console runs it.
it's the same example as a race, doing something between two actions "load rpx to memory" <replace the memory> "launch rpx in memory"

 

[Cyanopsis]

So that is the actual exploit... You have found a way to get inside the wii u between that hack checking. Getting this hack to work at 100% isn't possible with this kernel exploit, it would require a new exploit all together. Correct?

 

[EclipseSin]

Little Update from my last post... I worked some more, cause I are in need of sleep.
click for full size

 

[Gadorach]

So that is the actual exploit... You have found a way to get inside the wii u between that hack checking. Getting this hack to work at 100% isn't possible with this kernel exploit, it would require a new exploit all together. Correct?

Not necessarily, it might be possible to introduce additional processes to the cores that are intended to slow down the target processor enough to widen the gap between the ToCToU exploit used to overwrite the kernel. With enough work, it could likely be made into a more stable exploit, yes. Else, having a modchip attached to a serial port could allow the clock of the target core to slow down considerably through hardware manipulation, but that's a bit extreme of an alternative. Either way, the issue is in targeting the exact time that the ToC completes, and injecting the new kernel before the ToU begins. The slower the target core during that process, the more accurate the overwrite timing can be. Simple as that. Unfortunately, it's not quite so simple to implement, so it'll likely take some hard work to achieve it, if it's not replaced with a better exploit first.

 

[Cyanopsis]

Not necessarily, it might be possible to introduce additional processes to the cores that are intended to slow down the target processor enough to widen the gap between the ToCToU exploit used to overwrite the kernel. With enough work, it could likely be made into a more stable exploit, yes. Else, having a modchip attached to a serial port could allow the clock of the target core to slow down considerably through hardware manipulation, but that's a bit extreme of an alternative. Either way, the issue is in targeting the exact time that the ToC completes, and injecting the new kernel before the ToU begins. The slower the target core during that process, the more accurate the overwrite timing can be. Simple as that. Unfortunately, it's not quite so simple to implement, so it'll likely take some hard work to achieve it, if it's not replaced with a better exploit first.

Thanks a bunch! No more questions for me. Carry on!

 

[Azel]

Little Update from my last post... I worked some more, cause I are in need of sleep.
click for full size

I like this a lot too :o (the stretched settings key looks a bit weird to me though^^'')

upper screen could be that with left right on the pad (and L/R to switch more titles like 5) to switch the games
If you stay 3sec or more, the disc image could slide from the zelda box and start rotating)
lower screen could look like what wad shown before, a grid of icon with touch control at some point later

 

[merlin555]

Fast Racing Neo
20-25min to load in the level from main menu.
Loadiine v4.0

 

[EclipseSin]

I like this a lot too :o (the stretched settings key looks a bit weird to me though^^'')

upper screen could be that with left right on the pad (and L/R to switch more titles like 5) to switch the games
If you stay 3sec or more, the disc image could slide from the zelda box and start rotating)
lower screen could look like what wad shown before, a grid of icon with touch control at some point later

The wrench is just a basic wrench, nothing fancy. Just whipped it up quick cause I couldn't think of a design I liked. It'll probably be different later.

As for the other stuff, I agree with the scrolling and box manipulation, but I want this on my gamepad. xD I hardly use my TV with my U, unless the game requires me to use it. Preferably, I would want X to swap screens like the home menu anyways eventually. That way we could quick swap between at least two views on the gamepad/tv, with touch/normal controls for each mode.

 

[luan43]

Fast Racing Neo
20-25min to load in the level from main menu.
Loadiine v4.0

which sd card you using fam?

 

[Garou]

Quick search here and cannot find the same error, so here goes

when playing Mario Kart 8 using loadiine and the game asked me if I want to post to miiverse, it crashes with this error

I know loadiine has no support for online yet, but does that mean I should refrain to do anything with miiverse as well?
not a big issue to me, but just to confirm so I won't do the same things again and risk losing my progress

 

[fiveighteen]

Nice work on a GUI, glad to see people working on this. look forward to getting to use one of these some day.

(This is my personal opinion and not hating on what you've done, lord knows I could not do better but you did ask for ideas.)

Seem to be alot of useless(IMHO) info that takes a large chunk of screen real-estate. I personally would prefer something that shows more of the artwork and less text. Also there is a bit of empty wasted space to the right of this text between that and the images that is nearly dead center of the screen. I think a design that had less of the extra info or a secondary optional screen that show this info if say you pressed +(have know Idea what is actually possible). And or possibly putting this text on the lower or split between the lower and upper portions of the screen showcasing larger game eye candy in the middle part of the menu.

Thanks to you and all that work on these things.

I like constructive criticism. How about something like this then?

Cover/Info is interchangeable with the B button. Grid and List views are interchangeable by clicking the button to the right of the SD card info. The button to the left of it would reload the SD card (for hot swapping).

Spoiler: V2

Spoiler: V2

Latest version here

--------------------- MERGED ---------------------------

Little Update from my last post... I worked some more, cause I are in need of sleep.
click for full size

Constructive criticism for you:
- That's going to require downloading a lot of cover files, no? There are at least 3 different types there.
- I thought about putting the synopsis text into mine, but what happens when you get a long one (Look at Yoshi's Woolly World's)? I guess that box could be scrollable.
- You might want to make the controller and accessories field height twice as tall. You're going to quickly run out of room for icons (Super Smash Bros.)