Betwiin Brick Repair

Betwiin Guide – This Is An Advanced Tutorial If you don’t understand everything here, I recommend you do not proceed as this is advanced brick repair and is not a suitable option for most bricks. Please consider ALL other options before continuing with this method.

I wrote this guide to help people wanting to use Betwiin to recover their bricked Wii but don’t know where to begin. If you try searching for a guide on Betwiin you will quickly find that there just aren’t any so I hope everyone appreciates me posting this info as it took a lot of hard work to figure this all out. If you have any questions, please post them in this thread and I will be happy to answer to the best of my ability.

NOTICE: IF YOU DON’T HAVE THE KEYS.BIN FILE OR AT LEAST KNOW THE KEYS FROM YOUR BRICKED WII THIS METHOD WILL NOT WORK AND YOU CAN NOT CONTINUE!!!

Betwiin (Summary)

Betwiin is program written by Bushing that can be used to make a Wii nand dump compatible with a different Wii console. This is done by using the keys from a bricked console to encrypt a nand dump from a donor console. The reason the donor nand needs to be encrypted with the bricked Wii’s keys is because each Wii has its own specific keys used to encrypt and decrypt local data. For more information on how Wii security and encryption works see this thread. Betwiin can be used as a last resort to completely restore any software brick so long as you have a compatible donor nand dump, keys from bricked/target Wii, and an Infectus modchip or similar programmer.

Step 1 – Extract Keys & Compare With Donor Nand

Prerequisites

1. Bricked Wii
2. Donor nand dump with same version of boot1 as bricked Wii.
3. Donor nand dump with equal version or greater of boot2
4. Infectus or Infectus2 Modchip and Programmer
5. Hex Editor
6. Xavbox Programmer v1.0.0.7
7. Wiinand v0.2
8. WiiFlash-Toolz-v0.2BETA.zip

First you will have to complete a full nand dump from the bricked/target Wii. This can be completed with Xavbox Programmer and an Infectus modchip. If you don’t know how to do this you should first download and install the Xavbox software in this thread and then take a look at The Infectus NAND Flashing Guide. Once the target nand is extracted you will have to compare it with the donor nand to make sure they both have the same version of boot1. To do this you will have to look at the first block of both dumps with a hex editor. The first block of the nand contains the boot1 information that we need to evaluate. To evaluate the nand dump open it using a hex editor, the boot1 block starts at offset 0 and ends at offset 00021a5f. Take a look specifically at the first 400 bytes or so of data and make sure they match (see img below). If the first 400-bytes from both nand dumps don’t match then you will have to find a different donor. You can also use Wiinand to find out what version of boot1 you have however, sometimes it comes up as unknown therefore comparing with a hex editor is the more accurate way to check if they’re the same. Also make sure that the donor nand you will be using has boot2 v4 as this will ensure you won’t run into any boot2 compatibility issues.

Step 2 – Save and Remove Keys From Donor Nand & Bricked/Target Nand

Option #1 – Use Simple Nand Converter You must already have a file from Bootmii named keys.bin from both Bootmii nand dumps to use this option (if you have your keys, skip this part for now and move on to step 3 – Preparing your donor nand). If you don’t have your keys then see option #2 below on how to extract them.

Option # 2 – Alternate Extraction Methods If you don’t have a keys.bin file and only have a nand.bin from your Bootmii backup, chances are that your keys are attached to the nand.bin file. To manually extract these keys you can open the nand.bin in a hex editor and select the last 1024-bytes of data. If your keys are attached you should see 42, 61, 63, 6b, 75 as the first five selected bytes and your last byte should a 0 which comes after a ton of other 0’s. You will also notice to the right of the hex editor program a readable line that says BackupMii v1 followed by a console ID. If you see all this then your nand does indeed have the keys attached to it. Now that you have the keys selected, copy and past them into a blank hex file by selecting File -> New File in your hex editor. Save this file and name it keys.bin, then put it in a safe spot as you will need to extract the keys from this file later.

Advanced Note on Reading keys (this part can be skipped) – To manually read the keys with a hex editor locate the keys.bin file and open it in the editor. The hmac key starts at offset 00000144 and is 20-bytes in size and the nand key starts at offset 00000158 and is 16-bytes in size. The keys attached to the nand.bin start at offset 21000000 and end at offset 210003ff. Just use the hex editor to copy them over to Betwiin accordingly (donor keys to input folder and target keys to output folder).

Step 3 – Preparing the Donor Nand

Depending on what type of dump you received from Bootmii you may have to remove the keys from the nand.bin. These keys are located in the last 1024-bytes of data in the nand dump and need to be deleted if they are included in the dump. The best way to do this is by using Wiinand to clean the donor dump. This option can be found under the extra tab in Wiinand v0.2 simply select the infectus radio button and then choose clean. You can also manually delete the keys using a hex editor to select the last 1024-bytes and deleting them. Once the donor nand is cleaned you need to move it to the input folder for Betwiin and rename it to flash.bin

Step 4 – Setting Up Betwiin

