Wii hacking explained

Cyan · Jun 14, 2018

Chapter 2 - The Wii's security system

Information Chapter 2 is not complete yet. It's missing few links and pictures to make understanding and read flow easier. Some areas are just place holders for future graphics.

If you want to help, you can create some (animated) graphics or write a cryptographic paragraph to detail how encryption and decryption process is working (RSA or Sha-1), or any part you think is missing.

This chapter will quickly explain how the console's security is working and how it has been circumvented.
It will also present the different elements and terms you will be susceptible to encounter when getting interested in general console hacking world. (Hacking scene)

Hacking the Wii (or vWii)

This guide is not directly written to tell you how to hack your console, but will cover what other guides fail to explain. It will eventually explain all the steps to install and use homebrew, how to fix other guides' errors and common user's encountered problems.

If you only want a step by step softmod guide to run homebrew, without understanding the reasons behind each step, then you can follow one of the existing guides. Though, they are somewhat old and might tell you to follow outdated and now useless steps, sometime even wrong things!
That's exactly why I'm writing this new guide: A lot of people are following old guides which tell users to do wrong things and get a lot of compatibility problems. I hope this will provide help to fix all encountered common issues (wrong cIOS, black screens, HDD not detected, etc.)

Existing softmod guides

Wii

modmii (Up to date)
Complete Softmod Guide (Up to date)
Mod4.3 and below (old, but up to date)

WiiU's virtual Wii

The definitive vWii Hacking guide (gbatemp, little outdated but very detailed)
Complete Softmod Guide (up to date)

Console Brick

"Brick" is a word you might have read often if you are interested in electronic device hacking.
But what does it mean?

[picture of wii brick]

Console hacking involves either hardware modification (called hardmod) by soldering additional electronic parts like chipsets (mod-chips) into the motherboard, or software modification (called softmod) by editing important files used by the system.
These parts could be done wrong and result in your console not working anymore. Based on the Wii physical box shape, having a broken and non-working Wii console would be as useful as having a "construction brick" (you could pill them up as if they were bricks).

The word "brick", which exists since the Wii hacking era, has since then been commonly used to describe all broken consoles as a result of a faulty or wrongly done hacking procedure, or any user error affecting the operating system's normal behavior.

A brick state can be defined into two sub-groups:

Full-brick:
The console is in a state in which it can't boot or launch any program. It's usually a hardware's fault (bad soldering job, water spread in the console, etc.), or a software issue (deleted files, corrupted database, etc.).
The full brick usually requires a hardware modification to fix it (parts replacement, chipset flashing tools to restore a full NAND backup, etc.) or the use of recovery mode (when available).
Sometime, a full brick cannot be repaired, or is beyond end user's knowledge to do it.

Semi-brick:
The console appears to not be booting, or boots but can't launch some or any applications.
If you followed the appropriate "brick prevention" steps when following one of the console hacking guide (bootmii, priiloader and NAND backup), you can usually recover from this brick using a software method to get your console back in a working state. It usually involves specific and different steps based on what you have and what you did to brick your console.

Fixing a brick:
If your console appears to be bricked, DO NOT ATTEMPT TO FIX IT YOURSELF. You could make things worse.
Create a new thread with as much explanation as you can and wait for proper fixing steps from knowledgeable users. If possible, even wait for confirmation from multiple users before performing what you've been told to do, as you might get wrong information from users who are not understanding your individual situation.

The Console security system

To secure the console, Nintendo uses a file signature system with RSA encryption.

For now, you don't really need to understand how the RSA encryption is working or how a signature is used to verify if a file is legit or has been modified.
All you need to know is the console uses the IOS program (in the ARM processor) to check the file legitimacy, and either answer "good" or "wrong" to the PPC program asking to check a signature.

The signature is checked to verify if a file is original or has been tampered with, and if a program is officially licensed by Nintendo or not.
The signature is verified only at title installation, the console consider that an already installed file has passed the verification steps and therefore doesn't need to be verified again at launch. This situation has been abused and allowed easy hacking on the console: Once a Title is installed on the console, you can launch it with your official unpatched system application. No custom firmware was needed to be developed or installed to run homebrew unlike other consoles.

Trucha bug and IOS236

Trucha bug

If you want to learn how signature are working, you can read the next big chapter (Security and cryptology), but it's not necessary to understand how Trucha bug is working. You can skip it completely as it can be hard to understand for end users.

For now, this is all you should know:

Trucha bug is one of the first vulnerability found in the Wii security system and is still used today.
Trucha bug is related to the signature checking process. All the IOS had this bug up until 2008. The first released IOS without this vulnerability was IOS37, at the same time Nintendo patched the bug in all previously released IOS.

This bug lets users abuse the IOS's signature verification method to always answer "good" even if the signature is wrong, allowing the program currently running on the PPC CPU to continue its execution instead of terminating.
Applications taking advantage of this bug are Disc channel, Title installers (Wad manager, IOS installer) and indirectly the System menu 4.x (for its SD menu).

IOS236

When nintendo patched the signature bug in existing IOS, hackers decided to "unpatch" one of the IOS to restore the bug. IOS36 was chosen and tools like "IOS36 bug restorer" or "IOS236 installer" were created.

To preserve the compatibility with official games which still uses IOS36 and keep this IOS36 legit (unpatched), the patched IOS36 result was installed into another, unused slot: Slot 236.

