HackMii

Marcan has posted an extracted version of the HTML from the System Menu.

Some highlights:

http://marcansoft.com/transf/wiisettings/US2/ iplsetting.ash/FIX/US/ENG/index01.html

http://marcansoft.com/transf/wiisettings/US2/ iplsetting.ash/FIX/US/ENG/Setup/startup_index1.html

http://marcansoft.com/transf/wiisettings/US2/ iplsetting.ash/FIX/US/ENG/Setup/ScreenSave.html

Enjoy!

A lot of stuff has happened lately, and I haven’t written in a while.   VC piracy has (as expected) flourished, and we’re still waiting to see what form Nintendo’s reaction will take — at least, I don’t really feel like releasing any code until I see what happens.

So, I’ve stepped back and am working on another problem — well, I was sort of forced to.

Bricks as seen in the “scene” come in two forms — “full-brick” and “semi-brick”.  Both are the result of installing updated System Menus from discs that came from other regions.  (Tsk, tsk.)

A “full-brick” Wii displays an Opera error message instead of the “warning” screen when the Wii boots — it does not even check the disc drive for a disc before displaying this, meaning it is impossible to fix this using software.

A “semi-brick” Wii is similar, but it allows you to boot the system to the main menu, and play games, etc.  However, you can’t get into the Settings menu (to enable WiFi, update the software, etc), because when you do, you are presented with a similar screen to above (but I can’t find any pics online) — however, instead of ScreenSave.html, it’s Settings.html.

[Thanks to H. for the below picture:]

Let’s take a look at why this happens.  What’s this ScreenSave.html?

If you ever have the fun opportunity to select “Format System Memory” when the Wii boots up, you’ll be presented with this screen — *before* the “warning” screen:

After this screen, you are then given a few screens that ask you to select a region, a console name, and some other settings — one of which is this screen:

I don’t have a picture handy, but before you are shown this screen, you get one with a message that says “Your Wii console has a screen burn-in reduction feature. To use it, activate it in Wii Settings.”

 After you finish this series of configuration steps, it will finally show you the “warning” screen.  This is notable because this all happens before the warning screen loads.

These html files are all stored inside an archive inside the System Menu content storage.  Here’s the stupid part:

Each region has its own version of the System Menu (1-2).  For example, the newest version of the system menu available is v. 288 (NTSC/J), v.289 (NTSC/U), v.290 (PAL).  The only difference between those three versions is two different files — the main executable for the menu (a .DOL file, more or less) and an ARC archive that stores compressed versions of the HTML / image resources.

All of this is fine and good, but why put them in separately named directories? (E.g. EU/EU/GER/Setup/ScreenSave.html above)?  The path name could always be the same because there are different files for each version.

So, there’s a specific path that the graphics need to sit at.  So, you’d think they’d hard-code a pathname like that into the code, right?  No…

The code’s pretty hard to tease apart, but they seem to be trying to determine the system region from the SYSCONF file, and then building up a pathname to load like so: sprintf(filename, “html/%s2/iplsetting.ash/%s/%s/ENG/Setup/ScreenSave.html”, region, region, region).   This is so silly, because if they had hard-coded the path then the system would have booted just fine.  

The code does this in slightly different ways in several places — this has to somehow distinguish the semi-brick case from the full-brick case, although I don’t think that anyone really understands why some people end up with one and not the other.

Still, a semi-brick is better, because it will still boot discs, meaning that there is still some hope for a fix.  If you can find a game with a newer version of the system menu in its update partition, then you can run it, and it will automagically fix things.  However, this requires a wait of several months until one comes out.

A friend came and asked me if I could help him figure out how to fix a “semi-brick” Wii, manually.  All that needs to happen in this case is we need to install a newer version of the System Menu WAD.  There are a number of ways to do this, and unfortunately I picked the wrong one.

Marcan had written some test code that can manually load the System Menu, and I modified it to try to patch the System Menu enough to get into the Settings screen by correcting the pathname.  My theory was that then we could use that to have the Wii update itself using its own internal code.  This had to be safest, right?

Well, now we have:

Looks like I just bricked a Wii.  The owner was kind enough to send me the Wii so I can try to unbrick it — this is not currently possible, but I think we now know enough to do it using an external NAND flash programmer and a bunch of software which I need to write.

The bright side of this, if there is one, is that I’ve been wanting to address the “bricking problem” for a long time, and now I have a perfect test subject to work on.

More about my plan of attack in my next post.

By popular request, here’s an explanation of the different encryption keys that are used on the Wii.

AES Keys: The Wii uses 128-bit (16-byte) symmetric AES (aka AES-128-CBC) for most encryption.

