An article from Bushing the man behind the Twilight Hack
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)
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.
Enjoy!
full details -- > http://hackmii.com/2008/04/brickmii/