This is what you should understand: The slot 236 contains a copy of the IOS program located in slot 36, but this copy has the signature check bug restored (patched back).
It's commonly said "IOS236 is based on IOS36".
You can also see the format "Slot[base]" like this : IOS236[36], which means the same thing, slot IOS236 contains an IOS program based on a copy of the official IOS located in slot 36.

Why slot 236?
Noticing Nintendo always released IOS in lower slot numbers and in incremental order, it was thought a good idea to install patched, unofficial, IOS in reversed order from the available slot range (from 255 back to 0).
The 200 mark was far away enough from the official IOS to consider the above slots safe to use for hacks without conflicting with Nintendo's legit IOS. As a fact, Nintendo's highest ever used slot is slot 80.

By common usage, or untold convention from hackers, all hacked and patched IOS were therefore installed in the slot range from 200 to 255.

AHB Access & HAB_PROT

AHB Access is one of the most important vulnerability in the Wii, even though Nintendo designed it as a feature.

AHB is the Advanced High-performance Bus connecting the ARM CPU with each different hardware's elements (RAM, NAND, SD, USB, etc.). The IOS running on the ARM CPU controls the security and specify which hardware connected to AHB can be accessed by the program running on the PPC CPU.

By default, the Wii has the AHB access protected. You probably already seen the name "AHB_PROT" and people telling to "use AHB_PROT" or "enable AHB_PROT", or "disable AHB_PROT", and you are probably confused about what it really does or what you have to do. What you want is to disable the AHB PROTection to get full "AHB Access" and unlock all the Wii's capabilities for your homebrew.

History of AHB access

The same way a program launched on PPC can request a specific IOS to be loaded in the ARM CPU, it can also request specific hardware access rights.
This feature is easily exploited by editing a value in a Title's corresponding .tmd file to request access to ALL connected hardware (NAND, USB, etc.)

There are two possibilities for homebrew to get AHB access.

Homebrew launched from a channel (either a Full channel or a Forwarder channel) have no problem to get access to all hardware. The homebrew developer needs to provide a compatible channel (in form of WAD or channel installer) with proper value set in its .tmd file.
Homebrew launched from The Homebrew Channel can inherit AHB access rights.

If now, homebrew can easily get AHB access, homebrew launched from old versions of The Homebrew Channel used to require different methods to get access to hardware:
Before HBC 1.0.8

by using a custom/Patched IOS (like cIOS236, or cIOS202), generally used by WAD managers, file explorers (ftpii, wiixplorer, etc.)
by using a hidden channel (TitleID "DVDX") with the AHB flag enabled in its tmd file to unlock DVD-Video disc access to be used by homebrew media players (WiiMC, etc.)
Inherited from HBC (old method), by preventing IOS reloading at homebrew launch time (using the < no_ios_reload/ > tag in the meta.xml).

Since HBC 1.0.8
Since The Homebrew Channel v1.0.8, HBC has full AHB access and can grant access on request to launched homebrew, dropping the need to use cIOS or DVDX method to access connected hardwares.
To keep AHB access, the launched homebrew needs the < ahb_access/ > tag in its meta.xml file. If the launched homebrew needs USB2.0 support, it has all interest in using IOS58 (the first official IOS with USB2.0 support). If your HBC is not using IOS58, you'll get AHB access but not USB2.0 access in your homebrew.

If your HBC doesn't use IOS58, you should follow the steps below to update it.
add link xxxxxxxx

Chapter 2.2 - Wii Security, Cryptology and Trucha bug in detail

This section is a quick explanation on cryptology and signature system used by the Wii, and a more detailed explanation on Trucha bug. This is still targeted at users who are new to hacking and computing world. If you are looking for a more technical and detailed guide, you can go to wiibrew.org.
A lot of information and details are left out on purpose to make it simpler to understand for someone new to hacking and security systems.

This chapter can be completely skipped if you only intend to learn about homebrew usage. Understanding how the security is handheld is optional.

What is a signature? When is a signature checked?

The signature is an encrypted data used mainly to secure all files or hardware a user manipulate or may have access to, like game discs and digital files transmitted over Internet from eShop to the console.

For game discs, the signature is checked on each launch.

For eShop's received titles, the signature is checked ONLY at install time and have two outcomes:
If the signature is correct, then the file is written into the console.
If the signature is wrong, the file is rejected and nothing is installed into the console.

The console's security is based on the trust of this installation verification step. All files already installed in the console are trusted and not checked anymore.

Why is faking a signature needed?

The primary use of the fake signing bug was to allow game disc edition (editing disc file content to mod a game, edit video mode, etc.)
It was also used by The Homebrew Channel installation process on its first release.
It was then quickly used for piracy by release groups to allow dumped WAD installation on all consoles.

Like said above, the signature is checked to install a Title (usually a channel) on the console.
Channels bought on eShop are linked to the console used to buy it using a unique identification ConsoleID information stored into the channel's ticket.
That information is part of the signed data to prevent editing the ConsoleID information to another ID which would allow installation on a console for which the channel wasn't intended for.

How File's signature is working

A signature is a two step verification system used to check if a file is official and from a trusted source.
To verify the legitimacy of a file, the console is using a signed hash method which involves two cryptographic methods: checksum and encryption.

