HackMii

Notes from inside your Wii

HackMii header image 2

Putting the genie back into bottle? (MIOS)

June 22nd, 2008 by bushing · 63 Comments

The June 16th (“3.3″) Wii System Update did more than bring the death of the Twilight Hack (sort of) and a patched version of IOS30.  It also brought new versions of BC and MIOS — which actually may be the more interesting of the changes in the update.

BC and MIOS are titles 1-100 and 1-101, respectively.  MIOS is the Gamecube compatibility layer — a fairly small amount of ARM code that runs instead of IOS when Gamecube games are running, and then the 157k Gamecube IPL — the PPC code that actually reads the Gamecube disc and boots it.   BC is still an unknown; in many ways, it resembles boot1.  Both are about the same size, and both contain code to load boot2 from flash and execute it.  When the Wii System Menu detects a Gamecube disc, it launches title 1-100 — BC, not MIOS.   It’s possible that BC launches boot2 which launches MIOS — we’re still not sure.   Let’s come back to that.

MIOS contains the GC IPL that was discovered about a year ago.  The ARM code serves mainly to load the GC IPL into memory and start the PPC running it; the rest of the code seems to just be a stripped down version of IOS (and therefore resembles everything else.)  However … some highly suspicious code has been added!

I’d imagine it looks something like this:

int do_hash_comparison(void) {
//	using the memory mapper, this should be aliased to
//	0x0D408000.  This resides in the on-chip SRAM.

	u8 *buffer  = (u8 *)0xFFFF8000;
	u8 *MEM2_ptr = (u8 *)0x10000000;  // = 0x90000000
	u32 hash1[5];
	u32 hash2[5]={0x4F00A54E,0x57E1E2C4,0x78634365,
                        0xF56BA5D3,0xF7DECA52};
	int i;

	memset(buffer, 0xCAFEBABE, 0x8000);
	memset(buffer + 0x8000, 0xCAFEBABE, 0x8000);
	aes_set_key(0x2B7E1516, 0x28AED2A6, 0xABF71588, 0x09CF4F3C);
	sha_init();

	for (i=0; i<1024; i++) {
		aes_set_iv(i, i, i, i);
		aes_encrypt(MEM2_ptr, buffer, 0x10000);
		sha_update(MEM2_ptr, 0x10000);
	}

	sha_finalize(hash1);
	if (hash1[0] == hash2[0] && hash1[1] == hash2[1] && hash1[2] == hash2[2] &&
		hash1[3] == hash2[3] && hash1[4] == hash2[4]) {
			do_log_message("%s shaHash: %x %x %x %x %x [%u ticks]\n",
				NULL, hash1[0], hash1[1], hash1[2], hash1[3], hash1[4], 0);
			return 0;
	}

	do_log_message("Hash comparison failed. Halting boot!\n");
	return -1;
}

This is actually pretty clever — far more so than anything else in this update. I don’t think there’s anything special about any of those “magic numbers” — what this does is overwrite all 64MB of MEM2 with (pseudo-) random garbage, verify that it was actually written, and only then reboot into GC mode.

This not only prevents the tweezer attack we used to get the common key last year — which was the primary piece of information that has made everything else possible, but it prevents what tmbinc called the “anti-tweezer attack” where we short some address lines while it’s trying to clear the memory to keep it from actually clearing the memory.  That won’t work, because it verifies the hash to make sure the garbage was actually written.

Why?

I’m not really sure — getting the common key was a one-time hack.  The only thing I can think of is that they are trying to reclaim the platform.  Maybe they intend to generate a new common key for use on new Wiis — Wiis that will not be able to read current games — and current Wiis will not be able to read any game that will work on those Wiis.  Does this make any sense?

Maybe.  Nuke mentioned on his forum that new Korean discs can’t be decrypted using the normal USA/JAP/PAL common key.  I can’t confirm this — the only disc image I’ve seen seems to have been corrupted — but it’s certainly possible, and it would explain this MIOS change.

In other news, the new BC has a fixed signature check.  This might prevent MIOS or boot2 from being modified (if you’re using the new BC) — but more likely, it means that new Wiis coming out of the factory have a fixed boot1 without the signature-checking bug.  I’m surprised it’s taken this long, but I guess we won’t know until someone dumps their NAND flash.

 

