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.
63 responses so far ↓
1 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.
2 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? 😛
3 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
4 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.
5 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.
6 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).
7 Anonymous // Jul 1, 2008 at 12:33 pm
@Kieran: Well, i live in Europe, got SSBB, and did have to update.
8 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 […]
9 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.)
10 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.
11 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.
12 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 […]
13 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.