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
IOS	Using content type 0x2 probably disables verification of the hash tree. Might only work on dev units, but dev TMDs have been released before (like 123J, 0000dead, 121J, 122E).	Could possibly allow disc modifications, or even BootMii on newer Wiis. Note that BootMii won’t work with this alone, since boot1 checks that the TMD's ID is 1-1, and none of the exploitable TMDs have that ID.	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
SDK	The interrupt table is initialized by copying a default handler to each vector; to account for errors in the specific devices, when initializing each device, OSInit replaces an ori r0, r0, 0 (nop) instruction with a jump to an earlier point, which is meant to create an infinite loop. However, this jump does goes to the location in the default handler (not the copy for that particular interrupt). This means that the ultimate fate of whether an errored device gets stuck in an infinite loop is determined by whether interrupt 0xF (thermal interrupt) has an error. The position in the function that the repeat jumps to appears to be arbitrary; repeating once before returning from the interrupt might save incorrect values in the registers, which could be exploitable in some way.	No known uses currently, but might be usable for some Broadway code execution exploit	Hallowizer