Changes

== Explanation ==

== 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).

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 and/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.

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 contained 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".

This might sound secure, until an exploit was found. Since the Wii IOS uses the C function known as strncmp 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.

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 couple hundred tries. When this is done, the Wii won't compare any hashes, because it will see the 0x00 bytes.

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.

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, as it uses the ES module in the IOS to import and thus follows the process it uses.

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.

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.

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 the ticket of the IOS.