Wii system flaws/Untested
These flaws have been identified but not yet tested.
|Location||Description||Uses of this bug||Discovered by|
|boot0||boot0 has a common panic routine that runs under a number of scenarios, one of which is when the boot1 hash check fails. For unknown reasons, there is an extra jump to the normal boot1 loading code after panic returns (offset FFFF04E0), despite panic never having any possibility of returning. It may be possible to time a voltage attack correctly to skip over the jump-to-panic instruction, allowing for certain recovery software.||In theory, it should be possible to boot recovery software on IOS-bricked consoles that lack a NAND backup.||Hallowizer|
|System Menu||Attempting to copy Bannerbomb to the NAND (either through Data Management or the SD Card Menu) triggers the "/boot.dol not found" dialog. This has not been tested when a boot.dol is actually present, but Bannerbomb normally gives a prompt asking to confirm running the exploit before showing that screen. This is most likely some form of buffer overflow.
Interestingly, this does not work with Bannerbomb v1 on System Menu 4.2 or System Menu 4.3 (where the ? mark dummy banner shows instead); it is not clear if this is due to the Bannerbomb exploit being responsible for this, or due to the Wii automatically giving an error when copying any channel with a ? banner.
|Making stuff look like channels in the SD Menu, and copyable to NAND.||Hallowizer|
|IOS||IOS_CreateHeap initializes a HeapBlockHeader at the beginning of the heap when it is called, consisting of the words
Note that if the thread is blocking, the code will not execute until the thread unblocks. One possible solution is to hijack the /dev/aes server thread, and attempt to open /dev/aes.
|IOS kernel code execution||Hallowizer|
|IOS||IOS_CreateMessageQueue does not limit the number of messages. By specifying 2^30 messages, the buffer size would be 0 (2^32), so no memory range would be verified. The target address could then be written to with IOS_SendMessage.
This flaw was originally discovered for the Wii U in 2016.
|Arbitrary write as IOS kernel||Hallowizer; derrek, nedwill and naehrwert (Wii U)|
|IOS||ES's signature verification code does not seem to verify the entire certificate chain, instead only verifying the last certificate. By constructing a longer certificate chain, it may be possible to create fake signatures.
One thing this will not help with is replacing boot2, since boot1 specifically checks that the last certificate starts with CP or XS, the second last starts with CA, and the third last starts with Root, verifying CA's signature with Root regardless of whether the issuer is Root or a fake Root certificate (e.g. Roothax)
|Running unlicensed discs or installing custom titles without IOS code execution||Hallowizer|
|IOS||When setting up the memory map, the kernel defines a single region that contains all default thread stacks, placed in domain 15 (shared). It is probably possible for processes to write to stacks belonging to threads that use the default stack, including kernel threads. By overwriting a saved LR, control of that thread could be taken.||Trivial privilege escalation within IOS||Hallowizer|