Everyone has at least heard of the Trucha Bug at one point or another. You may even know that it’s because of the Trucha Bug Wii hacking is possible however, most have no idea what this means, how it works, or why it works. I’ve done a lot of research and testing to help myself understand all of this and wanted to share what I’ve learned. I think it’s important to share this information in order to help newcomers and existing members understand the basics of Wiihacking and hopefully help them realize what it means to hack their Wii. Feel free to add comments, questions, or even disagree with me if you think any of this information is incorrect.
Wii Security (summary)
The Wii has very sophisticated security measures that it uses on all data to ensure it’s authentically issued by Nintendo. This data includes: boot information, system menu files (IOS), channels, game saves, Wiiware, and games on disc. All data is encrypted with AES 128-bit symmetric encryption to prevent unauthorized viewing and signed with an asymmetric crypto to prevent modification.
Common Key
AES symmetric encryption means the data is encrypted with the same key that’s used to decrypt it. This means that the Wii has this key stored somewhere as it needs to use it to decrypt data. Since the same key is used to both encrypt and decrypt data all Wiis must know it so it’s considered to be a common key. Team Twiizers are the group credited with extracting the common key by bridging areas of the Hollywood processor with tweezers thus the name Team Twiizers. This is the same key that’s used by programs like Wiiscrubber and Trucha Signer to decrypt and open game partitions.
Data Signature
The second component of Wii security is called the signature and this is much more complex than simple data encryption. All data has a unique digital signature that can’t be duplicated or reproduced. For example, if you have two data files that are exactly the same then the signature will also be the same however, if you change just one byte in one of the files, the signature will change completely and at random. The Wii uses this type of digital signature to verify data has not been altered. An SHA1 hash (which is simply a randomly calculated code) is calculated from each 0x400 bytes of data and the total of all the hashes combined make up the signature which is stored in a certificate binary file called a TMD. The actual signature of the data (compiled from all the hashes) is checked against the TMD for verification. If everything matches up then the data passes the security check and is allowed to run. Anything except for an exact signature match with the TMD causes the system to crash and it needs to be rebooted.
Private Key
As if public key encryption and signature verification wasn’t enough security (and it’s not), Nintendo also signs the TMD certificate and data hashes with their own private key. This is the big cheese in Wii security because it means the data inside the TMD can’t be modified without resigning with Nintendo’s own private key. Unlike the public key, the private key is unknown by the Wii so a tweezers attack won’t provide us with this information. The only way to obtain the private key would be through a leak from Nintendo or via a brute force attack. A brute force attack is usually conducted by a computer program which basically throws every possible combination at a signature or hash until it’s cracked. Brute forcing a key of this size (32 bytes or more) would take a very long time to complete making it an infeasible option.
Wii Disc Security
I’m going to attempt to keep this part as simple as possible for the sake of keeping this thread an easy read for everyone. If anyone is interested in more detailed info on this just ask or PM me.
First and foremost, you have to think of a Wii disc as separate data put into one media. The separate data is called a partition and each partition (usually an update partition and game partition) has it’s own security. Each partition’s security consists of AES symmetric key encryption in addition to a data signature which is protected by the private key. The most prominent difference with disc security is that the partitions are encrypted (not signed) with a unique symmetric key called a titlekey. This key is disc specific and is only used to encrypt/decrypt the partitions of the disc it belongs to. After each partition is encrypted with the titlekey and signed, the entire disc is then encrypted with the public key. This means that in order to view the data of a disc, you must first decrypt with the public key and then the titlekey can be extracted from the partition header and used to decrypt the partitions. This is all done automatically when opening an iso with Wiiscrubber or Trucha Signer.
SD Key/ECC Private Key
The final chapter in Wii security is the built-in local security which consists of two components, the SD Key and the ECC Private Key. Because the Wii is capable of saving data such as game saves and Wiiware to an external source via the SD slot, Nintendo added the ability for the Wii itself to encrypt and sign data so it can’t be viewed or modified.
The SD Key is used to encrypt/decrypt data and is known by all Wiis kind of like the public key except it’s limited to data from the SD slot. The ECC Private Key is unique to one console only and each console has its own. The purpose of the ECC key is to sign the data being exported from the Wii to an SD card so the data can only be used with that specific console. This type of security is not as concrete as Nintendo’s private key since the ECC key is known by your console and can easily be extracted. The problem with extracting the ECC key is that the average person can’t conduct a tweezers type attack to extract it. The easier way to get this key is to run software which reads the keys such as with an app called xyzzy by Bushing. The reason the ECC key can’t be used to hack a system menu is because you need to be able to run Homebrew before you can run the xyzzy application to extract the keys.
Don’t worry If you can’t follow all of this exactly. You only need to know that it’s nearly impossible to crack this type of security with all these security measures. Since cracking through the Wii’s security wasn’t a feasible option, hackers started looking for a way to bypass the security through a flaw in the software. This type of flaw is known as an exploit and we all know an exploit was indeed found.
The Trucha Bug Exploit
The Trucha bug was a software flaw found in the first generation Wii’s boot data and firmware files (IOS). The flaw would cause the Wii to bypass the security verification process on the data in question if a null byte was found in the TMD signature. These meant that in order to bypass the security check we only had to brute force the first character of Nintendo’s private key and use it to sign the TMD signature with a null (0) first byte. The security check would then see the null byte and automatically pass the TMD cert without even checking it. This flaw was soon fixed by Nintendo however the damage has already been done. Today we simply use a memory exploit to overload the buffer such as with Bannerbomb, Indiana PWNS, or Smash Stack. Once this buffer overload occurs we are free to run any custom code we want (Homebrew Installer, Dop-Mii, TruchaBug Restorer, MMM, etc.) since the overload causes the Wii to look to the SD slot for more space. The memory exploit then allows us to be able to reinstall the trucha bug into our system IOS via Homebrew. Without the Trucha Bug we wouldn’t be able to run games from usb, use emulators to play backwards compatible roms, install custom IOS or even have any of the self recovery options that we have today.
Here’s an example of the exploit: (sample IOS code taken from the Hackmii website)
struct rsa_cert {
u32 key_id;
char rsa_signature[1024];
char metadata[32];
char content_hash[20];
};
int verify_cert (struct rsa_cert cert) {
char *cert_hash=SHA1(cert.metadata + cert.content_hash);
char *sig_hash=rsa_decrypt(cert.rsa_signature, cert.key_id);
if (strncmp(cert_hash, sig_hash, SHA1_LENGTH) == 0) {
return CERT_OK;
} else {
return CERT_BAD;
}
}
int is_a_valid_disc(struct rsa_cert cert, char *disc_hash) {
if(memcmp(disc_hash, cert.content_hash, SHA1_LENGTH) != 0) {
return DISC_BAD;
}
if(verify_cert (cert) == CERT_BAD) {
return DISC_BAD;
} else {
return DISC_OK;
Fakesign/Trucha Signature
The process of resigning/rehashing the TMD signature with a new signature containing a first null byte was referred to as creating a fake signature AKA “Fakesigning”. This method of fakesigning data would in turn “open the doors” for us to be able to run custom code in boot2 such as Bootmii and even run an altered game image without crashing our systems.
streamlinehd 