• Common key (ebe42a225e8593e448d9c5457381aaf7):  This is the “shared secret” that we extracted with the Tweezer Hack.  This key is known by all Wiis, but is never used, directly, to encrypt anything.  Instead, all titles are encrypted with a random AES key; this key is then encrypted with the Common key and then stored inside a ticket. The ticket is then transmitted along with the content — on discs, it’s part of the “certificates” found before the encrypted data starts. Thus, knowing the common key allows you to decrypt most Wii content, as long as you have the right ticket.  This key is stored in the OTP area inside the Starlet ARM core inside the Hollywood package.
• SD key (ab01b9d8e1622b08afbad84dbfc2a55d): This is another shared secret — also stored on the Hollywood, but also found plenty of other places, including inside the firmware images. This key is used by the System Menu (1-2) to encrypt anything before writing it out to the SD card, and it’s used by 1-2 to decrypt anything read from the SD card. This is done mainly for the purpose of obfuscation, to keep people from examining savegames. It’s worth noting that all Wii games save their data to the internal NAND — no game supports loading or saving data directly to SD. This frees game writers from the requirement of handling this step themselves; they just write the savegame data, unencrypted and unsigned, to their title-data directory inside the NAND filesystem; the system menu then handles everything else. (The real reason for this is probably that it allowed Nintendo to make a system where they didn’t have to expose the details of this encryption — or any encryption — to their licensed game developers.) This key is also stored in OTP, and in several places in IOS (for no apparent reason).  If you’re using Segher’s tools, you may also be interested in the SD IV (216712e6aa1f689f95c5a22324dc6a98) and the MD5 blanker (0e65378199be4517ab06ec22451a5793), both of which are stored inside the 1-2 binary.
• NAND key (varies):  This AES key is used to encrypt the filesystem data on the actual NAND chip itself; it is probably randomly generated during manufacturing and is also stored in the OTP area of the Starlet.  This key is used to prevent the contents of the NAND filesystem from being read using a flash chip reader. Nintendo may or may not actually record this key anywhere, since they (theoretically) don’t need to ever use it. In fact, in some similar systems, keys like this are generated automatically by the device itself and (theoretically) never leave it — the Wii shares some design prinicples with HSMs, but it certainly doesn’t manage to be one. This is another OTP key.

RSA keys: The Wii uses RSA-based authentication in several different places.   This is fundamentally different than the AES encryption used for data-hiding, because RSA is an asymmetric cipher, meaning there are no shared secrets — nothing to be extracted from the Wii. The only RSA keys stored on the Wii are public keys, used to verify authenticity of content.

• CP: Content Protection? This key is used to sign the TMD associated with every title. The TMD contains a SHA1 hash of the contents of that title, proving that it had not been modified. My 24c3 presentation was done by injecting a new .DOL into a Lego Star Wars disc and then forging the signature on its TMD, using a flaw originally discovered by Segher. After that presentation, people eventually discovered the common key needed to decrypt update partitions, allowing others to analyze / disassemble IOS. xt5 (who I had the pleasure of meeting at 24c3) was then able to find the same flaw and implemented it in his Trucha Signer. In fact, from disassembling his code, the core part of it was almost identical to our never-released code — great minds think alike, eh?
• XS:  “Access”?  This is the key that signs tickets, which contain the title keys for individual titles.
• CA: Certification Authority:  This key signs both the XS and CP keys.
• MS: “Master?”  This key is used to sign the certificate that contains a copy of your Wii’s public ECC key.  This certificate is then appended to savegames on SD cards, so that any other Wii can verify that the key was issued by Nintendo.
• Root: This is the “grand master key”, which signs the CA key.  The public half of this can be found here.

ECC keys:  The Wii uses Elliptic Curve Cryptography in a few select places — primarily, it uses this when it signs savegames before writing them to SD card. ECC is used in ways similar to RSA, but it’s somewhat newer and much faster to run on an embedded system.

Other:  For lack of a better place to put it, there is also an HMAC key — a 20-byte value that is used in a SHA1-based HMAC of the NAND flash contents to prevent them from being tampered with. This is a commonly used scheme in embedded systems, where a device wants to “sign” something itself, for itself. There are no public vs private keys here — you need to know this value in order to verify the hash, and you need the same value to generate the hash. This isn’t appropriate for communications between two people, but is perfectly fine for letting the Wii test to see if the chip was pulled, rewritten, and resoldered.

Key storage: The public keys are stored in various places — these aren’t sensitive, so they don’t really need to be concealed (although at least one of them needs to be protected from modification, and it can then sign the others). The rest are stored in two places:

• Hollywood SEEPROM:  After meeting him at 24c3, bunnie was kind enough to decap some chips for me, including a Hollywood. One of those chips is 2kbit serial EEPROM, which stores the MS signature on the the ECC key.
• One-Time Programmable Area:  Inside the Starlet ARM core, there are a bunch of things: 

1. SHA1 hash of boot1
2. Common key
3. ECC private key
4. NAND HMAC
5. NAND AES key
6. RNG seed
7. other stuff we can’t yet decipher