Toggle sidebar

Hacking USB Loader GX will not initialize USB

Creating and importing Wii Miis made from a computer

ZodiaKGalXy · 2026-05-03T20:25:07+00:00

Hello all, I'm ZodiaKGalXy. Lately I've been experimenting with getting Wii Miis made from a computer and transferring them to the Wii. I've done the homebrew method of SaveGame Manager GX, and the non-homebrew method of writing Mii Slots on my Wii Remote via bluetooth. In addition to that, I've found a good selection of tools and websites that helped me learn further on how Wii Miis work. This post-thread will discuss what I've learned to get Miis working on a Wii after creating or editing them from a computer. This is not considered a tutorial, but rather a review and discussion styled post (which may lead into a tutorial video in the future). Updated since May 23th, 2026. What was learned / experimented: The tools of which I used for Mii creation, editing, importing and exporting are as follows: Mii Creator (a web project for making Miis online) RSD-Editor (a tool that converts a variety of Mii File Formats) AJ's Mii Editor (another tool for editing Miis, but I simply did it for the Mii ID and System ID) SaveGame Manager GX (the homebrew method to import .MIIGX files) Mii Transfer (the non-homebrew method to import .MII files using a Wii Remote) The websites where I've gained knowledge about Wii Miis are as follows: WiiBrew (a specific page which gives a good description on a Mii data structure) MarioKartWii.com (a forum titled "In Depth Information of Mii Client ID / System ID") Mii Library (a Google Site website showcasing and describing a variety of Nintendo Miis, DS to Switch) Mii Renderer (a website to render Miis, other than Mii Creator) InfiniMii (a Mii posting site, and also contains guides and online tools) Instructables (a blog titled "How to Give Your Mii Different Colored Pants") As research was formed, a table report of acceptable Mii types was constructed. This used a Mii created straight out of Mii Creator, and then used the mentioned PC tools to edit that Mii. The results were the same regardless of either the homebrew and non-homebrew methods I used. The table image shows compatibility differences for a Wii Mii, which differ between the Mii ID and two switchable settings. The Mii ID side differs between Normal, Transferable, and Special statuses, with the ideal hex ranges for each Mii ID. The Settings side uses Mingle and the System ID to determine the comparison. For reference, Mingle allows Miis to travel to other Wii consoles using the internet, and the System ID (unless left blank) corresponds to a Wii Console's MAC Address. Results: From a previous result image of the experiment, it was determined that Transferable Miis were the most compatible, leaving Normal Miis unable to be imported at all. But as of recently obtained information, it's proven that both Normal and Transferable Miis are the most compatible. For normal Miis, Mingle does not affect how these Miis get imported, but the System ID does. Even though everything appears green in the first row, Normal Miis under a blank System ID actually converts them into a Transferable Mii. While I can't classify if the Blank SysID instances make actual Normal Miis, it was kept green since the point of the experiment was to find the most compatible Mii types. To get Normal Miis imported on your Wii, they must be in the 8 - 9 hex range and have their System ID filled to match your console's MAC Address. Transferable Miis did not change since the previous experiment. Transferable Miis were (from my expectations) the most obvious to get working, since they don't rely on the System ID or Mingle to be imported. They are essentially bypassing the validation check the Mii Channel does for Mii IDs and System IDs. People would have also understood that these Miis are essential for the Check Mii Out Channel, since they are Miis made from different Wii consoles. Special Miis also did not change since the previous experiment. The only instances of these Miis not working were if they had Mingle set on. That's because they are a more stricter version of Transferable Miis. They can't travel over the internet, make copies of themselves on the Wii Remote (instead it's "moved" to the remote), or even transfer across DS and 3DS systems. The most interesting study was trying to edit these Special Miis, and this fact is both true and false. While they generally can't be edited, only in the 00-00-00-00 to 0F-FF-FF-FF Mii ID range do these Special Miis become editable. Since these Miis can't be ported with Mingle on, forcing Special Miis to have Mingle on in the Mii Channel causes a system crash after saving. Rebooting the system after a force shutdown will later remove the Special Mii from the console. System/Console ID Analysis: The System or Console ID of a Mii, as mentioned previously, refers to a Wii Console's MAC Address. You can find the MAC Address of your Wii in the Internet Settings. However, you may find when looking on a Mii's Console ID that it doesn't show the entire MAC Address. That's because a Wii MAC Address can hold 12 hex values, and the Console ID can only hold 8 hex values. So how does the whole MAC Address get represented in a Mii? The first 6 hex values of the MAC Address get stored as 2 prefixed values. Furthermore, MarioKartWii.com's Vega did a forum of what prefixed values represent for each Nintendo Wii MAC Address. You simply type the prefixed values first, and then you fill the ID with the 6 remaining digits of the MAC address. If your Mii ID starts with 8 or 9, filling the Console ID to your MAC Address correctly will make it a normal type. This tactic is especially useful if you're converting Transferable Miis (from another console or the Check Mii Out Channel) to Normal Miis. In a hex editor, the Mii's Console ID is on address row 00-00-00-10, and it goes from columns C to F. In AJ's Mii Editor, this is in the settings tab of the application. Mii ID Analysis: Before I continue, I would love to share an honorable mention who helped me with the Mii ID analysis. They are not on GBATemp, but the shout out goes to HEYimHeroic, the creator of Mii Library and a so-called "Mii Expert" (which they are). The updated information was based on what I learned from Mii IDs, half from the research and the other half from HEYimHeroic. Wii Mii IDs are a combination of a validation check (the first hex value) and a timestamp (the rest of the Mii ID). The Mii ID Analysis section will cover the timestamp part first, and follows the validation check afterwards. In a hex editor, the Mii's Mii ID is on the same address row as the Console ID, but it goes from columns 8 to B. In AJ's Mii Editor, it is in the settings tab just like the Console ID. Mii ID Timestamp: Starting with the timestamp part, the Mii Channel's Mii ID algorithm increments 1 to the hex sequence X0-00-00-00 every 4 seconds, and uses January 1st 2006 00:00:00 UTC as the initial date. This timestamp hex is translatable in seeing the Mii's creation date, and the age of a Wii Mii. To understand how this is possible, you can follow this formula: D represents the result date and time after the calculations h represents the Mii ID hex converted into seconds (which is really hex converted to decimal) i represents the initial date and time that was mentioned above. This is also referred to as the epoch. This formula simply adds the number of seconds to the epoch, leading to the exact date and time of a Wii Mii's creation. If you wanted to find how old a Wii Mii is, I recommending using a online "date duration calculator", where you substitute the start and end dates with i and D. Here's an example... Let's say I created a Mii named Richard, and their Mii ID is this: 89-8F-55-8B. Well, the first hex digit is replaced with 0, and 09-8F-55-8B in hex converts to 160,388,491 in decimal, and thus becomes our h value. h multiplied by 4 is 641,553,964 seconds plus the epoch (i). Therefore the creation date of Richard is May 1, 2026, at 09:26:04 AM (or at least close to there). This also means Richard is approximately 20 years and 4 months old in the duration between the two dates. Now, of course, the Mii ID timestamp part can be any possible value and the Mii ID would still be valid. This part only verifies the Mii's creation date, unlike the validation check which helps identify a Wii Mii further. Mii ID Validation Check: The more important part of what makes an acceptable Mii ID is its first value (0X-XX-XX-XX). Based on the Mii Compatibility table above, this is each accepted Mii ID value ordered from hex 0 to F: 0, 1, 8, 9, C, D. Out of all values, these six have installed Miis without any issues. What these specific values represent are the Mii types, but does not give enough information on some of these questions... What is the Mii Channel validating for? Where did these Miis come from? Why does the Mii Channel specifically use 8? Why are only the mentioned six hex values able to work, and not any other? This makes the hexadecimal number system useless to explain the validation process in depth. Instead, the validation is further explained by converting hex into binary. The binary number system helps give more information on how a Mii gets validated on the Mii Channel, and helps answer the mentioned questions. This information was provided from HEYimHeroic, and the visual representation would look something like this: XXXX RED = Bit 1 (isNormal) YELLOW = Bit 2 (isDS) GREEN = Bit 3 (isDeveloperMii) BLUE = Bit 4 (is3DS) NOTE: 0000 - 1111 in binary is also 0 - F in hex. X represents either 0 or 1. The four validation checks tell if a Mii is normal (which is a Mii type check), and what Nintendo system it had originated from. Here's what can be understood from the binary bits: A retail Wii console will never accept Miis coming from a Wii Development Unit (like NDEV consoles), which means Bit 3 would never be turned on if importing Miis to a retail console. When creating the Mii ID, the listed hex values will not work: 2, 3, 6, 7, A, B, E or F. If Bit 1is turned on, but the other three bits are not, it's 100% a Mii from a retail Wii console, and could be either normal or transferable status. This reason is likely why the Mii Channel uses 8 for Miis. If Bit 1 wasn't turned on, this is a Special Wii Mii, and will be regardless if any of the other bits were turned on or off. Bit 2 tells us the Mii came from the Nintendo DS systems, whereas Bit 4 is for the Nintendo 3DS systems. Hex 4 turns Bit 2 on, but not Bit 1. Meaning its a DS Mii in Special status. Special DS Miis never existed for the system, so this means hex 4 is invalid. If Bit 1 was turned on alongside Bit 2, this makes hex C. This is a makes the Normal DS Mii count as a Transferable Wii Mii. When Bit 2 and 4 are both on, they would indicate that the Mii was made on a Wii U console. Because of this, Hex D is the only acceptable Mii ID value where a "Wii U" Mii can be imported. This does not mean Wii U Mii files or 3DS Mii files are backwards compatible for the Wii. To summarize the analysis, the Mii ID's first value can significantly impact how Wii Miis are imported. By following the specific hex values to correctly place in a Mii ID, you will now know how and why a Mii gets accepted into the Mii Channel. There was so much I've learned about Wii Miis after doing this research. I felt grateful to share information on how Miis can be done from a computer, and be successfully imported to the Wii. Have you learned something about Wii Miis through this thread? Let me know in the comments below. Thanks for reading! :yaywii:

Thread starter Syn73
Start date Aug 17, 2025
Views 758
Replies 1

Syn73

New Member

Newbie

Level 1

Aug 17, 2025

EDIT: solved, usb loader gx needed to be on cios 251, but now it boots back to hbc after loading the game (guitar hero wt)

I've tried several different USB's, fat32 and wbfs formats. Syscheck linked. No clue what to try, have been troubleshooting for what feels like forever now. WiiXplorer DOES read the usb! And I'm very sure that the current usb I'm using (sandisk 8gb Cruzer Edge) works with the wii.

Last edited by Syn73, Aug 17, 2025

Syn73

New Member

Newbie

Level 1

Aug 17, 2025

Also, a weird thing is that if I start ulgx with the usb unplugged, and then plug it in, it proceeds to everything else, then gets to "reinitializing devices" and then just says waiting for usb devices and doesn't recognise it at all.