Not open for further replies.
Tutorial  Updated

Wii hacking explained


Wii Hacking explained - Guide and FAQ for popular homebrew

Information This guide is not complete yet and is still a work in progress and I'll probably won't complete it. I lost interest and miss time.
If you spot any error in completed chapters (ch.1 & ch.2 only, do not report chapter3+), please send me a private message, as this thread will be locked to contains only guides. No comment will be accepted to keep focus on guides only and prevent help to be hidden in hundreds of replies.

Chapter 3 and more are not written yet. Don't take these chapters seriously. Current contents are only random ideas for my own future writing plan.

Help needed If you have suggestions or want to help me write a part in the guide, please contact me. We can talk about what's needed, what can be done, and how to write it.
It's possible this guide will be moved to Wikitemp to allow more users to write parts of it without any action from me.

General help request guideline
If you have console issues, hacking problem or general questions, DO NOT CONTACT ME! I'm not your private help desk. Time spent answering you privately could be used to write this guide for everyone.

If you have hacking questions and it's not covered in the guide yet, create a new thread to get help from other users, or even better search in recent threads to see if someone already answered your question before creating yet another one with the same question for the 200th times! Posting your question publicly will both get you faster answers due to more people helping you at the same time with different ideas, and benefit other users with the same issue searching on the net for that answers. I'm not the only capable and available person to help you, and don't be selfish!
Read the Troubleshooting part (end of the guide) to get an idea of proper report methods.

And last: Do not repost your question in multiple threads, scattered help is unproductive and dangerous. Providing suggestions without knowing which other action you did can be worse!

Why a new guide?

This guide does not intend to be another hacking guide for newbies where you blindly follow steps to softmod your console because there are already more or less good guides to do that (Modmii, CompleteSoftmodGuide or vWii complete hacking guide, for example), but instead provides help and fixes for commonly used homebrew available after completing the softmod guides (hardware compatibility, loaders, neek, etc.). I also don't intend to replace wiibrew here but only provide a quick overview for users who want to understand how their console is working. For advanced and technical explanations feel free to check wiibrew or wiiubrew wiki.

Over the years, I've written on GBAtemp many guides and provided a lot of answers, but they are all lost and hidden in hundreds of threads. I want to finally regroup all my guides in one place.

This guide's objectives are to explain how the Wii is working and hope it will help many users finally understand why and what they are doing when they hack their console, how to report issues properly and in an understandable way to get better and quicker help from other users or even detect and fix their own problems themselves.
This guide written primarily for the Wii also applies for the virtual Wii mode of the WiiU (vWii). If there's no indication, it should be identical. If the Wii and vWii are behaving differently, it will be specifically stated using this WiiU icon

I think this guide is highly due and needed based on the amount of created threads with recurrent questions posted every weeks. It clearly demonstrate that many people don't understand what they are using, why they are doing something when following a softmod guide or what's possible to do once they completed the guide. They are often lost after following a step by step guide which hold their hand and suddenly left them all by themselves without any more direction. Guides rarely tell users what they can or should do next, this is what I'll try to cover here.

I want this guide to explain three things:
- How it works ;
- What to do and why ;
- How to fix common encountered problems.

I hope covering all these steps will help everyone, end users will be able to find the information they need and helpers can point everyone to a single updated place instead of providing wrong or outdated information, or re-writing the same answer for the 100th times.

Table of content
Table of content serves as writing plan. Links will be added later to allow anyone to easily link to a specific part of the guide to help other users.

Nothing is definitive and existing or future sections could move around at any time.
(If you like one of my post for a specific section, remember I might move it to another post in the future and you liked a post for nothing!)
Red text = not written yet.