Next chapters will explain what checksum and signature are, how they are used on Wii, and finally how they have been exploited.

What is a file checksum?

A checksum (also called Hash) is a numeric representation of a string or a binary data. There are different checksum calculation methods, the most known are CRC32, Sha-1 and MD5. The Wii is using Sha-1.

To get an easier understanding, instead of explaining how Sha-1 is working (which is complicated for someone who is not into cryptography), this chapter will explain how a chesum works in general by using a simplified method: Using the alphabet letter's position as letter's value.

In this example, we will do the checksum of the word "Guide":
Considering A=1, B=2, C=3, up to Z=26, you can say this word can be represented in numbers, by replacing each letters with their value, as: "07 21 09 04 05"
Adding the sum of each letter's value (7+21+9+4+5), you get the number 46. So you can say 46 is a cheksum of the word "Guide".

From now on, the word "Guide" will be called the "source", and the result 46 will be called "checksum".

If you edit one letter in the source, you'll get a different checksum value. This is how a program can check if the original data is what is expected or if it has been modified.
For example, if you want, for hacking or exploit reason, the last letter of the word "Guide" to be a "o" instead of a "e", editing the word to "Guido" will result in a checksum value of 56 (+10 than expected value).

You probably wonder what prevents you from editing other parts of the source to still get the correct checksum result? Well, you'd be right, and this is called "forging" a checksum.
For example the word to "Dredo" (04 18 05 04 15 = 46) has the same checksum value than "Guide", you just have to be sure you can edit the other letters without causing bugs or crashes in your program and it doesn't alter important data.

How to exploit a Checksum?

There are actually 2 methods to exploit a checksum
1. Forge the source to generate the same checksum value than the expected value ;
2. Edit the checksum's expected value.

In order to verify a file's checksum, an expected checksum value has to be stored somewhere to compare the calculated checksum with. That expected value is often stored in a secondary file or in the file itself using only specific parts of a file to verify the checkum value. On the Wii, both the checksum and its expected value are stored in the ticket, which is used to store the Title's owner information, like the ConsoleID.

The second exploit option seems the easiest, but Nintendo encrypts this checksum's expected value and only Nintendo has the encryption key. It can be decrypted with a public certificate located in the Wii, so we can find the expected value but it can't be edited and re-encrypted by users. You can't write a non encrypted value either, or use another encrypting key because the console expects it to be encrypted using the Nintendo's private key only. (More information about keys on next chapters)

Therefore, at this point, only the first option seems possible to exploit.

Checksum on Wii

It would be very easy to forge a checksum value by editing the source data if it used alphabetic letter's position and simple sum algorithm like used in the example above, but the Wii uses Sha-1 checksum method.

Sha-1 is using a strong algorithm which generates a 160bits long number (ex. in hexadecimal "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12"), and this value is completely different for every small changes done in the source. You can't predict a checksum value by editing the source data. Two different files will always generate two completely different Sha-1 checksum. The Sha-1 method was very secure for all the console's life. It's only in late 2017 that a flaw was found in the algorithm and a Sha-1 collision calculation was demonstrated (2 different files sharing the same checksum) but it's very hard to do and can't be achieved in Wii hacking.
Note: 160 bits = 20 bytes = 40 hexadecimal digits (letter/number).

Quote from Wikipedia

Sha-1 of string: "The quick brown fox jumps over the lazy dog"
gives hexadecimal: 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12

Even a small change in the message will, with overwhelming probability, result in many bits changing due to the avalanche effect. For example, changing dog to cog produces a hash with different values for 81 of the 160 bits:

Sha-1 of string: "The quick brown fox jumps over the lazy cog"
gives hexadecimal: de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3

As you can see, it's nearly impossible to predict a full 160 bits exact Sha-1 value by editing the source data because of its unpredictable nature.

Encryption on Wii

All the files transmitted over internet (from eShop to console) are encrypted, but their full security system will not be covered here. What's important for the Trucha Bug is only the ticket system.

All titles (disc or channels) use a ticket system for security. The ticket is a file provided along the Title which contains information on the Title itself (TicketID, TitleID, TitleKey, etc.) but also contains two important data : The ConsoleID which determines if the console can launch the Title, and the expected Ticket's checksum to verify if the ticket is legit.

To prevent edition of a ticket's expected checksum value, which would allow any non copyrighted files to be installed on any console, Nintendo encrypts this value using a private key.

Instead of encrypting the entire Ticket, Nintendo keeps it unencrypted and only encrypts the expected checksum's value for a faster access so applications don't need to decrypt the ticket to read its other content.
The checksum is decrypted and checked only at installation step (downloading a game on eShop, launching a game from SD menu or installing a Wad for example), if it's legit then the Title is installed on the console (or, for game discs, the game is launched).

Encryption and Keys

The Wii uses an asymmetric RSA-2048 bits encryption method using a Private/Public key pair to sign its files.
The private key is owned only by Nintendo and is used to encrypt and signed files.
The public key is present in, and used by, all consoles.

The private/public RSA-2048 key pair are static and identical for every consoles.

[insert a graphic ?]
developer> data > û Nintendo's Priv key > encrypted data ---eshop or game disc-----> Wii > encrypted data > ù public key > data