Tags: Wii

63 responses so far ↓

  • 1 xt5 // Jun 22, 2008 at 12:27 am

    yeah, korean disks uses distintc common key than the rest of regions, but the method to generate the titlekey is exactly the same (yet unknown)..

    korean wiis also as the “normal” common key, when byte 1F1 of disk ticket is 1, it uses the korean key, when it is 0 uses the normal one.

    boot2 and IOS reamaing exactly the same, so the changes must be done in the system menu.

    I don’t have a korean wii yet, but I’ve heard that has the gamecube mode disabled so use the garbage for only prevent tweezer attack maybe is not the goal and they are thinking of a more hardcore attack :o

  • 2 Dasda // Jun 22, 2008 at 2:03 am

    Can’t you guys just dump the memory using a chip instead of from gamecube mode? This might be a lot more work (and more risky), but it only needs to be done once or twice.

  • 3 tmbinc // Jun 22, 2008 at 2:12 am

    We could just decrypt boot1, unless they have a new maskrom with a new boot0 key. Of course they could be clever and have moved the common key out of boot1, and get it from the OTP, like it should be done since day 1.

  • 4 _bla_ // Jun 22, 2008 at 2:26 am

    Couldn’t they just get a new key into old Wiis with a update? Sure, people could decode that update and find the key, but if hidden well, it should gain them some time?

  • 5 Speggy // Jun 22, 2008 at 2:38 am

    we all beleive you can crack this, so good luck :D

  • 6 skawo96 // Jun 22, 2008 at 3:17 am

    He can do everything :)

  • 7 Mithos // Jun 22, 2008 at 5:01 am

    Maybe its to close all flaws, in preparation for Wii 2/Wii HD ?

    So they can use the same “system” for it, but with “all” flaws closed up, and changed keys etc.

  • 8 bushing // Jun 22, 2008 at 5:26 am

    If I had to guess I’d say that the way they are doing this is they are some how deciding between a key stored in OTP (let’s call it the “Korea Key”) and the common key stored in IOS. Normal Wiis have the same common key stored in both places.

    They can’t update old Wiis with a new key, for two reasons:
    1) If they distribute a new key, we can disassemble the update and retrieve the key
    2) You can’t modify OTP. Ever. Once it leaves the factory, you’re done. (Otherwise, they’d be able to fix boot1, also)

    @tmbinc: This means they probably “were clever”. But you never know.

    @Mithos: This is possible.

    @Anyone: If you want to throw a Korean Wii my way, I wouldn’t refuse it. ;)

  • 9 GameZelda // Jun 22, 2008 at 5:36 am

    Wouldn’t the memset() of 0xCAFEBABE be just filling it with 0xCA? According to memset() at cplusplus.com:

    “The value is passed as an int, but the function fills the block of memory using the unsigned char conversion of this value.”

  • 10 9th_Sage // Jun 22, 2008 at 6:32 am

    I hope they don’t change the crypt keys…I like being able to dump my own discs and extract the music from them. :P

  • 11 Me // Jun 22, 2008 at 6:50 am

    I have virgin(not powered up) pal wii mobo. Sb interested?

    @9th_Sage: i wanted extract the music from dvd but failed. Any tips?

  • 12 Louise // Jun 22, 2008 at 7:19 am

    Rumor: New Wii D2E drive in existance
    http://www.maxconsole.net/?mode=news&newsid=28737

  • 13 Smalls // Jun 22, 2008 at 7:56 am

    So they are gonna try a stunt Sony did with the PSP?

  • 14 Jan // Jun 22, 2008 at 8:16 am

    AWESOME job you guys!

  • 15 Grey Acumen // Jun 22, 2008 at 8:56 am

    I’ve been following homebrew as closely as I can ever since the Homebrew Channel was officially released, so I’m still fairly new to the whole scene.

    I’m quite skilled at reading programming languages (particularly with C++ and Java, and any similar languages, or those similar to Visual Basic) so I’ve been very curious at what methods are being use to convert the original code into what looks like C++ script.
    If I could figure that out, it would be a huge leap for being able to follow everything that’s going on with all of this.

  • 16 HiTsu // Jun 22, 2008 at 9:20 am

    @Grey Acumen

    The Answer to your question is IDA Pro
    >> http://www.hex-rays.com/idapro/ <<

    Go grab it and teach yourself some reverse skills
    :-D

  • 17 miom // Jun 22, 2008 at 10:48 am

    Can’t you detect and bypass this with the fpga?
    Might slow down everything, but if you have enough patience you can extract the changed key again.

  • 18 houseonfire // Jun 22, 2008 at 11:45 am

    I could dump my Nand flash is its any help.
    I have a US Console.

  • 19 Zwartbaard » Blog Archive » Nintendo Fighting Back? // Jun 22, 2008 at 12:00 pm

    […] the full post Putting the genie back into bottle? (MIOS) for more […]

  • 20 sponge // Jun 22, 2008 at 12:27 pm

    Hasn’t Nintendo traditionally changed their consoles for the Korean versions? I know the DS was different because of font issues, but it seems like something they’ve always done to stop piracy/importing in the Korean market.

  • 21 PimpKittah // Jun 22, 2008 at 2:26 pm

    “bushing // Jun 22, 2008 at 5:26 am” the OTP is a read only chip but like Cellphones you could in (theory atleast on the wii for now…) rewrite the bios code to read the data from loc X instead of the OTP, this hack have been used on SonyEricsson phones too bypass the authentication process and YES they use RSA encrypted firmwares that have been decrypted using bruteforce and supercomputers + security issues on the chips

  • 22 Enze // Jun 22, 2008 at 3:03 pm

    miom: My understanding is that they can’t change the key. That would involve an update to be downloaded – and said update could just be disassembled for the new key.

  • 23 tona // Jun 22, 2008 at 9:56 pm

    Could you possibly short the lines to make it write the garbage to somewhere else, so then it COULD check the hash and verify it, and still leave the original MEM2 intact?

  • 24 Nuke // Jun 22, 2008 at 10:09 pm

    If the asian region Wii’s store a the normal common key to boot USA / PAL / JAP regions games. Then they are relying on the drive for the only copy protection, but this hasn’t even been changed as people have reported playing imports with modchips.

    Do they really care more about unlicensed software than game piracy?

    Importing JAP and USA consoles to these regions is not forbidden and the price of the korean wii seems the same price as usa model?

  • 25 Nuke // Jun 22, 2008 at 10:19 pm

    XT5: There are no Gamecube games for these new regions, which is more the reason.

    One guess to all of this, is that Asia region games are going to be much cheaper in price, so they don’t want USA, Europe / Jap playing importing and selling them due to price structure. The other way around they probably don’t care.

    I’ve seen this before as the Chinese model of PS2 had its own protection from other regions it even had its own custom format which is unplayable on others.

    I am trying to get my hands on a Taiwan model, but was told the end of the month but still not out here.

  • 26 Enze // Jun 22, 2008 at 10:27 pm

    tona: bushing has already said that the hack was a one-time thing. We’ve gotten all the information from it that we need.

    The fact that they patched it now, even though it has served its purpose, is very suspicious.

  • 27 Phredreeke // Jun 23, 2008 at 3:31 am

    the OTP is a read only chip but like Cellphones you could in (theory atleast on the wii for now…) rewrite the bios code to read the data from loc X instead of the OTP,

    Nope, because the Wii doesn’t boot from flash, it boots from a small rom on the Starlet chip.

  • 28 Anonymous coward // Jun 23, 2008 at 5:10 am

    Enze:

    Maybe the key can’t be part of the future update as it could be disassembled, but a future update could do something like connect to Nintendo’s servers and download the key through SSL. There are still some unknown keys on the Wii.

    A future update could also change the way later updates are downloaded so the key could come as part of a later update in a format which can’t be disassembled.

  • 29 linkinworm // Jun 23, 2008 at 6:51 am

    do you need a NAND dump of a new wii with the fix already in place or an updated wii? id be happy do send mind over i used waninkokos tool to do it and its about 312MB in size and decrypted i think. everything is in its respected folder.

  • 30 superdave // Jun 23, 2008 at 7:32 am

    In theory, one could redirect the overwriting/hash checking stuff to a different area of the RAM, leaving most of the MEM2 untouched. However, the timing would be pretty critical (and the FPGA logic pretty hairy), you’d probably need an FPGA with a pretty hefty drive to override the lines, and there’s probably no point to it anyway unless something interesting (like a new key) pops up.

    Nintendo can’t very well change the common key without permanently disabling many Wii games; if they were to issue a new key for new games only, it would force a lot of people to update their Wiis to play new games, which would probably open them up to lawsuits from people who can’t for whatever reason (no wireless or other internet connectivity, etc).

    It looks like they’re going back and just cleaning up their shoddy initial code, making it do exactly what it should have done in the first place. I wouldn’t criticize them for it; they deserve to save a little face after leaving all those keys around in memory where anyone can look at ‘em with a little clever hardware hackery (and also using a string compare on the hashes, which is a very special brand of brain-dead).

  • 31 linkinworm // Jun 23, 2008 at 7:46 am

    superdave:

    well new games always contain updates of the newest firmware im sure that on the pal release of SSBB there will be the V3.3 update on the disk

  • 32 Shin // Jun 23, 2008 at 7:53 am

    I think Nuke is right.
    plus, nintendo might be searching for a way to produce hacking-free Wiis, maybe because they want to release a chinese version at some point.

    A friend who is working with the nintendo SDK told me there were Wii OS languages in the SDK that weren’t yet implemented, like Chinese for instance.

  • 33 PimpKittah // Jun 23, 2008 at 10:02 am

    @Phredreeke

    like most other xPU’s the starlet probably supports an alternative boot location using “bootstrap” ? not sure not seen the diagram for it. but it will most certain require some serious hardware modification. and on that hand in kinda wondering why i havent seen a FPGA resolder mod for “debuging” the memoryes / starlet during runtime.. all “hackers” bad on soldering? ;)

  • 34 bushing // Jun 23, 2008 at 2:27 pm

    @superdave: Yes, I agree that they may just be going back and cleaning up past mistakes — however, it seems like they have more pressing matters to attend to (like patching the other versions of IOS). They *could* change the common key for new systems if they don’t intend them to be compatible with current Wiis — this would work well for releasing the Wii in a new region.

    @PimpKittah: I see no reason to believe that the Starlet supports strapping to boot from external memory — this would defeat its purpose as a secure processor. Remember that this processor was designed from the beginning to implement security for the whole Wii. (Similarly, there is no diagram that we can get access to.)

    It is not feasible to tap DDR3 memory using an FPGA; the signals go by too quickly. Besides, most of the interesting stuff now happens in the 128K SRAM built into the Starlet.

  • 35 bushing // Jun 23, 2008 at 2:28 pm

    @linkinworm: no, thanks. We understand how the update works. What we don’t understand is why there are doing it.

    Still, if anyone has a NAND flash dump of a Wii that has never been booted, I’d love to see that.

  • 36 shazy // Jun 23, 2008 at 3:10 pm

    interesting stuff

    keep up the good work guys

    is there anyway to donate to you guys so you can buy that korean wii

  • 37 shazy // Jun 23, 2008 at 3:10 pm

    interesting stuff

    keep up the good work guys

    is there anyway to donate to you guys so you can buy that korean wii

  • 38 Crah // Jun 23, 2008 at 4:28 pm

    Its possible that the businessmen who are in charge told them to make these changes and there staff were just obliging them.

  • 39 tona // Jun 23, 2008 at 10:58 pm

    ^^^ Yeah that’s actually what I’m betting on.

    “I want you to fix the bugs that these guys are exploiting.”
    “Well sir that’s not going to stop them necessarily…”
    “I don’t care. I want to send them a message.”
    “And what message would that be, sir?”
    “‘We’re gonna fix the bugs you find!'”

  • 40 Kurøsan // Jun 23, 2008 at 11:09 pm

    @ Crah

    You don’t just randomly decide to make a change like that without any reasons. Whoever decided to do that had something in mind, be it simply fixing past mistakes or not.

  • 41 bushing // Jun 24, 2008 at 12:48 am

    It’s entirely possible that that is the reason — “we will fix all the bugs that people find”. (So there may be a reason — just not a very good one…)

  • 42 skawo96 // Jun 24, 2008 at 1:12 am

    ^Yeah, not matter what they do, there is another mistake, or they’ll make one. And then you and co. will patch it….and someone must give up someday.

  • 43 Iblis // Jun 24, 2008 at 9:24 am

    It means they are going to roll out something new which they don’t want compromised. What that might be is a very good question.

  • 44 seac // Jun 24, 2008 at 2:22 pm

    Maybe it has something to do with the storage solution Nintendo is working on

  • 45 dr // Jun 24, 2008 at 2:56 pm

    bushing, when you say “a NAND flash dump of a Wii that has never been booted” do you mean brand new, off the shelf, or even before that? I suspect that any Wii being sold has at least been booted to run a diagnostic.

  • 46 Anonymous coward // Jun 24, 2008 at 11:36 pm

    It might be easier to fix the code on the Western Wiis even though the keys are known than it is to maintain two different versions (Western and Asian Wiis).

    If they fix the Western Wiis it also means that they get some free bug testing on those fixes (by bushing etc…) before launching in the Chinese market.

    Alternatively, the storage solution might use a new unknown key to store channels and data. They might not be able to put the genie back in the bottle but they don’t want to let another genie out either.

  • 47 Kurøsan // Jun 25, 2008 at 12:56 am

    @ Anonymous Coward

    I like that last part; sounds very plausible.

  • 48 bushing // Jun 25, 2008 at 3:19 am

    @dr: Brand new, off the shelf. *After* the diagnostic has been run. ;)

    @seac, anon: Care to elaborate on how a new storage solution might involve a new key? (and how that key would be made available to existing Wiis)

  • 49 Atacama // Jun 25, 2008 at 8:37 am

    @bushing: http://kotaku.com/5017088/nintendo-were-working-on-a-wii-storage-solution

    Doesn’t really give any idication of well anything really apart from they’re working on it.

  • 50 ChipD // Jun 25, 2008 at 11:13 am

    @ dr

    Brand new, off the shelf, and never been plugged into a power outlet.
    So in order to get the dump he needs, you need to remove the nand and dump it externally.

  • 51 seac // Jun 25, 2008 at 1:24 pm

    I think we need to know more about the storage solution. If it is a removeable device where you can store complete games on and run these games directly from the storage, then Nintendo doesn’t want you to take this storage to your friends and play the games from Wii A on Wii B. They want to pair the storage with the specific Wii.
    If this storage is paired, the Wii can be updated in some way if the update is added to the storage by Nintendo before shipping it.

    But we don’t know what the storage solution will be, they say it will not be a harddrive. A harddrive can be put in a PC…..
    So it can be a device with a home made interface (USB, an SDcard extension, maybe they use a GC port or wireless….)

    Maybe part of the pairing process is to generate a key that uses the key in the Wii as CA. Can that be done? Does the current Self Signed key contains a Cert from Nintendo as a CA? The key in the Wii can then be an intermediate CA for the external storage… then the games on the store can only be read by the Wii.

  • 52 PimpKittah // Jun 25, 2008 at 1:57 pm

    @bushing

    well since ddr3 are really fast.. cant this be “fixed” by tamering with the oscillator to make the Starlet operate att slower speeds or does the starlet have an built in oscillator ? my guess is that a realtime tap would be hard to follow but a recording of some taps would probably helt in understanding whats going on, or am i way far off into the fog? :P

  • 53 linkinworm // Jun 25, 2008 at 7:10 pm

    @seac

    well it could be that nintendo just let you use your SD card because when you copy the game over to the sd card it gets signed by your wiis key so that it cant be used on another wii, so nintendo would only have to patch the system to read games from the SD card on the menu aswell as the NAND, you wouldnt need a new key aswell then. im sure people would be to bothered about useing a few SD cards to store games. i only have about 1GB worth of games and i have about 40 of them. i cant see them letting you stream from your PC it would be to complicated on there end, and for the average user

  • 54 Anonymous coward // Jun 26, 2008 at 4:59 am

    It depends if it’s proprietary or not. The problem is nobody knows what it is.

    If it’s not proprietary it can’t store a key or firmware upgrade on the device itself and as it stands both the SD card slot and the USB ports are very slow and limiting for storage. Are we sure that the SD card slot is limited by hardware to 2Gb and the USB port is limited by hardware to 1.1 or can this be fixed with a system software upgrade?

    If it’s proprietary then it could carry some firmware upgrade or key on the device itself which could be read by the Wii.

    If the device is large enough to store an ISO, Nintendo may also want a new key in an effort to prevent ISO loaders.

    They’ve also stated that it won’t be a hard drive. So this means one of the following…

    a) It’s proprietary and therefore could contain some firmware or a key or both which can be read by the Wii on connecting for the first time, pairing the device to that Wii.

    B) It’s an SD card which is currently limited to 2Gb unless this can be fixed with a firmware upgrade.

    c) It’s a USB mass storage device with support for hard drives deliberately removed (or possibly with an artificial upper limit for storage, e.g. assuming that everything larger than e.g. 8Gb is a hard drive).

    For options b) and c) it may require formatting to a non-FAT filesystem first, a filesystem which may be encrypted with a new key.

    Streaming by wifi could be done via SMB but it adds a whole new support nightmare for routers, networking, etc…

    These are just ideas, until we know more we can only guess.

  • 55 bushing // Jun 27, 2008 at 7:07 am

    I don’t think that the new common key / MIOS / whatever is related to the alledged future “storage solution”. It’s a red herring.

  • 56 Kieran // Jun 28, 2008 at 11:04 pm

    @ linkinworm

    I just got the PAL version of SSBB; it didn’t make me update anything (I have whatever is the version before 3.3).

  • 57 Anonymous // Jul 1, 2008 at 12:33 pm

    @Kieran: Well, i live in Europe, got SSBB, and did have to update.

  • 58 etc // Jul 1, 2008 at 4:26 pm

    […] Wii:  We believe that the new Korean Wiis have a new common key, and we won’t be able to use our tweezer attack to recover it.  I’d like to take a look at one and see what other avenues of attack there […]

  • 59 Hatchhaker // Jul 9, 2008 at 10:27 am

    So, to sum up there’s a bunch of possible reasons for this update:

    1) if the keys for Korean wiis are different, that could stop them from getting the keys or at least for them to spread,
    2) having two keys, one for old games and one for new games,
    3) so that versions for future regions use a different key,
    4) hoping that the keys are not widespread enough as to get “popular” (last time I checked I couldn’t find them online), so they eventually “die” after some time and noone else can retrieve them again,
    5) as a message to hackers that they’re covering the holes,
    6) it’s a security bug anyway; fixing it makes no harm and leaving it open is slightly more risky.

    #46’s points sound fairly valid to me as well (not to maintain two separate versions, plus the possible new storage).

    Now that I’m here, out of curiousity, can’t an OTP be totally zeroed (or “oned”) out? If they are like fuses, which is the concept I have of an OTP, that should be possible (without any possibility to roll back, of course.)

  • 60 andoba // Jul 10, 2008 at 1:57 am

    Well, I have no idea about how does the Wii work, but after reading this post, my thoughts are that all the bug exploiting – bug fixing game that hackers and Nintendo are playing, could be a sandbox for releasing in China a hackfree iQue Wii, as said before.

    China is a very, very potential market, many potential users if launched at the right price. Also there is a huge problem with piracy, you can buy pirate iQue DS games which are inside GBA carts; I have no idea about how do they do it, but chinese have a huge industry into piracying and possibly Nintendo want a firm ground before launching it.

  • 61 bushing // Jul 10, 2008 at 4:58 am

    @Hatchhaker: Thanks for the nice summary. As for the OTP — we don’t know exactly how it’s implemented, but from the boot0 code it appears that it starts out as all zeroes and is selectively flipped to ones (so, like fuses, and opposite of PROM). If we could flip them all to zeroes, we could change boot1 as much as we want; if we flip them all to ones, I believe the device would become unusable. Nobody’s actually tested to see if it’s possible to modify that memory; feel free to be the first. :)

    @andoba: I agree that the Chinese market is probably very tempting for Nintendo, and would also be a huge piracy concern. Unfortunately, I don’t think that changing the common key will really help anything, but … oh well.

  • 62 Korean Wii // Sep 13, 2008 at 3:17 pm

    […] xt5 astutely noted, there is a field in the ticket structure — byte 0×1f1 — that is set to 1 in […]

  • 63 shuffle2 // Jun 18, 2010 at 10:41 am

    The link to the wiimpersonator log needs to have the region dir added to the url :)

You must log in to post a comment.