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. Must work on retail units, since 122E runs under a retail IOS9. Normally only present on dev TMDs, but dev TMDs have been released before (like 123J, 0000dead, 121J, 122E); these TMDs have hash 456767b68bd91a7a000000000000000000000000, which is Egg....z.............	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