Chapter 1 - The consoleChapter 2 - Hacking & securityChapter 3 - Homebrew presentation & setupChapter 4 - USB Loaders (in general) ?Chapter x - one per Loaders ?Chapter x - EmuNAND & Neek

  1. * Hardware
    * Boot sequence
    * Internal memory (NAND structure)
    * File system, folders and TitleID
    * IOS and slots
    * updating the console

  2. overview
    * existing blind step by step hacking guides
    * console brick
    * Trucha bug & IOS236
    * AHB_PROT & AHB Access
    Chapter 2.2 - More on Security, Signature check and Trucha bug detailed
    * File signature
    * fake signature
    * checksum (multiple sections)
    * cryptology and encryptions keys
    * Signature bug
    * Trucha bug demonstration

  3. * what are homebrew?
    * homebrew channel
    * hardware compatibility, best usage (SD, HDD, Flash drives, SSD, HID USB, LAN, etc.)
    * different homebrew (apps, games, media player, loaders)
    * etc.

    Chapter 3.2 - Hacking the console and Installing homebrew ?
    Hackmii installer
    Chapter 3.3 - cIOS and patched IOS
    * what is it?
    * Existing cIOS
    * Do you need it?
    * how to install or update
    * How to choose and where to install
    * How to uninstall

  4. * requirement (hardware, IOS, etc.)
    * install
    * setup
    * etc.
    * troubleshooting

  5. * requirement (hardware, IOS, etc.)
    * install
    * setup
    * etc.
    * troubleshooting

  6. * requirement
    * install
    * setup
    * etc.
    * troubleshooting

Troubleshooting and FAQ

  1. * How to properly report an error and ask for help !
    * Deleted system menu brick

The Wii and its Operating System

The first part of this guide will cover only the official and non-hacked functionalities. Everything related to hacking and homebrew will start in the next chapter.

Before talking about the softwares and how to use homebrew on a console, it's important to understand how it works inside the box.


The Wii console contains 1 GPU (Graphic Processor Unit) and 2 different 32 bits CPU (Central Processor Unit):

- The GPU is an ATI chipset, it's an updated version of the Gamecube GPU (It's not important to know more about it for now).
- The main processor is a IBM PowerPC (PPC) used for applications and games.
- The second processor is a NEC ARM9 used for security and hardware access restriction.

The GPU and the two CPUs are linked together by the RAM chipset, which itself is separated in two bank regions: 24MB fast SRAM memory called MEM1; 64MB DDR3 memory called MEM2.

The ARM processor is responsible for accessing these interfaces:
- Disc interface (di) ;
- Gamecube controller ports ;
- EXI (Gamecube memory card ports, debugger).

The ARM chipset is connected to other restricted components along the Advanced High-performance Bus (AHB), and grants right access on a case by case basis for application's requirements:
- 512MB NAND Type Internal Flash Memory
- 2x USB 2.0
- Wifi b/g, used for network access
- Bluetooth, used for controllers
- Cryptology (Hardware AES/SHA engine)

The programs managing the security and hardware access running on the ARM chipsets are called "IOS" (Input/Output System).

Boot process

The ARM is the first processor to run code at console's boot.

The boot sequence can be visually represented like this:

Power > Boot0 > Boot1 > Boot2 > System menu

The first code to be executed when powering up the console is part of the processor's BootROM, called Boot0. Its content is written at manufacturing time and can't be changed anymore.
Boot0 is a program which loads, decrypts, verifies and runs Boot1 located on the first block of NAND. Boot1 is verified with a hash located in OTP (see below). If Boot1 is wrong, the console stops here and will refuse to boot.
Boot1 Initializes the RAM, then it loads, decrypts, verifies and runs the Boot2 program (TitleID 1-1) located in the folder "/title/00000001/00000001/" (More on that later). The verification is done from a signed hash located in boot2 itself.
Boot2 is responsible for loading and launching the system menu title (into the PowerPC chipset) and its corresponding IOS (into the ARM chipset). Boot2 is also responsible for launching MIOS instead of IOS if the CPU is detected running at gamecube speed.
System Menu is the main Wii user interface. It is now running and the user has the hand (literally).

On WiiU, the vWii doesn't follow the same boot procedure, there's no boot0 nor boot1 steps.

