First of all, let’s count up what we’ve “lost.” (In terms of fully updated Wiis).

• Twilight Hack is gone. (as of 3.4’s release)
• Signing bug is gone.
• FS commands are gone (or protected?)
• ES_Identify is gone/fixed.

The Twilight Hack can easily be replaced by other savegame exploits, of course, so that’s still on the table to some extent.

But without fakesigning, ES_Identify, and Filesystem commands, all code that deals with installing or modifying content (System Menu hacks, patched/custom IOS) is pretty much dead. This really feels like a lot of negative work. Patchmii is nearly useless. Everything I’ve written is pretty damn useless, too.

Pirates, however, don’t seem to have a problem with searching for workaround after workaround to get their things working. They’ve still managed to bypass most of the issues here (besides needing twilight hack) to get their warezloader and pirated VC/Wiiware to work.

The only issue that we care about is homebrew. It’s being killed by the updates, and we don’t really feel it should. So far, however, all homebrew relies on Nintendo’s code in the form of “IOS,” which handles loads of hardware interactions–Wifi, Bluetooth, Disc drive, SD, USB–everything unique to the Wii. If we want to use these, we pretty much have to hook into Nintendo’s code somehow. We’ve been loading code using IOS through channels and savegame hacks, but all of these require Nintendo to allow us to use their code, and can be cut off at both the System Menu and IOS.

So, what do we really want to do? Rely on as little of Nintendo’s code as possible. This is what BootMii is all about. We want to hook into the Wii processes as early as possible, so we don’t have to touch any code we don’t have to. BootMii is going to sit just before boot2, so it will be the first piece of boot code that we can actually modify. If we hook in before boot2, we’d either have to write our own code to interact with the Wii hardware, or pull some random IOS to use. Obviously, the former is the better solution. And what’s the best free way to deal with lots of hardware? Why, Linux of course!

So, the next step in Wii homebrew is going to be a low-level, all-inclusive linux system. This is going to require quite a bit of work, but, fortunately, it will probably end up less hacky and more stable in the long run than anything else. It may result in a bit of overhead for applications, but application efficiency will probably be more of a finishing detail.

Let’s talk about some of the reprecussions of this.

Wii piracy practically *requires* running Nintendo’s code (for compatibility), so our BootMii/linux efforts would practically nip this issue at the bud.
Homebrew, on the other hand, is mostly contingent on libogc and IOS code at this point. Fortunately, most legitimate homebrew (i.e. non-pirate, non-”utilitiy” apps) only really uses a few of the many IOS functions: SD reads, Wifi, and Bluetooth (Wiimote). All other things (Graphics, sound, etc) go through PPC, which are already supported by gc-linux (to some extent). What’s more, we hold the source code for libogc, so developing a libogc “wrapper” for the wii-linux functions would be fairly trivial, and would give some level of compatibility with existing homebrew applications.

With this system, Wii homebrew would be “stable,” in terms that it would all run off of a single library (or set of libraries) controlled by homebrews. IOS (in)compatibilities would cease to be an issue. What’s more, as long as Wii Linux would run, we could ensure that homebrew would run. There would only be the single task of getting Wii Linux installed/running–which is much much easier for maintenance.

So, this is the *general* direction Wii homebrew is heading in. Consider this your warning. Things are going to change–for better or for worse. For most of the hacker-developers, this should seem like a much better solution. For Homebrewers, prehaps slightly inconveniencing, but better in the long run. For pirates, hell.

You’ve been warned

The Hackmii post explains what the potentials of the Recovery Dongle are, but they don’t really explain how the device does what it does–which may be the cause of some of the random speculation.

Here’s the deal:

The Wii System Menu will check for a “Nintendo Waikiki Adapter” when it boots. If it finds one, it will load up a “Recovery” mode, which really just boots diagnostic/autoboot (Disc ID 0) discs and displays the current System Menu version.