The decryption algorithm doesn't verify if the input string is encrypted with the private key or not, nor if it's even encrypted.
The encryption/decryption algorithm just convert input data into output data using the provided keys as scrambler or unscrambler.

Based on that behavior, you can edit the encrypted signed data in hope to get the expected checksum value once the console decrypted it.
But trying many possibilities randomly and decrypting them with the public key until you get an exact 160 bits checksum value would take billions of year with current computer's power.

The RSA encryption is secure and can't be calculated or even brute-forced using a program trying all possibilities.

Then, where is located the signature vulnerability?

The Wii uses two good checksum-attack prevention :
1. The source can't be forged to get a specific checksum value (sha-1 checksum) ;
2. The expected value can't be calculated or brute-forced (RSA-2048 encryption).

The signature vulnerability lies in the IOS's function used to compare the calculated checksum value with the expected checksum value.

Graphical representation of the signature checking process:

File's unenc part > calc chksm > xxxxxxxxxxx (A)
..........................................................|------- > IOS compare string A with string B > Good/wrong ?
File's enc part > key > dec > xxxxxxxxxxx (B)

1. calculate the checksum of the file --> A
2. decrypt the expected checksum value --> B
3. compare A and B together

Explaining the Trucha/Signature bug

In order to compare two elements together, there are two different methods : strcmp() and memcmp()
The former is used to compare alphanumeric strings, the later is used to compare binary memory banks.
The signature bug exists because Nintendo used the string method to compare binary data.

Both comparison methods checks one bytes at a time (first byte of string A with first byte of string B, etc.), if identical it checks the next ones up until two bytes are different or it reaches the end of the data to compare.

The binary data comparison method compares a specific length of data (for example, 20 bytes of Sha-1 checksum values), while the string comparison methods uses a non-alphanumeric string detection code (0x00, null character, also noted \ 0) to determine how long the stings are.

String A : "You are reading this Guide\0" converts in hexadecimal to 596F75206172652072656164696E67207468697320477569646500
String B : "You are reading this Forum\0" converts in hexadecimal to 596F75206172652072656164696E67207468697320466F72756D00

in red, the differences between both strings.
in green, the "end of string" null character (0x00).

The comparison stops after comparing position 22 and replies WRONG because the 22th characters are different (G and F).

If one of the string contains the terminating null character (0x00) anywhere before the "real" end of the string, then the comparison stops at this location, even if they are both identical.
String A : "You\0are reading this Guide\0" 596F75006172652072656164696E67207468697320477569646500
String B : "You\0are reading this Forum\0" 596F75006172652072656164696E67207468697320466F72756D00

The comparison stops after comparing the 4th character, and replies GOOD even if the strings are different, because all compared characters were identical (including the null character).
If only one string had the null character, it would return WRONG because null and another character are different.

This vulnerability can be exploited by trying multiple random encrypted signature value and editing the source's data until the first byte is set to zero on both the source's sha-1 checksum and the decrypted hash expected value.

Randomly editing the encrypted data string to get an exact 20 bytes decrypted value would take years, but now you only need to get 1 byte.
Generating different random 2048 bits encrypted strings until you get a 0x00 on the first byte of the RSA decrypted string is very fast (few minutes), but doing it is even unnecessary.

For each data, the RSA algorithm always produces a different encrypted/decrypted value, except for zero. "0" always encrypt/decrypts to "0" !

Knowing this means no calculation is needed. The 2048 bits encrypted signature can be manually replaced with zeros and you'll be sure to get a 0x00 as first byte for the decrypted file's expected checksum value.

What's left to do now is forge a Sha-1 checksum by editing an unused part in the file you want to "trucha bug" (the ticket) until you get a checksum starting with 0x00. Again, you don't need to take care of the full 20 bytes, only the first one is important, which is done almost instantly on any computer! (less than a second)

Demonstration of trucha bug

This section will explain how to patch one of your dumped channel to be able to install it on another console.
You don't need to do it yourself because tools like BlueDumpMod is doing it automatically, but this is to illustrate how it's done.

Step 1: replacing your consoleID

Dump and extract your channel's content.
To make a channel initially tied to your console work on all consoles, you need to edit its ticket file which contains the ConsoleID.
To untie it from a specific console, set the "consoleID" to 0x00000000, which allows launches on all consoles like if it was a game disc.

By editing the ConsoleID (4 bytes at 0x01d8 in ticket file), you broke the signature verification process which prevents you from editing the ticket's data.
The calculated checksum doesn't match the expected decrypted value anymore, so the Title will not install on another console because the IOS will not allow wrong signature.

Step 2: forging the signature

In order to force the IOS's signature verification to still report it as good, you need two things:
1. The forged ticket's checksum ;
2. An IOS loaded in the ARM processor with the Trucha bug.

