"The Early History of Wii Modding"
Here is an article by noobwarrior7 at GBAtemp.
The Early History of Wii Modding - GBAtemp.net
To celebrate the release of Waninkoko's cIOSx rev20, I thought I would post this. Please remember to thank Waninkoko as you download and try his newest cIOS.
This "article," if you will, is mainly for latecomers. It is meant to be a source of general, accurate, but most importantly, detailed information.
:: The Early History of Wii Modding::
Running any unlicensed code (called "homebrew") on a Nintendo Wii (in Wii mode, not Gamecube mode) really only became a possibility for the average Wii owner with the first release of the (now defunct/repeatedly thwarted) long-lived Twilight Hack, requiring the user to have only a copy of Zelda: Twilight Princess and a standard SD card with the required files. The exploit itself involved installing very little onto the Wii’s internal NAND flash memory; only a specially crafted save-file. Team Twiizers was responsible for the Twilight Hack itself, and although it served only to load other programs being created, they were also responsible for disseminating the knowledge required for many(/most) of the earliest homebrew programs.
The first such program to really gather a lot of general interest was a program used to “share” (read: pirate) private “dumps”, or copies, of Virtual Console and WiiWare titles, called Wad Installer (and then came Uninstaller, and then finally together as “Manager”). Wad Installer was created by a then-associate of Team Twiizers, Waninkoko. However, it was not endorsed by Twiizers, for it was created without their consent to use a Wii software bug (putting it lightly) they had shared with Waninkoko. This bug allowed content to exist and function via the Wii’s own software and hardware as if it had a proper signature. Using this bug, for example, Wad Installer could “fakesign” content upon installing onto the Wii’s internal NAND, and allow it to be run as if it was a program purchased for that system. This is what we still refer to today as, “the Trucha bug.” Also a common term, “wads” are simply native Wii Files for a specific app, such as a VC game, packed into a singular container.
Small problems began to crop up pretty quickly after that, much as Team Twiizers believed they might. Aside from the obvious rampant piracy drawing negative attention towards Wii homebrew, there were a lot of user-end “issues” that became apparent. With “wads” increasing in popularity, people grew a little bolder and began “injecting,” the practice of replacing the content of wads to get customized channels, or different VC games. Upon the release of the first true homebrew loader, The Homebrew Channel by Team Twiizers, it became apparent that even custom Visuals for channels (called “banners”) were achievable. Unfortunately, many users and even “quickware” creators, didn’t want to take the time to learn the full in’s-and-out’s. To compound this problem, those in-the-know were strangely secretive about what they did know. The result was various processes and crapwares that resulted in the semi-infamous “banner bricks.” The term brick generally means to make a device unusable by accident, and if you install a wad to a Wii with any number of problems with the banner files (just known generally as a “Bad banner”), the result was(/is) a failure to properly boot. The whole process of average users tinkering with wads has still not been as finessed as you would think at this point in time, and is only considered now “moderately safe” because of other factors. Read up on Wadder if this is something that holds interest for you. Note that the methods of brick prevention now have changed (read:improved) greatly, so make sure to stay timely.
Taking a moment to back up, it is definitely important to highlight possibly the most-used piece of Wii homebrew (which is still the definitive homebrew loader), The Homebrew Channel, or HBC. As an end-user item, it has always been a fully-featured and enjoyable app to use in order to stretch the potential of your Wii. Steps have been taken with every release to test and ensure the safety of the installer, which does install the channel directly onto your NAND internal flash. What often goes unnoticed is how much this enabled other developers to test and interact with Wii homebrew. Combined with the first region-free game loader, GeckoOS, and at times a USB-Gecko device, this led to many creations. Even non-developers could take more risks and use more “dangerous” apps that modified the system files of the Wii, as long as they were using a program written to return directly to the HBC. This meant, for example, that one could eventually remove the system menu itself (very “unsafe”) but return to the HBC rather than power off (which would result in a brick upon restarting) and load Wad Manager to install a different System Menu. This is still an unsafe process, but at the time, people believed there were cases where it was needed. Regardless, this illustrates how both planned and unplanned exploration has taken place only because of the HBC.
At this point, all code run on the Wii was only running through advanced custom libraries manhandling built-in Wii Software, and not really what we’d call “natively” (It remains that way for a while, and we’ll get to it later). This is to say, all code was running off of IOS (This is the part about IOS, if you were looking for it). I have heard IOS named as, “Internal Operating System” and “Input-Output System,” both by reputable aficionados, but whether it is even officially written as something other than “IOS” anywhere is unclear. It makes sense that it might have no official name since even title developers do not interact with it directly. They are led to believe that it exists merely as an IO Bridge, and now I’m getting more technical than I can handle…
…IOS are the often-Critical System files of the Wii, akin to but different from “firmware”. So forget firmware, starting now.
Many of us got a first sneak peak at IOS when a special “hacked” IOS version 5 (not an official Nintendo IOS), or IOS5, was released in Wad form, and had to be installed in order to use an early Wii Disc Copier app. It was of minimal popularity however, and people only really began to interact with IOS after Team Twiizers (once again) introduced PatchMii, a program (and a framework) that would install a customized IOS with a given set of “patches” to allow it a few more internal “privileges”. Essentially the same thing had been done to IOS5.
PatchMii confused many newcomers, not really offering any clarity about the features of having a patched IOS. At this same time, there was another creation that rode in off the hype that had built to a kind of plateau temporarily with PatchMii. Another associate of Team Twiizers, Crediar, had made a system-menu patching application, called, “Starfall.” Perhaps one of the furthest-branching creations, Starfall laid the groundwork and inspiration for the likes of StartPatch, PriiLoader, and SNEEK, which you can find loads of information on. Patching not the IOS, but the Menu app on NAND itself, Starfall could enable permanent Region-Free gaming from the system menu, instead of through a loader like GeckoOS. It also offered the first semi-reliable brick protection (in combination with the Twilight Hack). The region-free options actually made some older, popular software virtually outdated, such as AnyRegion Changer by the talented Tona, which now (temporarily) only toted changing the Wii Shop Region as it’s only true benefit (until it was fixed on Nintendo’s server-end).
Soon after, a wave of newcomers to the Wii scene arrived to take advantage of Team Twiizers newest revelation (yes, again). It was soon made known that PatchMii, combined with a special “hidden channel” installer released by Twiizers called “DVDX” (and later DISC/DISK) would allow a Wii System to not only play DVD Video in an appropriate video player app, but would also allow homebrew apps to reference/use files burnt to a DVD-R/+R (not RW). This was huge for those who wanted to use the Wii as a DVD player, or who wanted to play emulated games via “roms” burnt to disc instead of the SD card. However, a lot of noise rose up from those pirates no longer content to play their pirated VC and WiiWare. They had hopes that this would lead to a method for playing pirated Discs. Team Twiizers were harassed incessantly despite making several clear statements that they did not endorse piracy of Wii Software. They themselves actually made mention (sarcastically) that someone the likes of Waninkoko did not respect creative rights and would be the one to go beg to, although they maintained he was incapable of such. They were wrong.
Waninkoko proved to be up to the test, as he had been developing and testing for some time, a “custom IOS” or cIOS. The cIOS installer first appeared shortly after PatchMii and was essentially the same product. The original goal, however was to create the most stable and functional IOS (that was separate from all official IOS) that could still install “fakesigned” wads via the Trucha bug. The bug had been patched in newer IOS at first, but then with a certain update the fix was backported partially as several other key IOS were overwritten with new fixed versions, thus intentionally disabling Wad Manager. Wad Manager began to rely only on IOS249, which was the very high available slot Waninkoko chose to reference his custom IOS. Now keeping that in mind, the opportunity arose with the release of DVDX, to tweak his cIOS, ala PatchMii, with the intent to enable “backup” (unlicensed copy) loading. Waninkoko announced his intention and demonstrated a Proof of Concept internally to the scene, but before he could add whatever finishing touches he had desired, Backup-Loader, a special patcher (read:decrypter) program, and a wad of cIOS revision5 were leaked on the Wii-Hacking section of gbatemp.net. That is pretty much when it all turned into a hot mess. Insert pages of ridiculous drama, and then we’re back to the facts.
The leak of Backup Loader might have been the death of it and cIOS, but another developer interested in loading backups, WiiGator, borrowed some code from Nuke’s GeckoOS and created a more stable solution called Backup Launcher 0.1. This enticed Waninkoko to continue his work on cIOS. Waninkoko and WiiGator began to collaborate, and the release of Backup Launcher 0.3 Gamma, with a corresponding cIOS rev7, was a very functional backup solution with no hardware modification required at all. WiiGator barely stuck around long enough to soak up any recognition, though, but remained long enough to eventually create a custom cMIOS (which enable Gamecube backups), a loader for it as well, and then finally cBoot2, which is a special app for system recovery. Waninkoko has since taken over and tweaked cMIOS, but little has been done to alter compatibility. However, cIOS is still in development and has had many stable releases. If you are interested in backup disc loading, the evolution of what Waninkoko and WiiGator started is clearly seen in WiiPower’s iteration, NeoGamma.
At this point in the history of Wii-Modding, all parties in the scene essentially became the enemy of Nintendo. Backup-loading drew a lot of attention towards unlicensed software, and it became even easier as time progressed with creations like cIOScorp (aka: DarkCORP, the moderately unsafe practice of overwriting most Wii IOS’s with custom IOS’s to allow a system to natively recognize burnt discs; only REALLY unsafe if you plainly Remove any IOS), the USB-loading interfaces created by Kwiirk and polished by Hermes, and even SNEEK by Crediar which allows you to tweak and modify a “fake NAND” safely. It became clear that Nintendo would focus software updates on blocking the ability to enable unlicensed code to run in the first place. Every instance of the Trucha bug was eventually patched, several iterations of the Twilight Hack were put to rest, and the slots used for custom IOSs were filled with nonfunctional “stubs” that can’t even run the native system menu. Nintendo even went above and beyond to combat disc piracy at a hardware level with newer Wii drives. The Homebrew subscene has decidedly forked as much as possible from the piracy subscene, but usually their internal success has re-ignited the piracy scene every step of the way, and Nintendo has given them no benefit of the doubt for it. These and other developments have also caused Nintendo to use their knowledge of how certain modifications are being achieved, and checking systems to verify warranty validity before repairing damaged/defective systems.
I hope that you will take the practice in reading that you have had with this article, and not stop, but continue to read and gain a better understanding of the modifications you perform to your product.