When Nintendo “accidentally” released IOS37 on their update servers last month, they may have only been trying to intimidate Datel into not making more copies of their Freeloader; we may never know. The effect, however, went far beyond that, and in a strange direction.
No, this little chunk of code appeared on our Wiis, and I made a single comment on IRC that caused much wringing of hands in the Wii hacking community. At the time of this writing, a Google search shows 4,780 hits for “IOS37”, virtually all of which are variations on the same misguided themes:
- Ohmigod, Nintendo snuck in this patch and it broke everything on my Wii
- Wait, no, nothing happened — The Wiibrew people are playing an April Fool’s joke on us — one week early. Let’s go deface their Wiki and then link to it as evidence.
- No, there actually is this “IOS37” file on my Wii, but I don’t know what it does. I’m scared of it, let’s kill it before it ruins everything.
All of this noise is fairly irritating, and it’s occasionally hard not to take it personally, but the last one is what I find most disturbing. The real effect of IOS37 was that it escalated this “arms race” to the level of patching firmware. Even though nothing has actually changed, it’s clear that at some point in time we will have to modify some of the system software if we want to keep every one of our hacks alive. (Whether this is even a worthy goal is up for debate; even without the hash-checking bug, there’s still plenty we can do.) In response, people started tripping over each other in a race to release “a solution” — to this problem that didn’t actually exist.
The Wii’s design has a fatal flaw — at least from our perspective — in that it does not have any sort of recovery mode. If a single piece of code involved in the boot process malfunctions, your Wii is bricked in the true meaning of the word — unrecoverable. You’re done. I’ve seen it happen before, and you just get this awful feeling of despair in your stomach. Then what?
There are now several programs that have been hurriedly released to solve the IOS37 “problem”. All of them contain disclaimers — I think — that say “this may ruin your Wii if you run it, so if it happens, it’s your own damned fault”. Is this really ethical?
Maybe. There are many useful things that can’t be done without introducing some amount of risk. Where do we draw the line? As coders, I think that we have a responsibility to do what we can to mitigate the risk and protect our users. How? I have a couple of ideas, but I’d love to hear yours:
- Test. There are some patches that are difficult to test — say, patches to boot2 — but with most other patches, you can at least try to simulate conditions and see what happens. While working on the Homebrew Channel, we had some close calls (caused by invalid banners) that we only caught because we spent a lot of effort figuring out how to test our work. I don’t see any evidence that other people are doing this. I think that people are coding until they have something that works — at least once — and then releasing it. Great, except these tools are intended to protect users against a hypothetical future threat. How do you test to see if it’s effective? How do you test to see if it’s safe, even if a user goes through a future system update process?
- Explain. Not everyone who uses your software is going to want to read through a length rant about why your Wii might get fucked up, but you can at least try to explain what risks there are, why they are there, and what things people can do to try to avoid those risks. Things like “don’t patch code that is necessary for your Wii to boot unless you have a specific, immediate need to do so.” Things like this show that you have at least taken the time to think things through, and that you are at least aware of all of the possible risks. If you don’t understand what you’re doing well enough to clearly define the risks, how can you claim you can protect your users from calamity?
- Plan for the worst. Assume that your software will fail at exactly the wrong moment. Can you do anything to make that less damaging? Can you tell your users how to “undo” your modifications? Can you provide some suggestions for recovery?
Let’s try to make this scene a reputable, clean one, even despite the challenges imposed by the Wii’s architecture.
14 responses so far ↓
1 marcan // Apr 11, 2008 at 12:55 pm
I’d like to add that, as a result of this debacle, people have become extremely paranoid about newer Wii updates. Recently, we have been hearing about a suspected update that only some people seem to have been getting. We still don’t know whether this is a false alarm or just a release in some regions, but people need to stop making so much noise about it. Relax. If an update comes along that breaks something or fixes something, you’ll hear about it (as you did with IOS37, even though IOS37 doesn’t even really break or fix anything yet). Nintendo isn’t going to suddenly start making every other update break homebrew, the freeloader, or anything else – they also have other goals which are probably way more important, such as new channel releases and features, WiiWare, etc.
2 Dasda // Apr 11, 2008 at 3:57 pm
I’m glad you want your users to feel safe using your hacks, that they shouldn’t worry about bricking their Wii. You cannot know what Nintendo will do to prevent our hacks in the future, but you can get well prepared. For example, I think the Zelda hack was a great hack, because it did what it should, and at the same time had no huge risks, and was very hard for Nintendo to patch (because the save is signed as it should be, no tricks made). When we start using the trucha-signature for our hacks, everything will be different since it’s going to be patched sooner or later (and downgrades aren’t really good for newer games using newer firmwares). But Nintendo’s reaction is obvious to me, if a bug in the verification system gets public, of course you want to fix it as soon as possible. Especially when Datel released their Freeloader using the same exploit.
Let’s hope we can provide a hack which would remove the signature check, so we wouldn’t have to worry about that. That would be my primary objective if I was in your position.
3 bushing // Apr 11, 2008 at 6:27 pm
Yes, it’s possible to disable all of the signature checks. It’s actually fairly easy, as far as the actual coding goes — the big problem is that you have to patch boot2 and every version of IOS, and then you have to find a way to prevent boot2 from being upgraded, and you have to patch any new IOS version before installing it.
boot2 is the next exciting frontier, but I can’t touch it until I come up with a way to to unbrick Wiis with hardware. (I have ideas…)
4 doragasu // Apr 14, 2008 at 12:00 am
Hi bushing. I’m a noob, so I’m sure I’ll only write stupid things, but… isn’t posible to unbrick a bricked Wii with a Nand backup and an infectus modchip?
5 LittleStevie // Apr 14, 2008 at 3:22 am
I respect your work and your whole teams work Bushing so just a quick question…. I would like to know if my understanding is correct. Boot 0 and boot 1 are contained seperate(sp?) from the NAND and boot 2 is contained with in the NAND correct? if so then wouldnt a NAND programmer be an ideal protection method against bricking (i know someone mentioned an infectus but i cant trust those things after 2 killed xbox360’s due to an error in there 1st released diagram and to some extent there lack of VCC on the wii nand) Also isnt boot2 in the broken part of the RSA signature check? (i remember reading something about tmbinc running his own boot2 with an FPGA) ….
Sorry it turned into a few questions and a run and a bit of a ramble
Littlestevie
6 bushing // Apr 15, 2008 at 5:11 am
@doragasu: No, not unless you had previously backed up your Wii’s NAND flash (with an Infectus or similar). You can’t use a dump from another Wii because the encryption key is different, and it’s difficult to get the key you need from a bricked Wii.
@LittleStevie: That’s close; boot0 is a ROM inside the Hollywood, and boot1 and boot2 are at the beginning of the NAND flash. boot1 can’t be modified, though, because it’s fixed at the factory — boot0 loads up boot1, takes a SHA1 hash of it, and compares it with a hash burned into one-time programmable memory at the same time the rest of the keys are programmed in.
Yes, boot1 is what verifies boot2, and the current boot1 on Wiis has the buggy signature check; this is why we will (eventually) be able to modify boot2.
If you know of another NAND flash programmer that is affordable, I’m all ears — and no, none of the hacked xD /SmartMedia readers will work (I’ve tried, and the addressing scheme doesn’t match up). As I mentioned above, it “should” be fairly easy to unbrick your own Wii — in any circumstance — as long as you have a full backup and as long as you have a means by which to reprogram the chip with hardware. That having been said, this has not been well-tested — I’ve read a few reports of people saying they backup up their Wii’s flash, and then erased it. They confirmed the Wii wouldn’t boot, and then they reprogrammed the same chip with their backup, and it worked again. I don’t know of anyone who’s actually backed it up and then restored it several months later.
7 LittleStevie // Apr 15, 2008 at 9:20 am
Thanks for the correction there. It is much appreciated. I’m still learning the total security system of the wii, but im picking it up slowly (just moved across from the xbox360 camp sick of them RROD’ing and putting it in the cant be f*%$ed right now basket). i had a quick look around and the programmer that i use for NAND and NOR doesnt support any bigger then a 32MB NAND so thats pretty useless in this case (also dirt cheap and break easy). Having a quick look on google i can see what you mean (cheapest one i found was us$695 and that was without TSOP48 adaptor) The only really affordable one that i came across was the infectus, and i have already stated my discust of there software (the hardware is actually quite nice 16xbox360 installs and counting). If there was a program out there that took use of there new “open” driver that allows it to interface with any flashing program it may be a nice solution.
LittleStevie
8 bushing // Apr 16, 2008 at 3:20 am
Yeah, I may very well end up having to write one — or rather, get someone to help me modify the demo code they have on their site to not suck and to maybe be able to understand the different sections of the Wii flash. (Ew, Windows coding.)
As it stands, I currently have to use that demo program because the main software is completely non-functional 🙁 (http://www.infectus.biz/forum/index.php?topic=1585.0)
9 LittleStevie // Apr 17, 2008 at 6:15 am
lol yeah windows coding sucks lol and yeah that demo proggy is fucked i went thru it and its way over my head when it comes to addressing NANDS (actually when it comes to “c” anything more then “hello world is out of my depth lol) but i can reverse engineer like crazy go figure lol.
sorry i wasnt any help on the nand programmer front
10 DimensionT // Apr 17, 2008 at 6:13 pm
Thanks , Bushing. That was a great read. People are being far too enthusiastic, which might end up putting them in a posistion they don’t want to be in.
I was going to ask you what your stance is on the hacked homebrew channels that someone released… Which remove the time limits.
What kind of effect do you think they might possibly have in the future? In my opinion, it’s somewhere along the same lines as what’s been said in the article. No one really know what the channels might do during the next system update?
I’ve been debating this for a while, and am intrested in what your stance may be. Seeing as how you’re the most credible source.
Thanks again!
11 bushing // Apr 28, 2008 at 12:08 am
I’m not a big fan of them, because we put those time limits on them for a reason — we didn’t want people to keep using them because they weren’t done, and we (hadn’t/)haven’t done much testing with IOS37 to make sure there would be no problems.
We’ve done some more testing and no longer have any specific reason to think IOS37 will brick Wiis that have a “custom” channel installed — unless something changes — so we will be releasing the “real” homebrew channel shortly. I promise it’ll be less butt-ugly than the demo!
12 ChucktheTekkie // May 5, 2008 at 9:12 pm
The Homebrew channel looks awesome and I can’t wait.
My question is will you also release it in elf form so just in case Nintendo activates IOS37 and prevents the channel from working we will still be able to use the channel through the Twilight Hack?
Will the Homebrew Channel be capable of running actual channels like VC channels that have been fixed to run games that have not been released on VC?
In any event, Great Work and Keep it up.
13 bushing // May 6, 2008 at 1:19 pm
Sure, we can release it in ELF form. That’s a good idea.
We don’t have any plans to make it run other channels stored in NAND — in general, we’d like to discourage people writing stuff to NAND due to the danger of bricking, so we’ll be running all apps off of the SD card. Besides, there’s already a perfectly good menu to run channels 🙂
14 Your Wii is not a PSP (or an Xbox, or …) // Jun 12, 2008 at 3:56 am
[…] For more info about the IOS system, see Wii System Software: a guided tour and On firmware patching, risk and responsibility. […]
You must log in to post a comment.