Option #1 Windows GUI Method – (skip everything in option #2 below)

DOWNLOAD: Simple Nand Converter Mod – Includes Betwiin for Windows

If you have your keys.bin file for both your donor and target Wiis you can use this method as it’s much easier than running Betwiin using Python. (BIG THANKS to bad_Ad84 for suggesting this.)

1. Start Simple Nand Converter Mod
2. Load keys.bin from donor Wii
3. Load keys.bin from bricked/target Wii
4. Move donor nand.bin to Betwiin -> input folder and rename it to flash.bin
5. Click on convert button and accept or decline all warnings
6. Betwiin GUI will start and should take 20 – 45 minutes to complete depending on PC speed

Option #2 Python Method – (the listed modules are required)

Prerequisites

1. Betwiin
2. Python Interface
3. Numpy Module
4. Pycrypto Module

To run Betwiin on a PC you will need to download and install Python for Windows. You will also need Python modules Numpy and Pycrypto installed to be able to run the Betwiin code. Once you have all this installed you will need to locate and setup the input and output folders in the Betwiin archive (this is located wherever you chose to unzip Betwiin on your computer.) Add the donor nand.bin (renamed to flash.bin), hmac-key and nand-key to the input folder and the target hmac-key and nand-key to the output folder.

Next you will need to start Python, then open the betwiin.py module and choose to run the module. If everything was setup correctly, Betwiin will automatically start decrypting the donor nand and encrypting it with the output keys from the target Wii. This will take around 20-45 minutes to complete. Once completed, you will get an output file in the output folder called flash.bin. Simply rename this file to nand.bin and use the Infectus chip to complete the dump into the bricked/target Wii.

Step 5 – Preparing the output flash.bin

If everything was done correctly, you should end up with a file in the output folder named flash.bin. Simply rename this file to nand.bin and it’s now ready to be installed into the bricked/target Wii. You will need your Infectus modchip and Xavbox software to complete this installation. If it doesn’t work it may be because the donor nand doesn’t have the same boot1 or has an older version of boot2 than the bricked/target nand. To fix this, you will have to upgrade the donor nand (You should use a donor nand with the same boot1 and boot2 v4 to avoid this issue). You can also copy and paste the boot1/boot2 data from the original bricked/target nand to the Betwiin output to maintain the same boot1/boot2 versions. As mentioned by Bushing, this tool is a last resort to revive your system and can be a very tedious process that sometimes requires a lot of tweeking to get it right.

© 2011 Streamlinehd – You may not copy this material without prior written consent.

Wii Security, Truchabug Explained

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.

If you wish to post this guide elsewhere a link back to this page as the source is required!

Nintendo Wii Having Issues?

There’s much that can go wrong with the Wii console and fixing the issue requires an in depth understanding of the overall functionality of this gaming system. To do this properly you must first identify the symptoms of the issue. This may include disc drive not working, certain games arn’t functional, system won’t turn on, boots to black screen only, or Wii doesn’t boot at all.

Disc Drive Not Working – This is usually a hardware issue and requires tools and know how to fix. The only exception would be if the disc drive works for some games but not for others. If this is the case, you are likely missing the IOS the game uses to play. To find the correct IOS for the game you can do a google search and download the wad for this IOS and install it using wad manager. If the disc drive accepts games but gives a can’t read disc error for all of them, you likely have a hardware issue and will have to disassemble the Wii to find the problem. The most likely issue is that the laser pickup inside the drive needs replacing. You may also find that there’s something inside the drive restricting the disc from being read properly. Sometimes the top drive spindle breaks off or a piece of plastic from the spindle comes off causing this problem. The fix for this is to find a replacement part and replace the spindle. You can find parts for this from eBay.

Wii Won’t Turn On – This is usually due to a bad or overcharged power adapter but could also be caused by a short in the console. The first thing you should do is remove the power cable from power source for at least 30-minutes and then try plugging everything back in. If that doesn’t work, you should try a new power adapter. If the Wii still doesn’t power on you may have a short somewhere inside the console. The short can be on anything attached to the Wiis mainboard. You may want to seek professional help at this point.

Boots to Black Screen or doesn’t boot at all – If the Wii boots to a black screen or doesn’t boot you may have a software issue, hardware issue, or a combination of both. There are many ways to go about troubleshooting this and you should start off by analyzing what you did before this happened. Did you mess around with the system menu or any of the IOS? Did the console fall off a shelf and hit the ground? Did nothing happen and everything just stopped working for no apparent reason? Because this issue can be caused by many things, it is best to get an opinion from someone who deals with this sort of thing. I’ve personally repaired hundreds of Wiis and know almost everything there is to know about fixing them. In addition to myself, there’s a great group of people just as knowlegable and they can be found at hacksden.com. This is a new forum dedicated to helping people with any of the above issues (caused by softmods and non-softmods), we can provide the best advice possible and have helped a countless amount of folks with these exact issues. As always, best of luck and we look forward to seeing you at the new site.

Wii Problems