Console Hacking 2013

U Fail It

@comex, @marcan42, @svenpeter42

Best of Wii hacking

Twiizer attack

RSA with strncmp

the Homebrew Channel

Wii Hardware

Wii U Hardware

Wii vs. Wii U software overview

Wii Wii U
Games run on the Broadway, on the bare metal. Runs Cafe OS, a custom multiprocess OS running on the Espresso with process isolation and memory management.
The Starlet runs IOS, a microkernel OS handling security, crypto and I/O services Similar, but IOS is larger and significantly changed (we call it IOSU).
Games and software are loaded from disc or NAND flash. RSA signatures checked at installation time, not launch time. Also includes 8 or 32GB of eMMC storage for user software. RSA signatures also checked at launch time.

The virtual Wii inside the Wii U

09:19:14 [titlelist] WARNING: TitleList: DB file lastupdate.vwii.EUR.txt does not exist. Initializing to blank list.
09:19:14 [soap] INFO: Comparing update with previous...
09:19:14 [soap] INFO: 37 added, 0 removed, 0 changed
09:19:14 [check] INFO: Update detected.
09:19:14 [check] INFO: Downloading new titles...
09:19:14 [title.0000000700000002] INFO: Dowloading all data...
09:19:14 [title.0000000700000002] INFO: Downloading file
09:19:15 [title.0000000700000002] INFO: cetk already in cache
09:19:15 [title.0000000700000002] INFO: Downloading file
09:19:15 [title.0000000700000002] INFO: Downloading file
09:19:33 [title.0000000700000002] INFO: 00000002 already in cache
09:19:33 [title.0000000700000002] INFO: 00000003 already in cache
09:19:33 [title.0000000700000002] INFO: 00000004 already in cache
09:19:33 [title.0000000700000002] INFO: 00000005 already in cache

Wii Chain of Trust

vWii Chain of Trust

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.

vWii Chain of Trust Revisited

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.

Let's dump it anyway.

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.

First dumping attempt

+000: Ancast header
+0fc: mtspr scr,r3
+100: Decrypted code

The instruction at +0fc appears to disable the Boot ROM

Can we use the same approach to overwrite the instruction at 0xfc?

No :-(
No matter how hard we try to race the ROM, the PPC always executes the original instruction...

In order to understand why this didn't work, we're going to cheat and explain how the Boot ROM works first.

Boot ROM walkthrough

Addr RAM L2 cache Real mode Translated mode
+100: Reset vector L2 off
Boot ROM (16K)
Not mapped
+000: Ancast header
+100: Ciphertext
L2 off +000: Ancast header
+100: Ciphertext
Not mapped
L2 off Wrong mapping
Junk at 00020000
No physical memory L2 off

Clever tricks keep the ROM execution isolated

... but there's a hole.


PowerPC has two external reset lines:

  • HRESET (hard reset): full chip reset
  • SRESET (soft reset): basically just a nonmaskable interrupt


Both are controlled by the Starbuck.

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?


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!


  • Short widths: PPC crashes before running anything.
  • Long widths: PPC restarts normally.
  • Various widths around the middle: Boot ROM execution fails and deadlocks.

  • But for one or two specific pulse widths*... strange things happen.

* The specific values vary from unit to unit


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...


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.

The Espresso is pwned (in vWii mode), time for the Starbuck (in Wii U mode).


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.


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 :-(

</vWii mode>

How to pwn Wii U mode

What's missing?

The boot1 encryption key

  • Used by Wii U boot0 to decrypt boot1.
  • Permanently disabled after use.
  • We haven't found any way to get at it. Yet*.

* We're trying some cool stuff, expect to hear from us if we succeed!

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?


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:

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.

Thank you