What is OTP?
OTP is a One Time Programmable chipset memory. It's a chipset which is used to store fixed values at manufacturing time like Unique console ID and cryptographic keys.
The OTP on the Wii contains:
- The boot1 hash: used by Boot0 to verify if boot1 has been modified ;
- The common key: used to decrypt most titles & data ;
- Your unique Console ID ;
- Your unique NAND key: To encrypt/decrypt your NAND's content.


All the console's files are stored on a 512MB NAND Flash type chipset memory.
The NAND's content is encrypted using a per-console unique key stored in OTP.

The 512MB NAND is a single bank of memory, shared with both Nintendo's file (system) and user's file (savegames, bought games, etc.)
There's no reserved part for the system and reserved part for the user.

All the devices (NAND, SD card, gamecube memory card) available size are counted by Nintendo in a custom "block" unit instead of Bytes (8 blocks = 1MB). You can verify how many left blocks you have in the Data management section of the Wii System Menu, and the Nintendo online shop displays how big each game is in blocks to be able to download and install it.

The Console's Operating System and Firmware

Unlike other consoles (PS3, PS4, Xbox, WiiU, Switch, etc.), the Wii does not have a single operating system running all the time in the background, such as a Firmware, a supervisor or a home menu interface used for security.

The ARM CPU is what you can consider the most similar to a firmware as it's responsible for the security and hardware's right access, but acts more like a hardware's driver than a firmware. The ARM does not provide real-time features like screenshot, trophies/success, or console settings while you are playing a game.

The PowerPC CPU is dedicated entirely to the currently running program, and can't run two different programs (or Title) at the same time: It runs either a game (game, application, channel, etc.) OR the system menu interface, which actually is also a program and not a firmware. The Wii System Menu is not in memory anymore when a game is launched, the game replaces the menu completely to use all the available RAM and CPU power for itself. When you are in an application, you can't access another installed application (like Mii maker, eshop, internet browser, etc.) without exiting the one you are running.

