Bottom view of disc drive.
The Wii U has an internal disc drive capable of reading both Wii discs and Wii U discs. It's believed to be somewhat related to Blu-Ray drives, in a similar fashion to the Wii's relationship with DVD. Like the Wii, the drive is slot loading and mechanically complex. The drive casing has a label indicating it was manufactured by "China Hualu Panasonic AVC Networks Co., Ltd.".
SATA
The drive is connected to the Wii U via a normal SATA controller, using AHCI 1.2. The IOSU may communicate with the controller (and, by extension, the drive). The drive identifies as a standard SATAPI disk drive, connected to port 0. In vWii mode, the AHCI controller is placed into a special compatibility mode, which causes it to emulate the Wii's DI and provide accurate backwards-compatibility for Wii software.
SCSI Commands
Despite using normal SATAPI formatting for its commands (ATA PACKET, etc.), the Wii U disc drive doesn't appear to implement any of the required SCSI commands except for REQUEST SENSE. Instead, an entirely custom set of commands is used. All CDBs appear to be 12 bytes long.
0xDA - ATAPI_DI_READ_DISC_INFORMATION_CMD
0xE0 - ATAPI_DI_REQUEST_ERROR_ID_CMD
0xED - ATAPI_DI_READ_CBC_CMD
0xF1 - ATAPI_CF_AUTHENTICATE_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf1
|
Opcode
|
| 1
|
0, 1, 2, 3
|
Step (See #Authentication)
|
| 2-11
|
0
|
Padding
|
| Sends or receives 32 bytes depending on stage (See #Authentication)
|
0xF2 - ATAPI_CF_START_STOP_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf2
|
Opcode
|
| 1
|
0, 2, 4, 6, 8, 0xe, 0x16
|
Subcommand (see below)
|
| 2-11
|
0
|
Padding
|
| Subcommands
|
| 0
|
Stop unit
|
| 2
|
Awake motor (required for read)
|
| 4
|
Eject
|
| 6
|
Stop unit(?)
|
| 8
|
Unknown
|
| 0xe
|
Load disc
|
| 0x16
|
Run cleaning disc
|
0xF3 - ATAPI_CF_READ_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf3
|
Opcode
|
| 1
|
0, 1, 2, 3
|
Subcode (see below)
|
| 2
|
0
|
"cacheLineIndex" (?)
|
| 3-5
|
0
|
Padding
|
| 6-7
|
0-0xFFFF
|
LBA (Block number)
|
| 8-11
|
0-0xFFFFFFFF
|
Block count
|
| Subcodes (retail)
|
| 0
|
Main WUD (0x800 block size)
|
| 1
|
Media titlekey
|
| 2
|
Disc serial
|
| 3
|
Unknown
|
| Response data is encrypted with session key
|
0xF4 - ATAPI_CF_TEST_UNIT_READY_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf4
|
Opcode
|
| 1-11
|
0
|
Padding
|
| Command seems to only communicate via error sense codes
|
0xF5 - ATAPI_CF_INQUIRY_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf5
|
Opcode
|
| 1-11
|
0
|
Padding
|
| Returns a small struct (see below)
|
| IDENTIFY data
|
| Offset
|
Size
|
Description
|
| 0x00
|
0x02
|
Unknown
|
| 0x02
|
0x01
|
Vendor
|
| 0x03
|
0x01
|
Device
|
| 0x04
|
0x1C
|
Unknown
|
| 0x20
|
-
|
End
|
0xF6 - Unknown ATAPI_CF command
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xf6
|
Opcode
|
| 1
|
1 or 2
|
Unknown
|
| 2-11
|
0
|
Padding
|
| Checks for dev/retail discs?
|
0xFB - ATAPI_CF_FREC_READ_CMD
| CDB Description
|
| CDB Offset
|
Values
|
Description
|
| 0
|
0xfb
|
Opcode
|
| 1
|
0, 2, 0x12
|
Subcommand(?)
|
| 2-3
|
0
|
Padding
|
| 4-11
|
0
|
Must sum to 8 or less (subcommand 2 or 0x12 only). IOSU sets byte 4 to 8
|
| 0x20000 bytes response data, encrypted with session key
|
Authentication
The disc drive uses a two-stage authentication handshake, first a simple CBC-MAC challenge-response authentication so the console can prove it possesses the correct drive key, and then a function to derive a shared session key. The session key is used to decrypt some response data from the drive, using AES-128-CBC with a null IV.
Stage 1: CBC-MAC drive key proof
- First, the console requests a challenge from the drive by sending the Authenticate command with a step of 0. The drive responds with 32 random bytes.
- The console then encrypts these bytes using AES-128-CBC and the console drive key, null IV.
- The console takes the second 16-byte block, which is the CBC-MAC code and appends 16 null bytes.
- The console sends this 32 byte packet to the drive using the Authenticate command with a step of 1.
Stage 2: Session key derivation
- The console requests the drive's contribution to the session key by sending the Authenticate command with a step of 2. The drive responds with a 32-byte packet - 16 random bytes, then 16 "ee" bytes. If the drive is unhappy with the console's CBC-MAC proof from stage 1, it will instead give a SCSI error.
- The console extracts the 16 random bytes, discarding the "ee"s.
- The console generates 16 random bytes of its own. After verifying these are different to the drive's, it sends them to the drive (along with 16 padding nullbytes) using the Authenticate command with a step of 3.
- The console encrypts both the drive's random bytes and its own random bytes using AES-128-CBC, null IV and the console drive key.
- The console XORs these encrypted sets of bytes together. The result is the 16-bit AES-128 session key.
Cabling
The Wii U disc drive cable, viewed from the underside. Note the joined pins and extra tabs on the right.
Physically, the drive is connected with a custom 50mm ribbon cable, containing 28 pins at a 0.5mm pitch. The cable is non-standard - some pins are joined together, while others are disconnected. Notably, the cable is not symmetrical, which makes it vitally important that it is not put in backwards - the end with the extra tabs should connect to the disc drive, while the brown side of the cable should face away from the board underneath on both the motherboard and drive ends. The connectors on both the drive and console side have labels for the pin numbers, but they disagree on which pin is pin 1! 1 connects to 28, 2 to 27, and so on. The cable's pinout, when viewed from the drive end, black facing up, pin numbers as shown in the image, is as follows:
Numbering guide to interpret pinout table. Note the tabs - this is the drive end of the cable.
| Drive Cable Pinout
|
| Pin
|
Function
|
| 1
|
12v (1.8A)
|
| 2
|
| 3
|
| 4
|
NC
|
| 5
|
GND
|
| 6
|
| 7
|
NC
|
| 8
|
5v (1.0A)
|
| 9
|
| 10
|
| 11
|
NC
|
| 12
|
GND
|
| 13
|
| 14
|
3.3v (0.5A)
|
| 15
|
| 16
|
GND
|
| 17
|
Disc inserted (3.3v from drive = no disc)
|
| 18
|
Disc eject command (3.3v pulse from console to eject)
|
| 19
|
Disc presence sensor (IR emitter)
|
| 20
|
Disc presence sensor (IR receiver, only when powered off)
|
| 21
|
3.3V Always-On
|
| 22
|
GND
|
| 23
|
SATA A+
|
| 24
|
SATA A-
|
| 25
|
GND
|
| 26
|
SATA B-
|
| 27
|
SATA B+
|
| 28
|
GND
|
Motherboard
VXX72132
Chip Listing:
| Color
|
Chip Name
|
Datasheet
|
Notes
|
| Red
|
"C211NP9" "207P708J"
|
|
Some boards come with a "C212NR9" "235P30GJ" instead
|
| Yellow
|
"41226" "209C6200"
|
|
Motor Driver IC?
|
| Orange
|
"WBA" "121"
|
|
|
| Blue
|
ST "408WP" "8117"
|
Datasheet
|
1 Kbyte I²C SEEPROM
|
| Black
|
ESMT "M12L64164A- 7T" "AZM1P11M0 1119"
|
Datasheet
|
64M SDRAM
|
VXX72135
Chip Listing:
| Color
|
Chip Name
|
Datasheet
|
Notes
|
| Red
|
"C211BP1" "328P60G1"
|
|
|
| Yellow
|
"31TTI" "CD00G2" "1408G4"
|
|
Motor Driver IC?
|
| Orange
|
ST "408WP" "8318"
|
Datasheet
|
1 Kbyte I²C SEEPROM
|
| Black
|
ESMT "M12L64164A- 7T" "AZM1P237X 1301"
|
Datasheet
|
64M SDRAM
|
| Purple
|
TI "TPIC1391" "2CTG4" "AKXR"
|
|
"3-Half H-Bridge Gate-Protected Power DMOS Array"
|
VXX72137
Chip Listing:
| Color
|
Chip Name
|
Datasheet
|
Notes
|
| Red
|
"C213CP1" "532P60VA"
|
|
|
| Orange
|
"4G16" "53073"
|
Datasheet
|
2 Kbyte I²C SEEPROM
|
| Yellow
|
"55TTI" "C3TVL" "3060AG4"
|
|
Motor Driver IC?
|
See Also
Fail0verflow's Console Hacking 2013 article, specifically the "DI" section for information on vWii compatibility mode and AHCI.
