HackMii

[In Spanish: http://www.elotrolado.net/post_Gracias–Waninkoko_1711666033#post1711666033]

I’ve ranted a bit about how we need to be responsible as coders and consider the effects that releasing software will have on the community — in terms of hardware damage. I didn’t think that I had to also point out the need to consider broader, longer-term effects.

Several people have send me links to a recent release — the first pirated VC game. No, I’m not posting any links, and please don’t post any in comments — it’s easy enough to find anyway, if you really care. It’s currently the raw decrypted files, and not yet in a form suitable to be installed on a Wii, but I give that another 24 hours.

This is a direct result of Waninkoko’s release of his NAND FS Dumper. This is not the same as his “NAND Dumper” that he released a few days ago, which dumped the raw, encrypted contents of NAND to an SD card. (That’s pretty easy to do — just do some reads from /dev/flash — and is based on like 6 lines of code that I gave him. It’s also mostly harmless.)

No, this uses a exploit in the NAND FS permission system on the Wii that lets it read all of the contents of all titles on the Wii — including decrypted VC games and anything else.

For what it’s worth, this is the reason we never released any tools or code after the 24c3 hack. Segher asked that we not, in the fear that this moment would come. So, we didn’t, and sure enough it happened anyway, although it took perhaps four months longer than it would have. There is only so much we can do.

Anyway, Waninkoko’s code is almost exactly the same as some code that dhewg released months ago — the Wiifuse server. What’s the difference? Dhewg didn’t want to enable this, so he left it to the end user to provide the authentication credentials that Wiifuse uses to read the contents of the NAND. Waninkoko’s program does the same thing, but it comes with a hacked TMD that enables “root access” (more or less).

Why is this a problem? Remember what happened when Datel released their Freeloader?

Piracy is morally wrong — developers need to eat, too. However, I don’t expect this to persuade everyone, so I will also offer a more pragmatic reason. Nintendo’s primary motive in patching security holes is strictly financial — in the same way that releasing firmware patches is dangerous for us because it requires careful testing, releasing firmware patches is expensive for Nintendo because it requires careful testing on their part, too. Consequently, they will not bother to fix bugs until they cause specific, identifiable monetary loss on their part.

We saw this with IOS37, which I believe was a reaction to Datel’s Freeloader. However, Nintendo has never bothered to activate IOS37 — why? I think it’s because they were specifically trying to prevent / discourage Datel from pressing discs for US and Japanese Wiis. All of the PAL discs have already been made, and Datel has already spent all of the money they need to spend to sell those discs. At this point, they will continue to sell the discs they made because they have nothing to lose by doing so — and when IOS37 comes, they will try to deal with it however they can.

On the other hand, they have not yet spent the money to make USA and NTSC/J discs. They now know there is a very real possibility their current software will stop working on updated Wiis at some future date, so they now have to sit and wait for that “shoe to drop” before proceeding. Nintendo released IOS37 to stall Datel.

Now, Nintendo needs to keep people from copying VC games. So what will they do? They have to patch all of the things that could enable this. So, they will now go ahead and patch all of the old versions of IOS, and they will probably go ahead and patch BOOT2.

I know that Waninkoko is not a bad guy — he and I have chatted a fair bit on IRC — but I think he is reckless and does not think through the consequences of his actions.

Oh, and another thing — people keep asking me “Will there be some way to downgrade our consoles once IOS37 has been released?” I hate that question. Why?

The answer will always be “Probably, but it will require finding a security hole which Nintendo hasn’t patched.” That’s why I don’t like to answer the question — because if I start talking about all of the security holes that could be used to downgrade a Wii, then they will get patched before we have a chance to use them.

Guess what? The hole that Waninkoko is using to read VC games out of the NAND FS is the same hole that I was planning on using (first) to be able to downgrade versions of IOS. So, when it takes another few months to be able to downgrade a Wii, you can say “Thanks, Waninkoko!”

Bruce Schneier publishes a monthly newsletter called Crypto-Gram. It’s a fascinating read, but one of my favorite parts is a recurring section he has called “The Doghouse” where he picks (on) a particularly bad example of crypto-related hardware or software. Generally, they are programs or hardware that make broad claims of security but are trivially broken — or generally anything which makes bold claims with little to back them up.

I’d like to bring that to my blog — I don’t know how often; it depends on how much bad software is out there. Maybe this will be the first and last entry.

Superken7 recently released a program called the WiiSystemmenu-wadpatcher (original text in Spanish — English translation courtesy of WiiNewz):

this tool patches the updated wad that prevents the loading of ISOS patched by trucha signer. This tool patches the .WAD in the systemmenu in particular the WiiSystemmenu-vXXX.wad.

initial problem:
in a short amount of time nintendo through media updates issues the famous IOS37 which prevents isos from being loaded that were previously patched with trucha signer.

Solution:
To stop this and because there is no other tool like this, i have taken a few days to create a wadpatcher. You can patch your wiiSystemmenu and subsitute it with one compatible with trucha signer so we can once again load our isos. I mainly did this so i can play mario kart without issues. At the moment i have tested it with Naruto Clash of the Ninja Revolution PAL and it works.

This is exactly the kind of thing that I was afraid of, and ranted about yesterday. What’s wrong with this program?

Well, mainly, there is no existing system menu WAD that needs this patch. As I said, IOS37 is not currently used by the System Menu (1-2), nor anything else. So, already — we have a program here which is not a reaction to a current problem, but instead is an attempt at a “preemptive strike” … I guess. Or being first. One or the other.

The reason there are “no other tools out there like this” is because it’s useless and dangerous. (It also happens to be trivial to write — this tool modifies one byte in the TMD and then resigns it.)

Why useless? Again, there’s nothing for it to do … yet. I think the author expected Mario Kart to either ship with IOS37, run on IOS37, or include an updated version of 1-2 that uses IOS37. Well, okay. That claim ended up being false, so at best this is a program that is before its time.  Even if Mario Kart did use IOS37, the author’s claim that he wrote the program so he could “play mario kart without issues” is dubious — this program has — and never will — have any effect on the ability to play Mario Kart, or any other game with a valid signature.  It doesn’t matter what version of IOS the game uses; the system menu doesn’t really care about that.

How could it eventually be useful? That’s a tough one.  If you go and install a patched version of 1-2, then it will just be overwritten when you next install a game with an updated 1-2 in its update partition. That’s what will happen to most people. The only way this could possibly be useful is if a new game comes out, and someone opens it up in their favorite tool and actually does the research necessary to figure out if that disc contains a “problematic” Systemmenu.WAD. Then, they’ll presumably go online and warn all of their friends that they need to go patch their new ISObackup to remove that Systemmenu.WAD and replace it with one patched using their tool.

That’s pointless. First off, anyone who already installed their non-backup disc first will be unable to use this program. Oops. Hope they got the message. I guess it’ll have to be posted far and wide — the “IOS37 threat” shows that will happen anyway. Maybe that would be a more appropriate time to release a utility like this.

Why dangerous? I don’t think the author actually understands how this works, based on the comment about running Mario Kart. How many different ways could this brick your Wii? I can think of at least 3:

1. If the code which verifies the signature of the System Menu’s TMD is changed to fix the signature-checking flaw, it will declare your system menu invalid, and refuse to boot.  Quick quiz:  Where is that code?
2. The current System Menu uses IOS30; historically, they have only changed it to use a newer version of IOS when it required / supported features in that newer version of IOS.  There were a lot of other code changes in IOS37; it’s a fair assumption that the hypothetical new system menu will need some of those features.  Quick quiz:  What happens then if you patch it to use a different IOS?
3. I think that 1-2 currently checks the currently running version of IOS, and ensures that it falls within a range (30+, or something).  What would happen if you patched the TMD to use a different IOS version?  Have you tested this with the (still-hypothetical) IOS37-using System Menu?

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.