wraggster
May 5th, 2008, 19:53
New article from Bushing: (http://hackmii.com/2008/05/unbrickmii/)
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 ****ing 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…)
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 ****ing 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…)