So, here’s my big project for, well, this quarter or so. I’d like to be able to unbrick a Wii. Any Wii. I think you could rightfully call this the “Holy Grail” of Wii-Hacking projects right now — many have tried, some have written about it, and to my knowledge, nobody has succeeded. It still won’t be easy, but I believe we now know what must be done and have some ideas about how to do it.
The problem: The Wii has a single-string bootup system, with several points of failure and no safety or recovery mechanisms. It appears to have been designed with the assumption that internal testing (by Nintendo) can catch all problems that would prevent the unit from booting, and that the other failures would be rare enough that they could be dealt with at the Nintendo factory.
This was first discovered when people bricked their consoles by installing System Menu updates from “import” games. This is a pretty fucking lame problem, but it is obviously something that didn’t occur to Nintendo to test. Fortunately (for them), playing import games required that you physically tamper with your Wii, voiding your warranty in the process. So, this oversight on their part didn’t really cost them any money.
Lately, the situation has grown more complicated. Many new (official) updates have been released, each of which carries a minute risk of bricking. Datel’s Freeloader (among others) allows playing of import games without any visible modification of the console. The Twilight Hack allows unsigned code to be run; this can then be used to modify system files (e.g. banners), and there seems to be little to no error recovery built into any of the existing system software. Oops.
So, you install a slightly-corrupted channel banner while experimenting with channel creation, and now your Wii freezes on the “warning screen” (with the throbbing “Press A”). Now what?
Here are a few ideas that have been suggested but will not work:
- Replace flash chip with one from another console (or a cloned one from another console): Will not work because each Wii uses two unique keys to read and write the contents of the flash chip. These keys are not tied to a particular flash chip, but rather are stored inside the Hollywood chip.
- Backup flash chip, and then later reflash chip from backup: This is almost viable, but it requires that you have a clean backup of your particular Wii before you brick it. This applies to very, very few people, because it requires foresight and special equipment which is difficult to install. More on this later.
- Use some magic boot disc to “repair” the Wii: This will not work. The System Menu is the only software which knows how to boot a Wii Disc; if it does not run, you can’t use a disc to do anything.
- Plug some special USB dongle / memory card / SD card / Wifi thingy in to trigger a hidden recovery mode (ala the Pandora Battery): This is a neat idea, but it won’t work. Support for this would have had to be specifically written into the Wii system software, and after 6-8 months of auditing the Wii’s boot path, I’m pretty confident that no such code exists.
- Maintenance Mode: Sorry, folks. Wishing something will fix your Wii won’t make it happen.
- Fix the specific bugs in the software which cause it to be so fragile: This is a nice idea, and one we will pursue someday. However, it’s not a fix for the current bricking problem, because A) you can’t patch bugs on a system you can’t boot, B) patching the bugs is risky and will brick your system if you’re not careful, and C) most bricking scenarios happen when new software is installed; this means that any defensive patches you would make would be wiped out when they would be most needed.
So, with all of those out of the way, what’s left? What can we do?
We need to modify the encrypted contents of a Wii’s NAND Flash filesystem in a way such that whatever damage or corruption will no longer interrupt the boot process, without disturbing the security mechanisms that try to prevent us from doing this.
There’s a lot there, but since we’re engineers, we can apply good engineering practice and break this up into several discrete problems. Each of these is complicated enough to deserve (and will receive) its own blog entry, but I’ll give an overview here before I go to bed:
- Hardware access to the NAND flash: We need to be able to read and write the raw contents of the NAND flash, even on a unit that is bricked. This requires a hardware solution. The cheapest and most common solution is the Infectus chip, which has severe problems that prevent it from being used without custom software that has yet to be written
- Keys: In order to read and modify the raw contents of the NAND flash chip, we need to be able to extract this data from the Hollywood / Starlet. Tmbinc demonstrated this using sophisticated equipment — we should be able to do this with a modified / hacked version of boot2, but it will require some cleverness to figure out how to take these keys and communicate them to the outside world. (boot2 is not able to talk to the screen, controllers, SD card, network, etc…)
- Once we have the keys, we need to write software to let us modify the contents of the NAND filesystem to repair whatever damage may be there. Segher’s zestig is a good start, but it’s read-only and requires the aforementioned keys. Even if you have the keys and can figure out how to modify it to alter the filesystem, you must then figure out the bizarro slightly-modified HMAC scheme that IOS is using to “sign” the contents of the flash FS. I’ve spent more than a week working on this specific problem, with little success. But more on this later.
- Once we can modify the filesystem, we must figure out what exactly changed to cause the console not to boot, and what the simplest way is to fix that. This sounds like the easiest part, but to my knowledge nobody has yet actually sat down to document this.
So, there you have it. Four manageable problems, all of which need to be solved to make this work — and all of which can be worked on independently. If you’re bored and want to help, feel free to take one of them and see what you can do. I’ve started work on parts 1 and 3, and have some ideas for 2 and 4 … but, the more the merrier.
(That having been said, please refrain from making suggestions unless you fully understand the problem you’re trying to solve. I’ll write more about each of these over the next week, but I think it’s fair to say that those of you who will be able to tackle these problems probably will be able to take what I’ve written here today and run with it…)
34 responses so far ↓
1 svenk91 // May 4, 2008 at 6:52 am
nice and interesting entry as always.
i hope you can find people skilled enough to help you. i would like to help but i have no knowledge in these things 🙁
2 Mark // May 4, 2008 at 9:37 am
Awesome news! Hopefully whatever fix you find will encompass the semi-bricking problems as well, which are somewhat more common (although I can see the attraction of full unbricking, particularly when testing more dangerous stuff ^^).
3 Newbie // May 4, 2008 at 11:33 am
boot2 is not able to talk to the screen, controllers, SD card, network, etc…
boot2 supposed to load the firmware or sysmenu or whatever.
I.e. boot2 can read NAND. The question is: can it write to it too?
please refrain from making suggestions unless you fully understand the problem you’re trying to solve
Sorry, cannot resist…
4 Phredreeke // May 4, 2008 at 12:20 pm
boot2 supposed to load the firmware or sysmenu or whatever.
I.e. boot2 can read NAND. The question is: can it write to it too?
I don’t see why boot2 couldn’t write to NAND. boot2 could do pretty much anything it wants with Wii hardware, just that it has to have its own code for it*. It’s not able to call functions from IOS like ordinary Wii software.
* and you have to fit the code in the space allocated to boot2 in NAND.
5 bushing // May 4, 2008 at 5:00 pm
Yeah, boot2 can read and write from NAND. I’m still looking for the simplest function to write a block out to NAND, and then I’ll probably find some unused page and stash the keys there; then, we could read them out when we read the rest of the data out.
There’s actually quite a lot of free space available for boot2 hacking — there are two copies of boot2, of which only uses about 160K out of 512K. Another possible solution — and one that’s very tempting — would be to add SD card support to boot2. The SDIO driver from IOS is about 10K or so — that’s small enough that we could probably rewrite it from scratch, and patch it into boot2. We’d still then need to figure out how exactly to use to that, but it’s possible that we could use that alone to unbrick Wiis… eventually. This may or may not end up being a better solution than that outlined above.
@Mark: The semi-brick problem has already been solved. You just need to install a newer version of the system menu — the correct one for your region.
6 Mark // May 4, 2008 at 10:58 pm
@bushing: I understand that, but the problem is if there are no newer updates out and nintendo continue their trend of just releasing 3.1 on the disks there are people that could be stuck. I just think it would be nice to have a failsafe solution to fall back on.
7 amoxiflash // May 5, 2008 at 12:05 am
[…] XHTML ← UnbrickMii […]
8 Phredreeke // May 5, 2008 at 2:21 am
I understand that, but the problem is if there are no newer updates out and nintendo continue their trend of just releasing 3.1 on the disks there are people that could be stuck. I just think it would be nice to have a failsafe solution to fall back on.
They’ll put 3.3 on discs sooner or later, if nothing else for IOS37 🙁
9 Superken7 // May 5, 2008 at 5:02 am
Sorry if im saying something ‘funny’, but about that semi-brick solution… we will have to keep in mind that a future update might trucha-fix wiis, thus making it a solution which might not be desirable in a near future.
amazing bushing 🙂 i’ll keep an eye on this project. very interesting. good luck to all working on it.
10 bushing // May 5, 2008 at 5:41 am
Superken7: The one “saving grace” here is that we can download the System Menu contents from the Nintendo server, including the valid, correctly signed TMD, and assemble a WAD that does not need to be fake-signed. If you want to install it using an update partition on a disc, well, yes, we will have to Trucha-sign that — but the part that gets installed on the Wii will have a real, intact signature.
I made one of these ISOs for NTSC for a friend — if people are interested, I could make some for the other regions, too.
11 WunSick // May 5, 2008 at 5:57 am
Nice work. Hard to resist suggestions ideas haha
12 Mark // May 5, 2008 at 8:28 am
/expresses interest.
I think it would be great for that to happen – if you have one for all 3 regions it will sort out all the people who have semi-bricked with games with the latest update on them (also, having a disc with 3.2 (if I understand you correctly) would be useful to avoid a possible 3.3 + IOS37 combo.
13 Depois da pandora, temos UnbrickMii - NewsInside.org // May 5, 2008 at 1:38 pm
[…] quiser saber mais sobre o projeto, pode dar uma lida nesse post diretamente no blog: UnbrickMii (em […]
14 Kirtaner // May 6, 2008 at 11:50 am
@bushing: continuing from an earlier post, yes my Wii is NTSC
15 bushing // May 6, 2008 at 2:09 pm
Ok. Stay tuned.
16 Xoye // May 6, 2008 at 3:30 pm
If the problem is only broken links, maybe a homemade update with every languaje acts like vaccine to prevent full-bricks.
Thanks a lot for everything
17 Newbie // May 6, 2008 at 8:42 pm
There’s actually quite a lot of free space available for boot2 hacking — there are two copies of boot2, of which only uses about 160K out of 512K. Another possible solution — and one that’s very tempting — would be to add SD card support to boot2. The SDIO driver from IOS is about 10K or so — that’s small enough that we could probably rewrite it from scratch, and patch it into boot2. We’d still then need to figure out how exactly to use to that, but it’s possible that we could use that alone to unbrick Wiis… eventually.
IMO, it’ll be perfect solution!
The boot2 might implement following algorithm.
If(SD card is inserted){
If(it has BackupNAND folder && it’s empty){
create backup NAND in it (yes, it’ll be encrypted).
} Else if(it has RestoreNAND folder && it has a file matching certain criteria){
restore NAND
}
}
I guess we don’t have to know console keys to do above, right?
18 Newbie // May 6, 2008 at 8:54 pm
One more thought:
I think it’s fair to say that those of you who will be able to tackle these problems probably will be able to take what I’ve written here today and run with it…
IMO, in order to tackle this (i.e. write code and test it), it should be a way to rollback/restore erroneous attempts. I understand you do have one based on Infectus chip plus you custom program as “manufacturer” one simply doesn’t work.
I.e. for the rest of possible tacklers (Wii + Infectus) it’s “chicken and egg” problem still…
19 allan // May 7, 2008 at 11:42 am
I’m willing to send out 100USD to anyone who can help me unbrick my fully bricked wii that goes straight opera error.
20 bushing // May 8, 2008 at 5:07 am
@Newbie: That’s not a bad idea. We probably won’t have a filesystem, but we might be able to set a flag on the card. First, though, we need to write the SD card code ..
21 Newbie // May 8, 2008 at 12:00 pm
We probably won’t have a filesystem, but we might be able to set a flag on the card.
IMO, The file system with all pre-allocated files should in place before you start backup/restore.
Traversing FAT16 is a piece of cake. You can/should even pre-allocate continuous flies.
Backup operation simply writes to those files. And a flag could be set in FAT16 directory.
Sorry, I keep saying: you can easily do this and that. I know I’m not really helping much. Just trying to throw some ideas…
22 nerdyone255 // May 15, 2008 at 11:18 am
@bushing/Kirtaner:
would said iso fix a mkw brick? ive got a semi, my ntsc was semied with mkw pal. im guessing 3.2u would fix it, but obviously cant get online to dl it…
23 Semi-brick fix discs for all three regions (hopefully) - Page 2 - WiiNewz Forums // May 21, 2008 at 7:07 am
[…] project ended up brinking a Wii during the Channel install. You may want to check out bushings blog UnbrickMii for a little more in depth details __________________ Send a PM for Console repair and/or […]
24 ---X-A-N-A-X // May 31, 2008 at 11:40 am
Nice Job.. Guys..
25 boot0 // Jun 1, 2008 at 3:30 am
[…] UnBrickMii – Introduction, explanation of a 4-part plan to unbrick any Wii […]
26 Excaliber90887 // Jun 11, 2008 at 7:29 am
Although I am not currently bricked (thank heavens) I would like to say thank you for pursuing this problem…I will be following you every step of the way…can’t wait to see the outcome.
27 SonyBasher // Jun 19, 2008 at 9:10 am
Wait… can i boot to a firmware ISO without a mod chip so i can revert to firmware 3.2U??
28 etc // Jul 1, 2008 at 4:26 pm
[…] UnbrickMii / Factory — both of these have updates which deserve their own article. Stay tuned. […]
29 fireace // Jul 1, 2008 at 7:53 pm
I’ve had an idea in my head for a while that might be helpful I’m just not sure how do-able it is. Would it be possible to trick the wii into reading the NAND of a USB stick instead of its internal NAND. Eg. you could run a program that would backup your NAND onto a folder into the USB stick and then reboot the wii and trick it into thinking that folder was the NAND. This way you play around with modifying stuff with out fear of bricking. Then have some sort of exit function to go back to the original NAND when your done. This is something I would be interested in making but I havent done any Wii programing yet so I’m not sure if its even possible.
30 fireace // Jul 1, 2008 at 8:00 pm
On second thoughts a SD card would probably be easier than a USB stick.
31 bushing // Jul 2, 2008 at 6:18 am
No, not really (sadly).
32 WhoDares // Jul 2, 2008 at 1:12 pm
Anybody have a decrypted boot2 and disassembly? I’ve been looking at the boot1 section where it loads boot2 and want to try and understand a few things.
33 Jack // Jul 19, 2008 at 7:39 pm
“but it will require some cleverness to figure out how to take these keys and communicate them to the outside world.”
If boot2 could flash the power led, the key could be read by the user that way.
34 WiiCrazy // Sep 3, 2008 at 11:49 pm
I’ve bricked my wii recently installing an injected c64 game with custom banner… Warning screen displays, pressing A displays “… System files corrupted… refer to the …” white on full black.
I have a d2ckey modchip and autobooting doesn’t work with the zelda game, custom isos. But the strange thing freeloader (backup) works.
Reading you above blog entry I’m confused as to if my brick prevents autobooting, or the modchip or something else.
I have a dump from yawnd (taken in normal mode) and the keys for my wii. Would programming the flash with the dump using the infectus chip work with that?
You must log in to post a comment.