Best of Wii hacking

Twiizer attack

RSA with strncmp

the Homebrew Channel

Something is odd with the Espresso

• It won't boot code the "old" way (e.g. using BootMii).
• The System Menu is encrypted.
• There are two new encrypted binaries: 1-512 and 1-513.

The Espresso will only boot encrypted and signed code!

That means there is a special Boot ROM inside the Espresso too.

We call the new encrypted images "Ancast* images".

* Because the princess is always in another castle.

Modified vWii IOS PowerPC bootstrap

• Is the target title the System Menu?
  • Yes? Load the encrypted menu from NAND.
  • No? Load the encrypted 1-512 or 1-513 NANDLoader from NAND*.
• Bootstrap (reset) the PowerPC.


* This replaces the NANDLoader normally included with all other NAND titles.

Observing the BootROM

• The signature and hash of the image is verified before it is decrypted.
• The image is decrypted in-place from beginning to end.
• An additional instruction appears just before the entrypoint of the image.

Espresso Mode Hack

What happens when we overwrite memory from Starbuck?

• Boot ROM:
  1. Verifies ancast image.
  2. Decrypts the image.
  3. Jumps to the decrypted image.
• Code at the start of the image puts the Espresso into Broadway compatibility mode.

There's a lot of time between 2 and 3!

Espresso Mode Hack

1. Wait until the first instruction has been decrypted.
2. Overwrite the decrypted instruction with our own code.

The first block is not verified again by the ROM. Classic ToC/ToU.

Result: Espresso executes our unsigned code before Broadway compatibility mode is enabled.

In Espresso mode, you can start all three PPC cores!

Design flaw!

This is a major design flaw. It's not even an exploit.

We can also use the ROM as an oracle to decrypt binaries.

This renders the Boot ROM mostly pointless.

The only thing we can't do is decrypt Wii U binaries in vWii mode.

But it's no fun if we stop here.

Hacking toolkit

Rebooting to test code every time is painful.
We like experimenting interactively.

Solution: run a remote agent on the console that is controlled by RPC commands from a Python script running on a PC*.

How do we communicate?
We used the Memory Card ports on the Wii, but those are gone now.

* We did this in the past for the Wii, the PS3, and others.

Solution #1: LOLserial

STDOUT only, up to 115kbaud, simple. Good enough for printf()...

Solution #2: Ghettohci

I/O, up to 115kbaud, slow. No need to open console.

Solution #3: GPIOGecko

I/O, faster, warranty void.

Boot ROM walkthrough

The SRESET hack

What happens if we assert SRESET while the Boot ROM is running?

What if we apply SRESET later in the Boot ROM execution?

Success!

Boot ROM dumped.

8 Days: 3d331b3165f9638c6cd6221702b2f736f7fcf931

But it's too late to get the keys...

What about HRESET?

HRESET resets the whole Espresso, and restarts Boot ROM execution. HRESET is level sensitive: hold it low to reset the chip, then release it to begin execution.

The PPC750CL datasheet says HRESET must be held low for >=255 bus clock cycles.

What happens if we try narrower pulses?

The HRESET hack

The Starbuck runs at the bus clock rate and can control HRESET with single cycle accuracy.

1. Fill ALL free memory with jumps to some dumping code.
2. Upload a snippet of ARM code to perform accurate reset sequencing.
3. Start up the PPC normally, then HRESET it in the middle of the ROM.
4. Try various HRESET widths.
5. Hope that something blows up and execution falls through to our code.
6. ???
7. Profit!

Success?

The PPC seems to be executing our code...

... but it's drunk!

• Skips some instructions.
• Sometimes doesn't issue writes to memory.
• Some functional units are probably borked.

Drunk is good enough.

1. Read each key word from OTP/fuses
2. Write it to memory 4 times
3. Then piece them together by hand...

Success!

Espresso keys dumped.

11 Days: d6356c408f36a4bf4b48abbee5bfffe91d196ee6

That's a hash of this file which contains the hashes of the two keys (vWii, Wii U), because we must go deeper.

boot0

The Wii's Starlet booted from a boot ROM ("boot0").

