osdriver kernel exploit reliability in 5.3.2

[deleterrrr]

There is a solved issue regarding this but it wasn't really solved, a comment from @Marionumber1 https://github.com/wiiudev/libwiiu/issues/9#issuecomment-113835294 explains why the issue is occurring.

I can't get osdriver to work on my 5.3.2 wiiu after having it working every time previously and there's quite a bit of advice floating around surrounding this so I'm just going to list what I've tried and some questions that I have.

wiiu history is a Lego City Undercover bundle upgraded to 5.3.2 using Splatoon.

Originally it took me 20~ attempts to run the exploit successfully the first time, every attempt up until the time that it worked froze the browser bar half way and then put some artefacts on the screen and locked up the console, requiring a hard reset. Every time after the first successful attempt it would succeed or fail the race attack with the correct error message.

Then I compiled loadiine myself to skip some of the screens and changed over to self hosted exploits rather than using the wiibrew address I had used previously. I thought that I should probably clear out all the wiiu browser settings in the process of switching over to use my own .elfs - and now I can't get the (unchanged) osdriver exploit to run reliably.

Some questions I have - Does server speed matter for the exploit?

Are we aiming to have more memory used or less when the exploit runs? (I would say that less is better as I have seen reports of the exploit working when the quick start menu is used on the Wii controller, I have also experienced this however it doesn't seem to 'cache' the exploit like it did the first time I succeeded in running it.)

How can I debug this further? I know little about how this works at the moment but if I can help at all I will.

[deleterrrr]

OK got it running again and now quite reliably.

Here's what I did in order of what I think was most important for increasing the reliability of the exploit running.

1. Turn off quick start in the wiiu power settings.
2. Access the payload532.html files directly from the wiiu Internet Browser start page using bookmarks - to do this add a couple of bookmarks to somewhere like Google and then edit the urls to point to your payload532.html files, then close all of the tabs in the Internet Browser and power off the wiiu using the controller. Every time you start the wiiu browser now it should come up with the start page.
3. Turn on developer tools in the wiiu browser settings (not convinced this makes a difference).

However the issue still remains that the first run is the hardest one to get going, after doing some reading about how these types of exploit work I know that we have to spray a nop ramp with the exploit code at the end and then modify the stack so that the processor hits the nop ramp and eventually executes the code, I do not however understand which part of this process is failing. Unfortunately I'm not inclined to do any more testing regarding this as the wiiu is for my children and I don't want it out of action again before Christmas! After that though I'll come back and try to contribute a bit more.

[Netfreak25]

Hey deletrrr

I have no deep insight view but the xploit is running an race attack. A race condition needs to overhaul the original process before the original process is writing data, if it does not its going to fail (generally speaking). In my experience (e.g. race conditions on webservers) it helps if the destination is busy with other stuff, this increases the chance to win the race. So, I currently have a 1/2-1/3 chance to get it running. And the main difference made the speed in applying the xploit once the browser started. Therefore I can confirm that it was a good idea to link a bookmark directly to the payload, but I also host it locally due to network speed. I usualy try to click it in under 1 second and for me I have the satisfying fail rate mentioned above.

Regards, Moritz

FYI: I have no connection to the dev team here and I do not understand the code yet, nor do I have the source of the xploit itself (could not identify it)

[Relys]

I ended up running tests in the thousands to optimize the chance of a successful attack of the race condition when we overwrote an OSDriver objects pointer due to a memcpy unprotected by a spinlock. If you think that sentence was a mouthful you should have tried developing this exploit. Comex originally identified the vulnerability and it took @Marionumber1, @Hykem and I months to implement it.

Here are the two values for CPU0_WAIT_TIME and CPU2_WAIT_TIME: https://github.com/wiiudev/libwiiu/blob/master/kernel/osdriver/src/loader.h#L10

I ended up taking 20 random samples, removed the outliers, and calculated the median and standard deviation to arrive at those values. There are a lot of variables depending on what the kernel is currently doing at the moment which means 100% reliability is theoretically impossible.

Exploit developers have thus moved on to more stable methods of execution. This is the only public method and will remain so indefinitely until further notice.

[CreeperMario]

@dimok789 pulled some changes to the kernel exploit a few days ago. The exploit is still not 100% reliable (like @Relys said, that is REALLY difficult to pull off with the nature of this exploit) but it is presumably more stable than before.

[Relys]

@CreeperMario It is probabilistically impossible to reach 100% reliability due to the logical nature of this exploit (A driver race condition in the kernel that we spent almost a year finding). I'm pretty sure we've hit the upper-threshold for success ratio. Even then it proves to be non-deterministic at times. TOCTOU (i.e. "race conditions" for you mortals) often have a high entropy factor due to narrow window introduced by process scheduling, IRQs and cache flushes. There are alternative, more stable (post-exploit) vulnerabilities in the Wii U's operating system as there are for any system in the world if you know how to dig up and find the 0day gold. ;)