wraggster
June 22nd, 2008, 11:15
Bushing gives us more news on wii hacking:
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]={0×4F00A54E,0×57E1E2C4,0×78634365,
0xF56BA5D3,0xF7DECA52};
int i;
memset(buffer, 0xCAFEBABE, 0×8000);
memset(buffer + 0×8000, 0xCAFEBABE, 0×8000);
aes_set_key(0×2B7E1516, 0×28AED2A6, 0xABF71588, 0×09CF4F3C);
sha_init();
for (i=0; i<1024; i++) {
aes_set_iv(i, i, i, i);
aes_encrypt(MEM2_ptr, buffer, 0×10000);
sha_update(MEM2_ptr, 0×10000);
}
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.
http://hackmii.com/2008/06/genie-into-bottle-mios/
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]={0×4F00A54E,0×57E1E2C4,0×78634365,
0xF56BA5D3,0xF7DECA52};
int i;
memset(buffer, 0xCAFEBABE, 0×8000);
memset(buffer + 0×8000, 0xCAFEBABE, 0×8000);
aes_set_key(0×2B7E1516, 0×28AED2A6, 0xABF71588, 0×09CF4F3C);
sha_init();
for (i=0; i<1024; i++) {
aes_set_iv(i, i, i, i);
aes_encrypt(MEM2_ptr, buffer, 0×10000);
sha_update(MEM2_ptr, 0×10000);
}
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.
http://hackmii.com/2008/06/genie-into-bottle-mios/