Wii hacking explained

Discussion in 'Wii - Tutorials' started by Cyan, Apr 20, 2018.

Thread Status:
Not open for further replies.
  1. Cyan
    OP

    Cyan GBATemp's lurking knight

    Global Moderator
    22
    Oct 27, 2002
    France
    Engine room, learning


    [​IMG]
    Wii Hacking explained - Guide and FAQ for popular homebrew

    Information This guide is not complete yet and is still a work in progress.
    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 [​IMG].

    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.


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

    • 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

    • * 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
      Priiloader
      Modmii
      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



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


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


    • * requirement
      * install
      * setup
      * etc.
      * troubleshooting




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


    [​IMG]


    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
    - SD/SDHC
    - 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).


    [​IMG] 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.


    NAND


    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:
    [​IMG]
    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.


    IOS


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

    [​IMG]
    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, Jun 14, 2018 - Reason: update info boxes
    alexander1970, Orome, duwen and 4 others like this.
  2. Cyan
    OP

    Cyan GBATemp's lurking knight

    Global Moderator
    22
    Oct 27, 2002
    France
    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
    [​IMG] Wii
    [​IMG] 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:

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


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


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


    The Console security system


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

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

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


    Trucha bug and IOS236


    Trucha bug

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


    For now, this is all you should know:

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

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


    IOS236

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

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


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

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

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



    AHB Access & HAB_PROT


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

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

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


    History of AHB access


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

    There are two possibilities for homebrew to get AHB access.
    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 wiibrew.org.
    A lot of information and details are left out on purpose to make it simpler to understand for someone new to hacking and security systems.

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



    What is a signature? When is a signature checked?


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

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

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

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


    Why is faking a signature needed?

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

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


    How File's signature is working

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

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


    What is a file checksum?

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

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

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



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

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


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



    How to exploit a Checksum?


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



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


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

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


    Checksum on Wii


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

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

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


    Encryption on Wii

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

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


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

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


    Encryption and Keys


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

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

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


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

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


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



    Then, where is located the signature vulnerability?


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

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


    Graphical representation of the signature checking process:

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


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



    Explaining the Trucha/Signature bug


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

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

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

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

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

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


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

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


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

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

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

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


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



    Demonstration of trucha bug


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



    Step 1: replacing your consoleID

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

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


    Step 2: forging the signature

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

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

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

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

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


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

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


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

     
  3. Cyan
    OP

    Cyan GBATemp's lurking knight

    Global Moderator
    22
    Oct 27, 2002
    France
    Engine room, learning

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

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


    Not written yet

    Homebrew

    not written yet


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

    not written yet


    Hackmii Installer

    not written yet



    Bootmii

    not written yet


    DVDX

    not written yet


    The Homebrew Channel

    not written yet


    Priiloader

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


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

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


    Visual representation:

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

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


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



    Priiloader's features

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


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



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


    Priiloader an AHB access

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

    If you need to launch a program requiring AHB access, and don't want to auto-boot into The Homebrew Channel, you will need to 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.


    Visual representation to launch homebrew with AHB:

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


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


    cIOS

    not written yet


    Which cIOS do you need?


    not fully written * DRAFT *


    cIOS Install

    not fully written * DRAFT *



    DarkCORP/CIOSCORP

    Not written yet


    Syscheck

    not written yet


    Fixing your console using syscheck log

    not written yet


    PimpMyWii

    not written yet


    Modmii

    not written yet



    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

    not written yet


    Game loaders
    not written yet


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

    Postloader

    CFG Loader

    WiiFlow

    USBLoaderGX

    not written yet


    Game compatibility

    not written yet




    Chapter x - emuNAND

    EmuNAND presentation

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

    not written yet

    Creating Neek using Modmii

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

    Creating Neek using Neek installer

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




    FAQ and Troubleshooting

    Identifying the problem and getting proper help


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


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

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

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

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


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

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




    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.

     
Loading...
Thread Status:
Not open for further replies.