it's running "of a cloud" because the exploit is on the browser application, and it can access internet.
if it was another application, you would be limited to its possible access (lan, sd, nand, mii, saves, etc.)
being a vulnerability on the browser opens the door more easily, as you only need to load a file into memory by visiting an URL.
The OSDriver above is only the second layer in the full exploit. it's the one which patch the kernel level access.
Before that, you need to patch the user level access.
see it like 3 walls around the main CPU functions. the IOS wall, the kernel and user wall.
the IOS is responsible for hardware access, it's grants applications the access to specific hardware based on their needs (sd, usb, network, gamepad, etc.)
the kernel is responsible for the memory access, it allows or block specific memory area to prevent an application from accessing restricted memory and data.
The user level is "all the other function" an application can use to create the game/interface, a game don't need to manage the memory and the hardware, it only access what the IOS and kernel provides him. the user level is enough for a lot of application and homebrew, like games, emulators, mediaplayer, etc.
Then, there's the end user level : Us, the players. we don't have access to functions, only to input/output (tv, gamepad, sometime SD, sometime network and internet)
But you are limited in what the IOS or kernel let you access.
For example, loadiine is using Smash Bros as "host game" because it's one of the two disc based games (with Art academy) which the IOS grant SD access.
As IOS exploit is not public yet, we can't edit the hardware rights and are limited in what we can access based on the "host" we are using.
So, we come back to the browser exploit :
The browser has network access granted by the IOS, so it's a thing we can use to break the first wall and get the "user level" where we can run our own functions.
The first wall vulnerability in the browser is : JSStringJoiner heap overflow (up to 5.3.2) and StageFright (up to 5.5.0 and I think still not patched in 5.5.1)
http://wiiubrew.org/wiki/Exploits
it's using an overflow vulnerability, which means that the program (the browser here) is not correctly checking the length of its variables when writing into memory, and if you write a bigger variable than expected, you are "overflowing" into another memory area/bank.
by doing that, you can write a function in that area, and the browser will run it when it will load that area : the kernel provided that area to the browser, and the browser has user access allowing it to run "non kernel related" functions here.
The function we are loading here is the "entry point" into loading another program : the payload (your homebrew).
a tiny overflow lets you continue execution to another functions.
This is the "user level" access. You can now run safe functions here. safe functions are all the non-kernel functions, the ones not trying to access or modify the memory, or file system.
The issue here is that the browser has a limited memory area it can use to store your homebrew (few Kb), and if you need more memory you need to get kernel access to give the browser more memory!
this is now the OSDriver job.
that exploit is explained in the link posted by Garou.
That explanation is a lot more technical, it's explaining how it really works and not just providing the general idea.
Like said above, the kernel level is needed to get more memory, but also to get access to File system functions (to rewrite and redirect access from NAND to SD, for loadiine or saviine) or to access and edit the memory (TCPGecko), or rewrite the read/write rights of each memory area (BAT).
By using a vulnerability in the "kernel wall" the same way we exploited one in the "user wall", we can write functions in the kernel level and the kernel will run them for us.
@
Psionic Roshambo:
@
BigOnYa:
