Wii:The Signing Bug: Difference between revisions
(hello derf) |
m (formatting) |
||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
The Signing Bug (Also known as the trucha bug) was a massive security hole in the early versions of IOS (and Boot1) that allowed software to be easily fakesigned. The bug happened as a result of Nintendo's faulty use of strncmp in C, combined with the issue of signatures being binary hash's and not ASCII strings. Binary hash's may contain NULL bytes and if strncmp finds a NULL byte in the hash, it will stop and yield a positive result early if both hashes have the same NULL byte up to that point. This effectively made bruteforcing the signature doable in a matter of seconds by reducing it from 16 bytes to 1. The Homebrew Channel installer in its earlier releases, including the self-installing disc variant, was one of the first pieces of homebrew that took advantage of the signing bug. Even commercial software like the [[Wii:FreeLoader|Datel Freeloader]] used it. It was discovered by Team Twiizers that Boot1 also had the signing bug, thus effectively allowing modders to replace Boot2. The first software made to do this was BootMii, a piece of software injected into Boot2 that allowed excellent brick protection and recovery. | |||
==But, what verifications can be effectively bypassed using the signing bug?== | |||
The Wii, more specifically its IOS, does not verify titles anyway when launching them - due to a last minute performance-enhancing change. They however are verified when installed, so the signing bug is required for installing unsigned titles. Transferring a title exported to SD card via the official Wii Menu functions back to the console counts as installing. | |||
A comparable but limited verification applies to running game discs, covering the above mentioned Freeloader, the few early on-disc homebrews, the Twiizers "semi brick fix" (update) discs, and game mods/repacks. | |||
==How is the signing bug provided to homebrews?== | |||
Early homebrews (until about 2009) require the signing bug in the IOS they run as (whether naturally, ie the one displayed by pressing HOME in the HBC if running them from it, or often the one they explicitly load - often IOS36); that is, if they require/benefit from the signing bug in the first place (many system tools do, not so much emulators/amateur apps in general). | |||
Later, [[Wii:CIOS Installation|CIOS]] (often IOS249) tended to be expected or required - unless it was by Team Twiizers or to be posted on Wiibrew, with their anti-CIOS censorship; | |||
Nowadays, with the HBC having the option to forward [[Wii:AHBPROT]] (full hardware access from main CPU, including kernel memory) to running programs, modern homebrews that need it can simply re-add it on demand to the running IOS - or even fully disable signature checking! | |||
==What should the enthusiast user do about it?== | |||
Obviously the answer to this question, just like everything about modding of the highly modular Wii system, is subjective: | |||
* Many people will install a classic CIOS in IOS249; | |||
* ModMii recommends an IOS60-based CIOS (adding the signing bug and other classic homebrew patches) to be installed over all IOS numbers ever used by the Wii Menu, which will prevent some bricks caused by distraction errors ([[Wii:Downgrading System Menu|Wii Menu downgrading]] without matching IOS installation, [[Wii:Error_Codes#Error_003,_an_unauthorized_device_has_been_detected|Error 003]], etc), potentially increase recovery options for some others (ability to run custom discs from recovery mode), and allow for unsigned digital titles to be transferred back and forth from SD. | |||
* If older system tools are of interest, an IOS36 (and rarely 35) with these patches will often be desirable. | |||
[[Category:Wii]] |
Latest revision as of 18:45, 31 August 2023
The Signing Bug (Also known as the trucha bug) was a massive security hole in the early versions of IOS (and Boot1) that allowed software to be easily fakesigned. The bug happened as a result of Nintendo's faulty use of strncmp in C, combined with the issue of signatures being binary hash's and not ASCII strings. Binary hash's may contain NULL bytes and if strncmp finds a NULL byte in the hash, it will stop and yield a positive result early if both hashes have the same NULL byte up to that point. This effectively made bruteforcing the signature doable in a matter of seconds by reducing it from 16 bytes to 1. The Homebrew Channel installer in its earlier releases, including the self-installing disc variant, was one of the first pieces of homebrew that took advantage of the signing bug. Even commercial software like the Datel Freeloader used it. It was discovered by Team Twiizers that Boot1 also had the signing bug, thus effectively allowing modders to replace Boot2. The first software made to do this was BootMii, a piece of software injected into Boot2 that allowed excellent brick protection and recovery.
But, what verifications can be effectively bypassed using the signing bug?
The Wii, more specifically its IOS, does not verify titles anyway when launching them - due to a last minute performance-enhancing change. They however are verified when installed, so the signing bug is required for installing unsigned titles. Transferring a title exported to SD card via the official Wii Menu functions back to the console counts as installing.
A comparable but limited verification applies to running game discs, covering the above mentioned Freeloader, the few early on-disc homebrews, the Twiizers "semi brick fix" (update) discs, and game mods/repacks.
How is the signing bug provided to homebrews?
Early homebrews (until about 2009) require the signing bug in the IOS they run as (whether naturally, ie the one displayed by pressing HOME in the HBC if running them from it, or often the one they explicitly load - often IOS36); that is, if they require/benefit from the signing bug in the first place (many system tools do, not so much emulators/amateur apps in general).
Later, CIOS (often IOS249) tended to be expected or required - unless it was by Team Twiizers or to be posted on Wiibrew, with their anti-CIOS censorship;
Nowadays, with the HBC having the option to forward Wii:How to Play DVD Movies (DVDX) (full hardware access from main CPU, including kernel memory) to running programs, modern homebrews that need it can simply re-add it on demand to the running IOS - or even fully disable signature checking!
What should the enthusiast user do about it?
Obviously the answer to this question, just like everything about modding of the highly modular Wii system, is subjective:
- Many people will install a classic CIOS in IOS249;
- ModMii recommends an IOS60-based CIOS (adding the signing bug and other classic homebrew patches) to be installed over all IOS numbers ever used by the Wii Menu, which will prevent some bricks caused by distraction errors (Wii Menu downgrading without matching IOS installation, Error 003, etc), potentially increase recovery options for some others (ability to run custom discs from recovery mode), and allow for unsigned digital titles to be transferred back and forth from SD.
- If older system tools are of interest, an IOS36 (and rarely 35) with these patches will often be desirable.