1) Forging the ticket
Now you need to edit other parts of the ticket's data to get 0x00 on the first compared byte of both:
- The decrypted signature (the expected value of the ticket's hash) ;
and
- The calculated checksum of the "Ticket's checked data".

Replacing the encrypted signature with zeros is the easiest part to get 0x00 on the decrypted's first byte value.
Locate the encrypted signature in the ticket (0x04) and replace all the 256 bytes (2048 bits RSA signature) with 0x00.

The second step is done by brute-forcing the ticket's verified data (from "Signature issuer" at 0x0140 to end of the ticket) and replacing an unused value until you get a Sha-1 starting with 0x00.

Problem when editing random location in the ticket
A lot of Release groups were editing values at random location in the ticket instead of real unused data, which sometime could prevent the Title from installing, or functioning correctly on the console.
The "Common key type" data was often used, breaking encryption for some channels when "0x02" was set. 0x02 is the normal value for Korean Titles which uses a different Common key, breaking title installation process.

2) Using an IOS with Trucha bugs
To install a channel with the fake signature, you need to use an IOS with the signature bug.
Wad managers can either loads an IOS with the bug already present (old IOS36), with the bug restored (IOS236, cIOS), or with the bug temporarily patched in memory (IOS58+AHB access).

The cleanest method is using AHB to patch the IOS temporarily. The patching process can be done by the "wad installer" homebrew itself.
By using the proper program, the user installing a fake signed wad don't need to care about any previous steps nor install a patched IOS.
The signature being checked only at install time, the Title will launch fine, even with a wrong signature, using the official requested IOS from the system menu.

Step 3 : repacking and installing the channel
Once done, you can pack the new channel's content and edited ticket into a wad.
Launch a wad installer which patch the Trucha bug in memory using AHB access, or reload into an IOS with the bug still present in it (cIOS236, etc)
Install the Trucha bug patched channel.

Cyan · Jun 14, 2018

Chapter 3 (and more, to be split !) - HOMEBREW PRESENTATION

******Start of Wii homebrew presentation/setup/install? *********

do we explain what homebrew is here?

Homebrew

detail possible homebrew format : Elf, Dol, Channels ?

keep this section before "hackmii installer", as it's the first homebrew used by the people, and it's in elf format.
it would be nice to explain what elf file is before even using it for the first time.

and explain the 4 methods to launch homebrew :
SD Card, Channel, Channel+SD, Wifi

Full Channels and Forwarder channels
Channel : Full or forwarder ? (alt section title)

Explains the differences here.

Hackmii Installer

Explain what it does (quickly)
Tell users to install bootmii as IOS/Boot2
Uninstall DVDX (not really needed)
Explain what "install @ boot2" means.
Prepare SD Card
install HBC

Hackmii installers -> SD / SDHC not working with old game exploits
not a hackmii problem, but a game's IOS problem. Use browser flashax to bypass.

vWii works fine with SDHC (WUPhax using Miimaker has SDHC driver)

Bootmii

What is bootmii?
What is Bootmii@boot2 ?

Boot1 signature bug, fixed in 2008.

Boot2 v2/v4 etc. ? (can't be downgraded ? why ? I don't remember, read hackmii blog again)

DVDX

can be uninstalled from hackmii installer

The Homebrew Channel

What it is
How to install (from Hackmii installer)
How to unistall (from ...)

note using IOS58 ! How to fix ?

How to use HBC
Where to put homebrew apps folder/
which files to use (meta, icon, boot)
option to HBC (press 1 or 2)

Add homebrew by wifi
Launch homebrew by wifi
Theme HBC

Priiloader

Priiloader is a homebrew program primarily used to protect the System from possible brick.
It is meant to be launched earlier at boot to get a solution to fix your console in the event where your System menu can't be loaded.
It is often the first installed and use application after adding The homebrew Channel on your console.

Priiloader application installs itself in the System menu folder and takes its program's filename (00000000.app) in order to be launched by Boot2 in place of the System menu. The installer first renames the real System menu's application (to 00000001.app) to still be able to access it when needed.

Priiloader's main interest is the fact that it displays a graphical user interface only if you hold the Reset button at Boot. If you don't hold the reset button it loads your real System Menu right away, making Priiloader hidden to end users and your console feels like it has not been hacked.

Visual representation:

Console boot without Priiloader:
Power > Boot0 > Boot1 > Boot2 > TitleID 1-2 (system menu)

Console boot with Priiloader installed :
Power > Boot0 > Boot1 > Boot2 > TitleID 1-2 (Priiloader)> TitleID 1-2 (System menu)

Reinstalling or updating your system menu will replaces the program (00000000.app), effectively removing Priiloader. You need to launch Priiloader installer again after reinstalling/updating your system menu.

Priiloader's features

When accessing Priiloader's interface (holding reset at console's boot, you get access to two important features:
- Autoboot menu
- System menu hacks

The autoboot menu lets you choose priiloader's action when you don't press the reset button and lets it boot automatically.
You can choose to either boot into: The (renamed) System menu like a non hacked console, The homebrew channel, or a user installed homebrew (boot.dol)
Once in priiloader, you can also manually exit by choosing from one of these launching methods.

The hacks menu is used to modify how the System menu program works by patching its functions in memory before launching it.
You can add or remove features, like prevent console Update, region free for game discs or channels, auto-press A button on the "press A" screen, etc.

Priiloader an AHB access

Priiloader lets you install one homebrew to automatically launch it at console boot.

However, Priiloader doesn't have the necessary power to grant AHB access to that launched homebrew so if it relies on AHB access (instead of cIOS) to get hardware access, then your program will not work correctly or even at all.

If you need to launch a program requiring AHB access, and don't want to auto-boot into The Homebrew Channel, you can get AHB access from a channel. If you've read the AHB section, you'd know only HBC or channels can grant AHB access.
Unfortunately, Priiloader doesn't have a channel launcher function, so you'll have to install one yourself into Priiloader's boot menu.
There are two possibilities for you at this point:
- A specific channel booter program for the homebrew you want to launch.
- A program which lets you select and memorize which installed channel to launch automatically on next boot.

