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)




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)

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




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

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




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





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.





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.



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.



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.



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.





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.




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

Click to expand...

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.



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




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.





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





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)





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.

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























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






























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.







(Mighty channel, DM, DML, Devolution)














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



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


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







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)

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





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.