@comex, @marcan42, @svenpeter42
|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.|
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 http://nus.cdn.shop.wii.com/ccs/download/0000000700000002/tmd.514 09:19:15 [title.0000000700000002] INFO: cetk already in cache 09:19:15 [title.0000000700000002] INFO: Downloading file http://nus.cdn.shop.wii.com/ccs/download/0000000700000002/0000000D 09:19:15 [title.0000000700000002] INFO: Downloading file http://nus.cdn.shop.wii.com/ccs/download/0000000700000002/0000000E 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 [...]
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.
* This replaces the NANDLoader normally included with all other NAND titles.
What happens when we overwrite memory from Starbuck?
There's a lot of time between 2 and 3!
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!
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.
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.
STDOUT only, up to 115kbaud, simple. Good enough for
I/O, up to 115kbaud, slow. No need to open console.
I/O, faster, warranty void.
+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 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.
|Addr||RAM||L2 cache||Real mode||Translated mode|
||L2 off||Not mapped|
|L2 off||Wrong mapping
|No physical memory||L2 off|
Clever tricks keep the ROM execution isolated
... but there's a hole.
PowerPC has two external reset lines:
Both are controlled by the Starbuck.
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...
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 Starbuck runs at the bus clock rate and can control HRESET with single cycle accuracy.
* The specific values vary from unit to unit
The PPC seems to be executing our code...
... but it's drunk!
Drunk is good enough.
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?
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:
Unfortunately, we have not found any exploitable bugs in boot0 :-(
The boot1 encryption key
* We're trying some cool stuff, expect to hear from us if we succeed!
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.
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).
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:
The sandbox is a bit leaky. We can:
But it's not enough.
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.