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 { 0xBABE0000, size - 0x10, 0x00000000, 0x00000000 }. However, it does not ensure that 0x10 bytes are available in the heap before doing so. By passing 0 for the size, the words { 0xBABE0000, 0xFFFFFFF0, 0x00000000, 0x00000000 } can be written to any address. By setting the beginning of the heap to 0xFFFE0034 or 0xFFFE0038, the main kernel thread's PC is set to 0, likely causing privileged execution in an area already controllable. 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	Everyone
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	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	Everyone
IOS	DVDLowOpenPartitionWithTmdAndTicket and DVDLowNoDiscOpenPartition do not verify that the TMD passed has the same ID as the TMD on the disc. By passing a Wii Backup Disc TMD and ticket, it may be possible to get group 0 access. This exploit appears to be used in HackMii Installer 0.7-1.0 to install BootMii-IOS at startup.	Setting the IOS permissions to group 0	fail0verflow,[check]