Edit 2020:
DacoTaco, priiloader's developer, said it provides AHB access if the dol you want to install is provided with a meta.xml containing the no_ios_reload tag used by HBC.
When installing the dol in the boot menu, it also generate a boot information for priiloader to use and set the option to prevent IOS reloading and grants AHB access.
So, a third option to get AHB is to install dol with their meta.xml !

Visual representation to launch homebrew with AHB:

Priiloader > System menu > Channel with AHB
Priiloader > The homebrew Channel > homebrew with AHB
Priiloader > installed homebrew to launch a channel > Channel with AHB

Available program to launch a channel:
- Crazy Intro (generic channel launcher)
- USBLoaderGX UNEO forwarder booter

cIOS

cIOS
what is it, do I need it (IOS58 is enough for most homebrew), base IOS, which base to choose (see other chapter), how to use, how to update, existing cIOS list since rev14.... d2x v10-alt
List of waninkoko/d2x since rev14
do not use rev20(b), it has wiimote sync and game freeze issue.

cIOS236, 202
Hermes
Waninkoko
d2x

explain d2x v8 / v10 / v10-alt differences and all the pro/cons.
But don't tell how to install here, redirect to install section.

Which cIOS do you need?

The used cIOS affect the hardware and software compatibility.
Some games will need a specific base, while other games will need a specific version.
And remember : NEWER IS NOT ALWAYS BETTER !

Most games will work fine with d2x cIOS v8 final, or d2x v10 revision 52, both based on the original IOS57.
Do not install d2x v10 revision 53 if you don't know the reason why it exists in the first place, and the differences with r52.
Also, do not install a cIOS based on IOS other than 56 or 57 without being sure it's required.

Recommended :
d2x v8 final, base 56 : good for most games, has the best USB access speed, but not all games are compatible.
d2x v8 final, base 57 : good for even more games, but slightly slower to access USB. I'm sure you won't notice a difference if you don't actively compare with base56.

cIOS and Game compatibility list
Call of Duty : base 57, any cIOS version NOT d2x r53
Metroid Prime : don't use NAND redirection (emuNAND save)
Just dance 2017 : base 57, hermes cIOS or d2x v8 or v10r52. NOT r53

cIOS Install

Before starting
Before installing or editing your setup, don't you think it might be a good idea to know what you already have installed?
Knowing and understanding what is installed on your console is better to use it at full power, instead of randomly messing with it in hope you'll get a good-enough working setup by chance.

First, you should read the section above to know which IOS you need, and why.
Then, you can look into your console to see if you already have what you want or need. no need to risk bricking your system if not needed.
finally, you will install or replace IOS if needed.

What you need to remember:
1. Slots are NOT interfering with each others. if you have an old cIOS installed (Hermes) and you don't need it anymore, you don't have to uninstall it. It will just be ignored by your homebrew application if it uses another slot!

2. The slot number is irrelevant!! you don't NEED a number, but what's actually inside that slot number. If you've read on a forum that you need cIOS249 or slot250 to fix your problem, then you should immediatly understand that the suggestion is wrong! What's important is not the slot number, but the cIOS version and base.

Ready to install
Now that you know what you need, and you want to install one or multiple (custom)IOS files, you need to choose the method you'll use.
To install an IOS, there are two main methods:
- using a homebrew installer ;
- installing an IOS in a wad form.

how to install (wad, modmii, pimpMyWii, specific installers)

Compatibility (base57 for CoD, just dance, etc.) 55/38 for (wiispeak, the conduit?), 56 for spyro Skylanders?

d2x differences v8/v9/v10/v10-alt

Trouble shooting : how to know which IOS I have? How to report my setup ? (syscheck, cIOS info base/ver)

DarkCORP/CIOSCORP

explain what it is.
Why all IOS are patched (adds trucha bug and ISO9600 patch to launch burned disc without modchip, but limited to 3x read speed instead of 6x)

Should you keep it?
how to remove?

Syscheck

What it is
how to read it/What it means
What you want and need (explain which lines are useful, 58, 249,250,254)

/HBC/Nintendont/Homebrew : 58
USBLoaders : 249 / 250
EmuNAND : 254

Fixing your console using syscheck log

with modmii
->common setup
manually
-> specific needs (port1, dual HDD, etc.)

see cIOS install section and install the needed IOS.

PimpMyWii

What it is ?
Is it good or bad?

Modmii

What it is ?
Is it good or bad?

Chapter 4 (and more. To be split later) - Homebrew usage

Most guides just end here, and the users are often lost and don't understand what are available to them and what they can do next.
I'll try to add or even just link to this guide every help and answers I provided on the other forum's threads so there is a single place to find all my useful posts.

the majority of users only want to play Wii games, gamecube games and WiiWare/Virtual console games easily (USBLoader, emuNAND), but there are other homebrew available to enjoy : Homebrew games, Media players (WiiMC), emulators (ScummVM, DosBox, console emulators, etc.), or even apps (homebrew browser, ftp or file explorer to manage your files directly from the console). Each homebrew have their own configuration steps, along with hardware and software requirements, and users are often lost in all these different requirements.