Marcan’s device (at this point) merely identifies itself in the same way as the Waikiki Adapter, with no other functionality as far as I know. Duplicating other Waikiki functionality may even be superfluous, as I’ve gathered that it’s just an EXI2USB device like the USBGecko.

So, in short: System Menu boots, says “Is there a Waikiki plugged in?” Then marcan’s device replies, “I’m a Waikiki!” Then the System Menu goes into “Recovery” mode.

If you want to see this functionality for yourself, you can try crediar’s Starfall, which will let you access the Recovery Menu by holding a button on your Gamecube controller.

What exactly does the Recovery Menu do? What is it good for?

That’s a good question. The Recovery Menu will load before the system menu performs a number of checks/actions, so you may be able to boot to it when your System Menu will not otherwise load. However, as far as functionality, as I mentioned before it just boots autoboot discs, which are discs that have the Disc ID set to ‘0′. Now, there’s only two kinds of discs that have a Disc ID of 0: The Pink Fish Disc (and probably other factory discs), and burnt discs with the Disc ID artificially set to 0. In terms of recovery, this means that the Recovery Menu is only useful if you have Nintendo diagnostic discs or a drivechip. Furthermore, if you’re on System Menu 3.3 (With the new IOS30) or newer, you still won’t be able to boot fakesigned discs, leaving you high and dry on recovery options if you don’t have the Twilight Hack (or some other savegame exploit) installed.

As you can see, It doesn’t have any functionality beyond that of the normal System Menu, so it’s only really useful for when you are stuck with a System Menu-related brick, and even then it’s not guaranteed to help, and requires knowledge of the brick.

Here’s an example runthrough of a use of the recovery dongle.

Your unmodified 3.3 Wii has a full Banner Brick or Region Brick. You would need:

1. Recovery Dongle/Waikiki Adapter
2. The Twilight Hack ALREADY installed,
3. An image of Twilight Pricess, modified to have a boot code of 0, and burned to a disc.
4. A drivechip installed to allow said disc to boot.
5. Some homebrew to run through the Twilight Hack that would fix your brick somehow

Is it useful? Sure, but not to most. And it’s only useful in very specific cases. As for trying to keep it secret to try to capitalize on it, that’s not likely. Few people will ever get into a situation where the Recovery Dongle is the fix they need. Even fewer will actually look into purchasing such a device. It would only be useful if you were in the business of fixing bricked/broken Wiis.

“Much ado about nothing.”

As most people finding this blog probably know, I write code for the Wii from time to time. I wrote a few utilities for the Wii, mostly dealing with the Wii’s specific way of doing things, rather than anything interesting on a low level –i.e. nothing dealing with security.

There’s a few things that you may be interested to know about me:

• I am a beginning undergraduate majoring in Comp Sci
• I am nothing close to a “professional” coder in any sense.
• I never touched C until I started working on the Wii (Although I’ve had quite a bit of exposure to programming in general)

Please consider this in your judgments of myself and my applications. For the most part, this just means that I’m a slow coder. I’m actually rather confident in my code’s merit as a part of a finished product. That said, I haven’t really written anything all that incredible, either, but I’m not sure that’s necessary for making a useful application.

These past few months I’ve been incredibly lucky to be able to speak and work with all the members of the Wiibrew/#wiidev community. The Wii is a very interesting system, and understanding its inner workings is a great motivator in itself to me. Between the Homebrew enablement of the Wii and the aforementioned community, I’ve been able to learn great amounts about the Wii’s software system itself and manipulate it in various ways.

Now, concerning this blog:

While I’m not a great coder or a “hacker,” I do have the ability to understand these systems to a fair extent. Through this blog, I plan to inform the community on various portions of the Wii’s hardware/software systems to the best of my ability. Of course, I will probably also use this blog for more personal purposes–e.g. updates to my applications–however, the purpose of informing the community should remain the primary one for this blog.

Nom nom nom.