Disc drive

From WiiUBrew
Jump to navigation Jump to search
Top view of disc drive.
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.".


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.





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)


CDB Description
CDB Offset Values Description
0 0xf2 Opcode
1 0, 2, 4, 6, 8, 0xe, 0x16 Subcommand (see below)
2-11 0 Padding
0 Stop unit
2 Awake motor (required for read)
4 Eject
6 Stop unit(?)
8 Unknown
0xe Load disc
0x16 Run cleaning disc


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


CDB Description
CDB Offset Values Description
0 0xf4 Opcode
1-11 0 Padding
Command seems to only communicate via error sense codes


CDB Description
CDB Offset Values Description
0 0xf5 Opcode
1-11 0 Padding
Returns a small struct (see below)
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?


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


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.


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 cable's pinout, when viewed from the drive end, black facing up, 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)
4 NC
7 NC
8 5v (1.0A)
11 NC
12 GND
14 3.3v (0.5A)
16 GND
17 Unknown
22 GND
23 SATA A+
24 SATA A-
25 GND
26 SATA B-
27 SATA B+
28 GND

See Also

Fail0verflow's Console Hacking 2013 article, specifically the "DI" section for information on vWii compatibility mode and AHCI.