Compatible Devices

Change title to : Hardware requirement ? make a section Software requirement ?

SD/SDHC
HDD
Compatible devices (flash, usb2, usb3, hub)
link to wiki usb device compat

Format : MBR FAT32 only for HBC.

keep here or move to USB LOader section ?

Different HDD format (WBFS, FAT, NTFS, Ext, exFAT, WiiU HDD format), how to choose?

Explains the WBFS format is ok but deprecated -> wbfs files
What is Scrubbing
what differences with Trimming
what is cISO (hermes only)

Now FAT32 is fine (since rev18)
(NTFS since when?)

How to format
How to convert WBFS to FAT32

MBR, GPT, Advanced Format, e512

vWii : Prevent Format prompt, how it works, Ustealth, Linux

Game loaders

Existing loaders
wii / GC : GX/Flow/CFG/Post
Channels : emuNAND/Mighty/Loaders/neek

Accessories and gamepad
wireless controllers
gamecube controllers adapters
HID
It works with nintendont, why can't it work with wii games?

WiiU Gamepad support

Old loaders

(Mighty channel, DM, DML, Devolution)

Nintendont

Postloader

CFG Loader

WiiFlow

USBLoaderGX

Installing Game

WiiU

Gamecube

Channels
forwarders, wii, vwii, wiiu, https://gbatemp.net/threads/usb-loader-gx-forwarder-channel-for-wii-u-menu.482595/unread

Game compatibility

Driver : neek, or USBGX 2.3, or Wiiflow
Tintin : neek
Call of Duty Modern Warefare Reflex : d2x v8/v10 base 57
Just dance :
Sing it : v8/v10 base 57

Video mode problem

black screen at launch
game region/console region
dol patch info

Chapter x - emuNAND

EmuNAND presentation

Temporary guide : https://gbatemp.net/posts/6592730

what it is
NAND and emuNAND differences
EmuNAND type (cIOS, neek, neek2o)

creating NAND copy to use with emuNAND

Using emuNAND with cIOS

required cIOS version / base
why

Creating Neek using Modmii

Temporary guide : https://gbatemp.net/posts/5508831

Creating Neek using Neek installer

Temporary guide : https://gbatemp.net/posts/5508831

FAQ and Troubleshooting

Identifying the problem and getting proper help

When you have a problem, the first thing you need to remember before doing ANYTHING to your console to prevent making things worse is to stop what you are doing and think about what you already have.
Editing, installing or formatting randomly is NEVER a good idea, it could be worse and end up in a non fixable state.
When you are not sure if it's safe, create a new thread and ask for help.

Some important rules you should follow when you want help:

Do not create multiple threads, keep your problem in one single place. Asking for help in multiple threads (or forums) will not provide you faster or better help but instead will create confusion. People helping you in one place will not know what you where asked to do in your other help place and it could end up conflicting with new fixing steps, or you might even miss the correct fix. It's harder for helpers, harder for you and it clutters the forum for nothing. If you consider that nobody saw your question, just ask for more help in the same thread instead of posting elsewhere. Bumping a thread is fine if not abused: wait 1 day, then 1 week, then 1 month, if still nobody provided an answer then you can let it die because it probably mean nobody knows how to help you on this forum. Maybe one day someone will see your message and help you, it could take weeks or months.

Do not follow youtube tutorial! NEVER, EVER!
Youtube tutorials are done by unknowledgeable noob children not understanding what they are doing, 100% outdated, 99% wrong, 50% dangerous!
Youtube tutorial is the reason why you need help, right?

- Do not be impatient, helping peoples have a life, they are in different time zone, it can take some times to get a reply (wait at least 1 day, not 5 minutes, before thinking nobody saw your message).
- If you expect help, follow what helping people tell you to do, do not improvise or think ahead. This is very infuriating when users don't follow what they have been told to do.
- Always keep the helping people updated to know what you did, what worked or didn't, if it helped or not, etc. communication is important!
- Detail your problem (don't say "it doesn't work", people don't have working crystal balls to know what you are talking about)
- Provide the names and versions of all you can think of (console region, system menu version, HBC version, IOS used by HBC, and all your homebrew you have problem with)
- If your problem is related to hardware (SD, HDD, controller) give the name, brand, size, partition format, etc.
- If your problem concerns a software, post a syscheck log if you don't know the IOS base/version/slot your are using.

- If it worked before, try to remember what you did since that time and tell about it.
- Always try to narrow the possibilities and your problem by testing different elements. If your USB device is not detected, try another one. If your wiimote has issue, try another one. If your game doesn't work when launched from one loader, try another loader, try another game, try another IOS slot, try another USB Port, etc.
If it works by swapping one of those, then you know on which element to focus. If it still doesn't work, it likely isn't your problem and you can try swapping another element.
- Remember to NOT change your internal console's IOS or channels by yourself, always ask first. You can try to narrow the issue by swapping hardware elements only.

Examples of BAD and WRONG help requests (open the spoiler to read)

My loader worked fine until now, I did nothing and it doesn't work anymore, please help!

Why is it bad?
- "My loader": There's no detail. Which loader name? which version? Wii or vWii?
- "Doesn't work": Doesn't work doesn't exist. Doesn't work is not a real problem. Doesn't work could be because you forgot to switch on your TV...
We don't know what doesn't work. The console doesn't power up? no pictures? the system menu doesn't appear? the homebrew doesn't launch? it launches but freezes? it crashes? where and when? at startup, when listing games, when downloading a file, when launching a game, it affects all games or only specific ones (give the tested game's name!), and so on. Always explain what you expect and what you see instead.
- Missing information: There's no information about console's region, HBC's version, loader's version, used device SD, USB, HDD or Flash drive, partition format, etc.
- Did you try to narrow the problem yourself? did you try another game, loader, IOS slot, SD, HDD, wiimote, console, did you try to reset the settings or reinstall the homebrew from the start (delete the entire folder on your SD and reinstall), etc.