So, if it's not running a firmware, you might wonder why the Wii provides a version number, like 3.1E or 4.3U?
This version number is a "virtual version" of the software used by Nintendo for its Graphical User Interface: The System menu.
The system menu is simply a program acting as game loader and content manager (savegame, channels).
This program is launched by Boot2 when you power the console up, and the same way the system menu replaces itself when it launches a game, a game also replaces itself with the system menu program when you choose to exit the running game (from the game's home menu interface).
The system menu version is not the firmware version of the console, for example new games work fine even if the system menu is outdated.

Why did I use the word "virtual version"?
Nintendo uses a version number for the System Menu software based on its features (for example 4.x is a major revision which added the SD menu over v3.x).
This versionning system is only subjective, and doesn't reflect the real program's version (build revision).

In "v4.3U", The letter represents the region of the console. U for USA, E for Europe/Australia, J for Japan, K for Korea.

TitleID and Title Version

Each application on the Wii (game or IOS) is called a "Title" and contains different information, here are 2 of which are important to know:

- Title Version: The internal build revision of the program. The Title Version is used by programs to determine if a new version of that title is available and update it when requested.
There is not much to say about this, but it's important to understand how the console is updating its files when you insert a game disc, or check if there's a new version online.
Every Wii game disc contain a partition with required and updated system files (IOS) which are checked by the system menu at game launch. If the system menu finds that the disc's update partition contains a Title with a higher version than the one you currently have on your console, it will prompt you to update your Wii before launching the game. It's not asking you to "update your firmware" (there's no firmware), it only detected that you had at least one file with outdated Title Version and will replace it with the newer version from the update partition.
This is interesting to understand that for later because Nintendo and homebrew will (ab)use this system.

- TitleID: The TitleID is a unique code per game or application, and is used to identify, access or launch it. The Title Identification code is also used by the folder's name in Hexadecimal (folder on the internal file system) where the program is located.
The TitleID is a 64bit number which represent a title (ex. 0001000146413950 -> European NES Virtual console Channel Zelda II: The Adventure of Link).
The TitleID can separated in two groups of 32 bits : 0001000146413950

The first half (TitleID High) is used to differentiate the Title type (system, game disc, channel, DLC, etc.).

These titleID High are used by the Wii:
00000001 System files (IOS, system menu, MIOS, BC)
00010000 Wii game disc
00010001 Game Channels (WiiWare, Virtual consoles)
00010002 System channels (Mii, Photo, Vote, Weather, etc.)
00010004 Games using both disc+channels (Mario kart, WiiFit, etc.)
00010005 DLC
00010008 Hidden Channels (EULA, region select)

The second group (TitleID Low) contains information on the Title itself: The console type, the internal game code and the region. It's usually the only part of the TitleID that users and loaders are using.
To be easier to read, the TitleID Low is usually represented using its ASCII converted characters, Example : Zelda 2 NES VC -> 0001000146413950 -> 0x46=F, 0x41=A, 0x39=9, 0x50=P -> 00010001-FA9P -> or more simply just FA9P.

The TitleID Low is decomposed in three groups, like this:

A = ConsoleID (G = gamecube, R or S = Wii disc, H = Channel, F = NES, etc.)
BB = Actual game code, chosen by Nintendo. LM = Luigi's Mansion, SB=Super Smash Bros., MN = New Super Mario Wii
C = Region (A = system, E = USA, P = PAL/EUR, J = JPN, K = Korean, X = Region free, etc.)

Informal TitleID6:
Additionally, on game discs only (Wii and gamecube), there is an additional 2 bytes value following the titleID often used by the game loaders: The publisher code.
With this additional data, it forms a TitleID using 6 digits (ex. GLME01 = Gamecube Luigi's Mansion USA, published by Nintendo)
This is the TitleID used in most game loaders to manage games, covers, memory card or cheat files.

The console's file system

The console uses a proprietary file system format and access is granted by the IOS.
The file system is based on files and folders, but programs rarely access them directly. Instead they rely on the IOS to access, read and write files based on the TitleID.

Each program uses the TitleID to locate the folders on the console and get the appropriate access rights (for example to store the savegame, or call another program to launch).
All installed Titles (games, IOS or apps) in the internal File System of the Wii are located in the /title/ folder, and using part of the TitleID as sub-folders: /title/< TitleID High >/< TitleID Low >/< the program's files are located here >

Some examples:
The Wii System Menu Title:
TitleID: 1-2 (or 00000001-0000002), stored in the folder /title/00000001/00000002/
TitleVersion: 481 (for v4.2U), 513 (for v4.3U)

The IOS58:
TitleID: 1-3A (or 00000001-0000003A), stored in /title/00000001/0000003A/
TitleVersion: v6176 (latest Wii IOS58 version), v6432 (latest vWii IOS58 version)
Note that 58 is 0x3A in hexadecimal.

New Super Mario bros. Wii game disc:
TitleID: SNMP (or 00010000-534E4D50), accessed folder is /title/00010000/534E4D50/
TitleVersion: Disc games don't use a TitleVersion as they are not installed titles which can be updated by the console's online service. The game disc still has a version which is usually version 0.
The TitleID path is used by Game discs to store their savegames on the console's memory in a "save" sub-folder /title/00010000/534E4D50/save/

The Mii Channel:
TitleID: 00010002-HACA, stored in /title/00010002/48414341/
TitleVersion: v6

Other folders used by the console

The console has other folders (other than /title/) but they will not be of any use to you right now.
They will be explained later if, or when needed.


The IOS is the program running on the ARM processor.
It's managing the security and works as a bridge or driver to allow the PPC programs to communicate with the hardware elements (Wiimote, SD, USB, NAND memory, etc.)

The particularity of the Wii is that the console is not based on a single firmware that Nintendo updates regularly, but instead uses a system with multiple different IOS revision.
To keep compatibility with old games, Nintendo decided to create a completely new IOS program revision (or Branch, like said on Wiibrew) whenever they released a new SDK to developers, ensuring that games developed with older SDK kept the same functionality and compatibility by continuing to use the old IOS they were designed to work with.
When Nintendo released a new SDK version to developers, they also released new IOS (batch) to use with matching SDK features.

If you've read the section about the processor, you know that the consoles runs two CPU at the same time: The PPC (Power PC) and the ARM processors.
In order to function correctly, every launched application on the PPC CPU have the information of which IOS they have to use. That information is stored in a separate files named "tmd" (Title Meta Data), which contains more important data that we will discover later.
One and ONLY ONE IOS is loaded in memory at a given time, and is usually the same for all the program's life. If for example you play Zelda Twilight princess, it will request IOS 9, and the game will ONLY use this one. All other installed IOS will not be loaded in memory, will not be accessed or used and have no effect on the currently running game or application. IOS are not conflicting with each others, that's how the console is designed to ensure the best compatibility with old games!

Along the console's life, Nintendo released many IOS revisions:

IOS9 (launch IOS, used by system menu 1.0 and games)
IOS20 (used by System menu 2.2)
IOS30 (used by System menu 3.x)
IOS36 (ES access, signing bug)
IOS37 (Fixes signing bug)
IOS58 (Adds USB2.0 support)
IOS59 (Adds encrypted WFS HDD partition support)
IOS60 (Adds SDHC support, used by System menu v4.0x)
up to
IOS80 (used by system menu 4.3x)

Every time a new SDK was released, new IOS batches were also released to be used by the new/future games and applications to be developed and requiring the new added features.
By convention, the multiple of 10th were used only by the System menu. Remember, System menu is a software like any other program or games, and as such it also requests a specific IOS to communicate with the console's hardware (Wiimote, SD, channels and savegames located on internal memory, etc.). For example, when Nintendo released Wiimote+, it needed a new System menu but also new IOS compatible with the new hardware.
On mostly every new System menu version, Nintendo also released a new corresponding IOS.

IOS30 -> System menu 3.0 to 3.3
IOS50 -> System menu 3.4
IOS60 -> System menu 4.0 (this IOS adds SDHC support, the System menu adds SD menu feature)
IOS70 -> System menu 4.2
IOS80 -> System menu 4.3

If you try to launch an application (Program, Title) which requests an IOS that you don't have, the console will refuse to boot it.
That's why it's dangerous to manually install a new System Menu without being sure you first installed the matching IOS. If the system menu can't be launched, you lose access to your console and can't do anything else, your console is dead.

You can find more information about IOS on wiibrew.

More about IOS Slots

Nintendo uses a system of "slot" to install the IOS application into.
A slot is nothing more than a folder with a 32 bits hexadecimal number as name, located in the "system folder" (/title/00000001/).

Few examples:
/title/00000001/00000009/ <-- IOS Slot 9
/title/00000001/0000000A/ <-- IOS Slot 10
/title/00000001/0000003A/ <-- IOS Slot 58

Nintendo has the possibility to install IOS in new folders up to "slot" 255 (000000FF).

The IOS's Title (the application loaded into the ARM CPU) is installed into the slot's folder.
When a software requests IOS58, it actually requests the IOS Title (or application) located INSIDE the folder number 58 (0x3A in hexadecimal).


The program loaded in the ARM CPU is the .app file, not the slot.
When a program requests an IOS, it doesn't request a slot number but the program which is located in that slot.

If a PPC program requests IOS58, it loads what's INSIDE the slot 58.
if a PPC program requests IOS249, it loads what's INSIDE the slot 249, and it can be anything you have into that slot! What's really important is not the slot number but the actual program type and version located inside the slot which is loaded into the ARM CPU.

IOS version and TitleVersion

The IOS is, like every other installed program on the console, referred to as a "Title" and using the "TitleVersion" system. Nintendo uses this TitleVersion number to update its system files (to fix bugs, for piracy prevention, etc.)
For example, by updating IOS36 it didn't become IOS37 but only an updated version of IOS36 (with the signing bug fixed). IOS36 has been updated 6 times, from IOS36 v1042 up to IOS36 v3608, but it was only done to fix bugs and never to add new features or Nintendo would risk breaking old game's compatibility.
IOS37 does not correspond to an update of IOS36, but to a complete new version of the IOS with new added features.
The IOSes were not always released in increasing slot order, for example IOS59 was released after IOS60, so a higher IOS slot doesn't always mean it contains new features, nor is a better IOS or newer than another IOS located in lower slots.

Some new IOS could even break compatibilities with old games (IOS58 adds USB2.0 support, but breaks games using USB1.1) and is why Nintendo uses the "frozen in time" program< - >slot requesting system. A game developed/designed to use IOS34 will always request the ARM processor to use IOS34 even if you have IOS35 available on your console.

Performing an update

When inserting a game disc or performing an online update, the System Menu checks and compare all TitleVersion on your console against the TitleVersion provided by Nintendo. If it detects at least one outdated Title (IOS or System Channel with a lower TitleVersion), it prompts the user to perform a console update.
If you ever see an update prompt, it doesn't mean there's a new firmware update but only one of your installed (or missing) Title has been detected having a lower TitleVersion than a compared ones. Performing the update replaces only the outdated, or missing, Titles.

On a game disc, the IOS and system channels are located on a distinct update partition.

Stub IOS

Instead of completely deleting the useless IOS (Old IOS used by previous System Menu version), Nintendo decided to replace them by releasing a dummy IOS Title (which does nothing) with a very high TitleVersion. This new non-functional IOS is usually called "Stub" (or "Mothballed" on Wiibrew). Doing this was used to free space used in the limited internal NAND memory of the console, and at the same time preventing re-installation of old IOS when inserting an old game disc if the IOS was simply deleted (missing IOS would be reinstalled if found on a disc's update partition).

Now, all previous IOS used by System menu (IOS10, 20, 30, ..., 70) are stubbed, only IOS80 is active for the System Menu application v4.3. If you ever try to install a different System menu, you will break your console if you don't have a fully working (non stub) IOS installed in the System Menu's requested IOS slot. (see cIOS and Modmii section below for more information to manually install a different system menu version)

To counter piracy and hacking, Nintendo also decided to install stub IOS in commonly used slots (like IOS249, IOS250, IOS254) in hope to prevent users from installing IOS in the same slot. Nintendo replaced the custom/patched IOS by releasing stub version with a higher TitleVersion than the one used by cIOS at that time.
Now the homebrew IOS installers let you specify the TitleVersion to use. You can easily set it to something higher than the TitleVersion used by Nintendo (v65280), for example by using the maximum possible value for a TitleVersion (v65535). (See the cIOS section in following chapters for more information about IOS installers)

Last edited by Cyan, , Reason: update info boxes


GBATemp's lurking knight
Former Staff
Oct 27, 2002
Engine room, learning

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

WiiU's virtual Wii

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:

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.

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


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 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.
  1. 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.
  2. 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
  1. by using a custom/Patched IOS (like cIOS236, or cIOS202), generally used by WAD managers, file explorers (ftpii, wiixplorer, etc.)
  2. 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.)
  3. 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
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) ;
- 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.

Last edited by Cyan,


GBATemp's lurking knight
Former Staff
Oct 27, 2002
Engine room, learning

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

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

do we explain what homebrew is here?


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)


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)


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 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 ( in order to be launched by Boot2 in place of the System menu. The installer first renames the real System menu's application (to 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 (, 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


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

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.

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)


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?


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
-> specific needs (port1, dual HDD, etc.)

see cIOS install section and install the needed IOS.


What it is ?
Is it good or bad?


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 ?

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
It works with nintendont, why can't it work with wii games?

WiiU Gamepad support

Old loaders
(Mighty channel, DM, DML, Devolution)


CFG Loader



Installing Game



forwarders, wii, vwii, wiiu,

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 :

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

Creating Neek using Modmii

Temporary guide :

Creating Neek using Neek installer

Temporary guide :

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.

Last edited by Cyan,
Not open for further replies.

Popular threads in this forum

General chit-chat
Help Users
    SylverReZ @ SylverReZ: