HackMii

A lot of stuff has happened lately, and I haven’t written in a while.   VC piracy has (as expected) flourished, and we’re still waiting to see what form Nintendo’s reaction will take — at least, I don’t really feel like releasing any code until I see what happens.

So, I’ve stepped back and am working on another problem — well, I was sort of forced to.

Bricks as seen in the “scene” come in two forms — “full-brick” and “semi-brick”.  Both are the result of installing updated System Menus from discs that came from other regions.  (Tsk, tsk.)

A “full-brick” Wii displays an Opera error message instead of the “warning” screen when the Wii boots — it does not even check the disc drive for a disc before displaying this, meaning it is impossible to fix this using software.

A “semi-brick” Wii is similar, but it allows you to boot the system to the main menu, and play games, etc.  However, you can’t get into the Settings menu (to enable WiFi, update the software, etc), because when you do, you are presented with a similar screen to above (but I can’t find any pics online) — however, instead of ScreenSave.html, it’s Settings.html.

[Thanks to H. for the below picture:]

Let’s take a look at why this happens.  What’s this ScreenSave.html?

If you ever have the fun opportunity to select “Format System Memory” when the Wii boots up, you’ll be presented with this screen — *before* the “warning” screen:

After this screen, you are then given a few screens that ask you to select a region, a console name, and some other settings — one of which is this screen:

I don’t have a picture handy, but before you are shown this screen, you get one with a message that says “Your Wii console has a screen burn-in reduction feature. To use it, activate it in Wii Settings.”

 After you finish this series of configuration steps, it will finally show you the “warning” screen.  This is notable because this all happens before the warning screen loads.

These html files are all stored inside an archive inside the System Menu content storage.  Here’s the stupid part:

Each region has its own version of the System Menu (1-2).  For example, the newest version of the system menu available is v. 288 (NTSC/J), v.289 (NTSC/U), v.290 (PAL).  The only difference between those three versions is two different files — the main executable for the menu (a .DOL file, more or less) and an ARC archive that stores compressed versions of the HTML / image resources.

All of this is fine and good, but why put them in separately named directories? (E.g. EU/EU/GER/Setup/ScreenSave.html above)?  The path name could always be the same because there are different files for each version.

So, there’s a specific path that the graphics need to sit at.  So, you’d think they’d hard-code a pathname like that into the code, right?  No…

The code’s pretty hard to tease apart, but they seem to be trying to determine the system region from the SYSCONF file, and then building up a pathname to load like so: sprintf(filename, “html/%s2/iplsetting.ash/%s/%s/ENG/Setup/ScreenSave.html”, region, region, region).   This is so silly, because if they had hard-coded the path then the system would have booted just fine.  

The code does this in slightly different ways in several places — this has to somehow distinguish the semi-brick case from the full-brick case, although I don’t think that anyone really understands why some people end up with one and not the other.

Still, a semi-brick is better, because it will still boot discs, meaning that there is still some hope for a fix.  If you can find a game with a newer version of the system menu in its update partition, then you can run it, and it will automagically fix things.  However, this requires a wait of several months until one comes out.

A friend came and asked me if I could help him figure out how to fix a “semi-brick” Wii, manually.  All that needs to happen in this case is we need to install a newer version of the System Menu WAD.  There are a number of ways to do this, and unfortunately I picked the wrong one.

Marcan had written some test code that can manually load the System Menu, and I modified it to try to patch the System Menu enough to get into the Settings screen by correcting the pathname.  My theory was that then we could use that to have the Wii update itself using its own internal code.  This had to be safest, right?

Well, now we have:

Looks like I just bricked a Wii.  The owner was kind enough to send me the Wii so I can try to unbrick it — this is not currently possible, but I think we now know enough to do it using an external NAND flash programmer and a bunch of software which I need to write.

The bright side of this, if there is one, is that I’ve been wanting to address the “bricking problem” for a long time, and now I have a perfect test subject to work on.

More about my plan of attack in my next post.