Identifying the issue
It's not possible, you need to ask questions to the user.

Suggested help
It's not possible, you don't know what the problem is.

Copying a game to USB freeze at 1%, what's wrong????

Why is it bad?
- It doesn't provide the used homebrew (CleanRip or USBLoaders?)
- It doesn't provide the used device (HDD or Flash?)
- It doesn't tell if it affects only one game or all of them
- It doesn't tell which IOS is used by the dumping homebrew

Identifying the issue
- It could be any of the above.
- Based on how frequent that issue is occuring on the forum, it should be easy to suggest a fix.

Suggested help
- DO NOT USE FLASH DRIVES! (Flash stick, USB Stick, USB key, everyone always name it differently). Flash devices are hardly compatible with Wii and vWii and known to freeze.
- If it's already using HDD instead of flash: Ask the user more information to narrow the problem, IOS, partition format, used homebrew, used device (sd, usb, lan, etc.), and from the new answer start the analysis again to narrow the cause.

Example of GOOD help requests (open the spoiler to read)

My wiimote lag, freeze or unsync randomly when I play a game launched from USBLoaderGX r1268.
I tried other wiimotes (normal and wiimote+), but I have the same problem.
My setup: Wii 4.3E, HBC 1.1.0 using IOS61, cIOS249 rev20b
*syscheck log posted in spoiler*

Why is it good?
- It explains the problem. Concerns: wiimote, what happens: freeze/lag, where: in games, when: randomly
- The user tried to narrow the problem by testing other hardware AND told about it!
- It provides used homebrew and version.
- It provides current System files setup (IOS and cIOS version used by HBC and loaders).
- It provides a syscheck log without the need to ask for one.

Identifying the issue
This one is easy to fix because it's a known issue: cIOS rev20b has a wiimote sync bug, fixed in rev21 (and it's old).

Suggested help
- Update the cIOS (explain the steps, provide this guide's IOS fix step, don't let the user find wrong guide or go to youtube...)
- Additionally, did you notice the user has another problem? his HBC is using IOS61 instead of IOS58. Take action to suggest what he should do to fix this situation.

My flash drive is not recognized by any homebrew, please help

Why is it good?
- It tells which device is used.
- It tells it has been tested in different homebrew and they all have the same problem.

Identifying the issue
- It affects all homebrew, showing the issue is not a specific homebrew compatibility, or a wrong setting.
- That one is easy too, because it's a known issue: Flash drive ARE RARELY COMPATIBLE WITH THE WII AND vWII!

Suggested help
- Use a Hard disk Drive instead of a Flash device.

I downgraded the System menu and the console doesn't boot anymore

Unfortunately, this is a full brick. It could have happen even if you upgraded the system menu, not just downgrading it.

You installed a title (system menu wad file) without verifying that your console had a valid and working required IOS.
Almost each System menu version has a different IOS slot number requirement, and Nintendo had the habit to invalidate old IOS (stub) used by previous System menu version.
By installing the System menu before the needed IOS you made the console request an empty and dummy IOS at boot, which has no functionality and does nothing. It just hang there on a black screen.

How to fix?
You can't use Priiloader, even if you had it installed, because the newly installed System menu just replaced your Priiloader's program (they both share the same folder and filename, read priiloader section above).
Priiloader can only help you with semi-brick console, not a full-brick.

If your console is old enough to be able to install bootmii in boot2 (pre-2008), you still have it installed and you kept a bootmii NAND backup, then you can recover your console. Read modmii section for a guide. If you restore an old dump, you'll have to follow proper update steps once your console work again (modmii is recommended).

If you don't have bootmii@boot2, your only solution is to flash a NAND backup using a hardware flasher, which requires lot of soldering experience. Very few people are capable of doing it.

If you don't have a NAND backup but you have your console's unique keys then you still have the possibility to generate an empty new NAND binary file and flash it with hardware device too. You'll lose all your data and the console will be like new again. It's also possible to dump your current NAND to edit it on a computer with the console's key and reflash it, but it's the last chance to have this console working again.

If you didn't make a NAND dump or key backup, then your console is unrecoverable.

How to safely change System menu version
Before installing a Title system menu, you need to know which IOS slot it requests and be sure this IOS both:
- exists on your console ;
- is not stub.
If it doesn't meet the requirement, you need to first install that IOS.

The easiest and recommended solution is to always use Modmii to generate the needed system files and follow its auto-generated guide. Modmii always replaces ALL stub IOS with a patched version of IOS60, making sure all slots used by all existing System menu are never stub.

GBATemp's lurking knight

GBATemp's lurking knight

Similar threads

Popular threads in this forum