vWii doesn't have any boot0 (or boot1 or boot2) - it is entered from Wii U mode.

How does the Wii U mode boot? We can't find out from the vWii sandbox.

Or can we?

A blast from the past

On the Wii, boot0 is mapped to FFFF0000 on boot.

boot2 disables it by writing to a hardware register.

The register is not clear-only (it can be reenabled).

The register still exists in vWii mode (for compatibility).

What happens if we set the enable bit again?

A wild boot0 appeared! It doesn't look like the Wii boot0.

Seriously?

All your Wii U boot0 are belong to us.

14 Days: ee28d0be718055423ee79d89889ebe386e5b0c2d

The Wii U boot0 is much more interesting than the Wii boot0:

• Real RSA signature checks (not just a hash).
• Supports booting a signed recovery image from SD.

Unfortunately, we have not found any exploitable bugs in boot0 :-(

Other approaches

We don't care about Wii U software -
all we want is to access the hardware from homebrew.

Can we escape the vWii sandbox and enable Wii U hardware?

cafe2wii

The Wii U Starbuck code that switches to vWii mode.

Contains interesting low-level code.

Tells us what we have to undo.

Now that we have the keys, we can decrypt it.

Nintendo's (2012)
holiday gift

cafe2wii is an ELF executable

$ file cafe2wii.elf
a: ELF 32-bit MSB executable, ARM, version 1, statically linked, not stripped

Yes, they left the symbols in.

And full DWARF debugging info (including structures).

Strings galore

MCP_AssertResetAHBSubsystem    MCP_HWResetDeassertAHB                     C2W_AHBMemRBInvalidate
MCP_AssertResetAHM             MCP_HWResetDeassertDI2SATAandVI            C2WBin
MCP_AssertResetSupportBlocks   MCP_HWSetAHBCompatMode                     C2WBootInfo
MCP_CompatFlaSetting           MCP_HWSetCompatMemoryController            C2W_DdrReadSeqMemReg
MCP_CompatUDelay               MCP_HWSetCompatMode                        C2W_DdrWiiInit
MCP_DisableDCache              MCP_HWSetMEM1MapCompatMode                 C2W_DdrWiiReInit
MCP_DisableICache              MCP_HWSetMEM2SelfRefreshMode               C2W_DdrWriteSeqMemReg
MCP_DisableInt                 MCP_HWSetPLL                               C2W_FinalizeCafe
MCP_DisableMMU                 MCP_HWSetSATACompatSetting                 C2W_InitLomem
MCP_FlushDCache                MCP_HWSetSysProt                           C2W_LaunchWiiIOS
MCP_HWClockGating              MCP_InvalidateICache                       C2W_Memcpy128
MCP_HWClockGating_BIF          MCPLowPowerCommand                         C2W_Memmv128
MCP_HWClockUngatingGFX_VI      MCP_RVAL                                   C2W_Memset32
MCP_HWDMCUResetDeassert        << C2W_ConfigSysPllForCompat Failed!! >>   C2W_RAM_DDR_CFG
MCP_HWResetAssert              << C2W_FinalizeCafe Failed!! >>            C2W_ReadDdrCfg
MCP_HWResetAssertAHMN          [C2W:%s:%d] MEM0 Overflow                  C2W_SetEspressoPLLConfigGPIO
MCP_HWResetDeassert            C2W_AHBMemFlush                            C2W_StartPPC

Also, they use Cygwin:
/cygdrive/c/J/workspace/20605_P8_BUILD/maint_sdk_2_06_05_p8/system/src/iop/app/c2wboot

Mixed bag

The sandbox is a bit leaky. We can:

• Partially reconfigure the bus to Wii U mode.
• Half-enable the extra 8MB of MEM1 (but it breaks Starbuck).
• Mess with some Wii U GPIOs and misc. stuff.

But it's not enough.

• Most new hardware is powered off / clock gated.
• The required reset/clock regs seem to be locked off.
• Bits in SYSPROT are one-shot and can't be reset.

Nintendo could enable a homebrew sandbox with access to Wii U hardware while locking out the software and keeping their DRM safe (OtherOS style).

But we all know they're not interested.