HackMii

I’ve had a few people ask about this — the way that I found out what titles had been updated was using Marcan’s nifty tool, wiimpersonator:

http://wii.marcansoft.com/wiimpersonator/reports/

It’s a collection of Python scripts that attempt to emulate an actual Wii’s update check process, and then generates reports to show what changed, eg. 20080617-030018.log and 20080617-040048.log.

It’s pretty neat; I’d say it’s the spiritual descendent of e.g. roto’s http://mozy.org/wii/old/index.html

Breaking news (har har har)!  Check back for updates.

Several pieces of Nintendo system software have been updated:

====== Titles Changed ======

SystemMenu
 Title ID: 00000001-00000002
 Version: 0x 161
 Size: 23511040
 Contents: 9 (of which 6 are shared)

IOS30
 Title ID: 00000001-0000001e
 Version: 0x a10
 Size: 1933312
 Contents: 15 (of which 14 are shared)

IOS31
 Title ID: 00000001-0000001f
 Version: 0x a10
 Size: 1933312
 Contents: 15 (of which 14 are shared)

bc
 Title ID: 00000001-00000100
 Version: 0x   4
 Size: 98304
 Contents: 2 (of which 0 are shared)

mios
 Title ID: 00000001-00000101
 Version: 0x   8
 Size: 262144
 Contents: 2 (of which 0 are shared)

Channel 'HACA'
Title ID: 00010002-48414341
 Version: 0x   5
 Size: 8290304
 Contents: 7 (of which 3 are shared)

I’m currently disassembling these to see what has changed. Please do not pester me about this or ask what our response will be; this isn’t exactly easy or quick. Comments will be enabled once i’ve completed my analysis.

Update 1: IOS30 and IOS31 have been changed — specifically, the kernel. The old timestamps read:

$IOSVersion:  FFS: 06/08/07 18:10:10 64M $
$IOSVersion:  ES: 07/10/07 18:11:26 64M $
$IOSVersion: IOSP: 06/25/07 14:17:16 64M $

The new timestamps read

$IOSVersion:  FFS: 06/08/07 18:10:10 64M $
$IOSVersion:  ES: 07/10/07 18:11:26 64M $
$IOSVersion: IOSP: 04/03/08 19:37:33 64M $

It’s interesting that Nintendo bothered to update the IOSP timestamp, because the only change I see in IOSP is that the version reported changed (there’s a variable that stores the value “040308”). They’re trying to be clever; the actual bug fix was in ES, where the encryption code lives.

The strncmp signing bug has been fixed in IOS30, which is what the system menu uses. (The new signature-checking code is identical to that in IOS37.) This probably means that it will no longer boot Trucha-signed discs, but I have not yet tried it. Early reports on IRC indicate that the Homebrew Channel still works; this is consistent with my understanding that the system menu does not verify the content of already-installed content.

I don’t know why IOS31 was patched.

Update 2: Okay, now this is just silly. Three functions have been added to the system menu. Guess what they do:

• ipl::utility::ESMisc::DeleteSavedata((unsigned long long, EGG::Heap*))
• ipl::utility::ESMisc::VerifySavedataZD((unsigned long long, EGG::Heap*))
• WADCheckSavedataZD

We Are Not Impressed.

Update 3: They wrote a special-purpose function to try to check for the exact exploit we used — specifically, if a savegame is for Zelda, it checks the length of 6 strings inside the savefile (two of which are the player name and horse name). It repeats this check for all 3 saveslots, and then another three times for all 3 backup slots.

No, we do not have a response to this yet; we will probably take a few days to formulate one. I predicted Nintendo would *not* do this; I’m disappointed. This was the first bug we found, in the first game we tried. We’ll find others, and they’ll have to try to catch up to each.

I’ll open up comments, but please only post if you have something constructive to say.

Update 4:  It’s interesting to look at the timestamps here.  The System Menu has a build marker of “systemmenu.rvl.0803060727”  — yes, that’s March 6, 2008, 07:27.  This update to the menu only accomplished one thing, as far as I can tell — the blocking of the TP hack.  (I guess we can count the IOS30 patch together with it.)  They spent 3 months testing it — this isn’t actually that surprising, when you consider the potential financial damage if they roll an update out that bricks Wiis.

Congrats to tmbinc and tehpola for finding a combination of two bugs in the code that Nintendo added that — when combined — allow us to fool their check into ignoring the TP hack.  More info will be forthcoming — I still wouldn’t rush to update my system, anyway.

This still leaves the issue of how to deal with IOS30; there are several different ways to deal with this — some of which have already been released by people — and we’ll need to take some time to decide on the best one to use and test it thoroughly.   There’s no urgency here, no need to rush into something.

Inspired by henke37’s idea of making a diagram that shows how the different processors on the Wii relate to each other, I took a stab at it.  I got a little carried away I guess.

I can’t promise everything here is right — there are just too many things we don’t know, and even some of the things we do know, we don’t all agree on.    So, here’s my first attempt at summing it all up:

You can find a nicer pdf version here.