492
edits
Changes
Created page with "The '''Trucha Bug''' (trucha is "trout" in Spanish) is an unofficial name for a signing bug in the Wii. It allows "fakesigned" WADs to be installed on the Wii. == Explanation..."
The '''Trucha Bug''' (trucha is "trout" in Spanish) is an unofficial name for a signing bug in the Wii. It allows "fakesigned" WADs to be installed on the Wii.
== Explanation ==
In TMDs and tickets used for titles, there's an RSA signature that's signed by Nintendo or [[BroadOn]] (usually an RSA-2048). The signature contains a SHA-1 hash of the rest of the file (along with ASN1 padding). The Wii verifies the signature with a public key, the private key is something that only Nintendo or BroadOn would have. (In many examples, the public key is used to encrypt and the private key is used to decrypt. However, since it wouldn't make sense for the Wii to have the private key, the public key is used to verify and the private key is used to sign).
The reason that the TMDs and tickets are signed is to make sure that someone can't modify the contents of a title. TMDs contain SHA-1 hashes of all the contents, and if the hash doesn't match up, the Wii wouldn't launch the title. Also, for content downloaded through the Wii Shop Channel, tickets are made that have a console ID so the titles can't be transferred to another console.
This might sound secure, until an exploit was found. Since the Wii IOS uses the C function known as strcmp instead of memcmp to compare the hash in the signature to the hash of the rest of the file, the function stops if there's a null byte ("\0", also known as "0x00"). Thus, if the hash being compared starts with a null-byte, nothing is compared at all. Exploiting this is called "fakesigning".
In TMDs and tickets, tools that utilize fakesigning set the RSA signature to all zero, and the file is modified until the SHA-1 hash of it starts with 0x00 (different tools seem to modify it differently). At most, the hash will start with 0x00 in at most a few hundred tries. When this is done, the Wii won't compare any hashes.
If you're making a WAD of the contents, the TMD doesn't have to be fakesigned as long as it's not being modified. However, the ticket has to be modified to get rid of the console ID. Tools that install WADs won't usually install the WAD if there's a console ID in it and it's being used on a Wii that's different from the one being used on.
Discs use the trucha bug as well if you're modifying them, since they use TMDs. Programs that can load games from a USB drive or Dolphin Emulator might not respect the signature, as formats such as WBFS have been made to hold the contents. WiiConnect24 content also has RSA signatures, however it's not known if they're affected by the trucha bug.
Nintendo patched the trucha bug in later revisions of the IOS firmware, however by using IOS that have the bug in it, they can be used to install modified IOS that reinstates the trucha bug, and using the bug itself to fakesign the TMD and possibly ticket of the IOS.
== Explanation ==
In TMDs and tickets used for titles, there's an RSA signature that's signed by Nintendo or [[BroadOn]] (usually an RSA-2048). The signature contains a SHA-1 hash of the rest of the file (along with ASN1 padding). The Wii verifies the signature with a public key, the private key is something that only Nintendo or BroadOn would have. (In many examples, the public key is used to encrypt and the private key is used to decrypt. However, since it wouldn't make sense for the Wii to have the private key, the public key is used to verify and the private key is used to sign).
The reason that the TMDs and tickets are signed is to make sure that someone can't modify the contents of a title. TMDs contain SHA-1 hashes of all the contents, and if the hash doesn't match up, the Wii wouldn't launch the title. Also, for content downloaded through the Wii Shop Channel, tickets are made that have a console ID so the titles can't be transferred to another console.
This might sound secure, until an exploit was found. Since the Wii IOS uses the C function known as strcmp instead of memcmp to compare the hash in the signature to the hash of the rest of the file, the function stops if there's a null byte ("\0", also known as "0x00"). Thus, if the hash being compared starts with a null-byte, nothing is compared at all. Exploiting this is called "fakesigning".
In TMDs and tickets, tools that utilize fakesigning set the RSA signature to all zero, and the file is modified until the SHA-1 hash of it starts with 0x00 (different tools seem to modify it differently). At most, the hash will start with 0x00 in at most a few hundred tries. When this is done, the Wii won't compare any hashes.
If you're making a WAD of the contents, the TMD doesn't have to be fakesigned as long as it's not being modified. However, the ticket has to be modified to get rid of the console ID. Tools that install WADs won't usually install the WAD if there's a console ID in it and it's being used on a Wii that's different from the one being used on.
Discs use the trucha bug as well if you're modifying them, since they use TMDs. Programs that can load games from a USB drive or Dolphin Emulator might not respect the signature, as formats such as WBFS have been made to hold the contents. WiiConnect24 content also has RSA signatures, however it's not known if they're affected by the trucha bug.
Nintendo patched the trucha bug in later revisions of the IOS firmware, however by using IOS that have the bug in it, they can be used to install modified IOS that reinstates the trucha bug, and using the bug itself to fakesign the TMD and possibly ticket of the IOS.