GAMECUBE ROM

ROM chip

I wanted to create my own gamecube rom sniffer so I could dump the gamecube rom and at some point in the future replace the gamecube OS with a small application that I may write. So after doing some research (google this google that) I found that the ROM resides within U10 on the gamecubes main pcb (top side). This chip has the following pinout

I also found out that the rom chip (U10) transfers the data to the CPU at startup via a SPI protocol where pin SI (serial in) is used to transfer commands from the CPU (the master) to the rom chip (the slave). Data is then transferred from the SO (serial out) pin of the rom chip (slave) back to the CPU (master).   

The data transmitted from the rom chips S0 pin at start up is the encrypted bios / rom, this data is decrypted by the gamecube on the fly and is used to setup the gamecubes hardware and display the gamecubes startup menu. The bios is xor'ed with a random bit stream produced from a prng (pseudo random number generator) which is non repeating (but is constant ie the same every boot). This should make it very secure as the key (random bit stream) is non repeating and is as long as the data (bios). however the chip that does the decrypting (the flipper) before passing the data to the CPU has a nasty bug.

To transmit information via SPI one bit is clocked out on the SI line whilst a second bit is received on the SO line, this has to happen as the SPI protocol uses two shift registers configured as a circler buffer as shown below.

This means to receive any data on the SO line something must be clocked out onto the SI line. Normally after sending the command out on the SI line dummy bits are applied to the SI line and clocked out so the master can receive the data on the SO it requested. Normally these dummy bits our all low or all high (but they can be random), however it was found out by a guy called tmbinc that the dummy bits in the gamecubes case are the decrypted bits of the BIOS!

So by simply sniffing the SO line of rom chip we get the encrypted version of the BIOS and then by sniffing the SI of the of the rom chip we get the decrypted version of the bios (thanks to the hardware bug within the decrypting chip (the flipper)). This is bad however it gets worse as the encryption is XOR based it is open to plain text attacks, to get the encryption key. If we can get the encryption key we can encrypt our own bios / rom and replace the current gamecube startup software.

XOR Plain text attack

The easiest way to explain xor plain text attacks is with an example, lets say we have a message P and a key K and we XOR them together to make the ciphertext C as shown below.

P = HELLOYOU

K = PASSWORD

C = HELLOYOU xor PASSWORD = 0x18041F1F18161D11

You can think of the xor as an add function its effectively added together P + K to make C. Now the problem is if someone knows any of the plaintext they can simple xor it with ciphertext (which is effectively a subtraction) to get the key K. Lets say someone knows the first part of P, HELLO they can obtain part of K as shown below.

P = HELLO

C = 0x18041F1F

K = HELLO xor 0x18041F1F = PASSW

with this knowledge an attacker can guess the other part of the key (K) and obtain all the plain text or re-encrypt part of the message (P) with his own letters.

In the case of the gamecube we can get the plaintext P from sniffing the rom chips SI line and get the ciphertext C by sniffing the SO line, therefore we can get the key K by xoring P with C. Then we can encrypt our own message with the found key K and use this new encrypted message to take control of the gamecube.

Gamecube rom dumper    

To obtain the key K I first had to build some hardware to dump data on lines SI (plain text) and SO (ciphertext). I needed some why to read the SPI comms a byte at a time and send it to my PC without missing any data. As the SPI clock speed is quite fast (30Mhz) that ruled out low cost micro processors microchip / atmel etc. A guy called tmbinc used a CPLD to make the SPI data parallel and then supplied this data to a high speed parallel port of a cypress micro controller. Which in turn read the data on its parallel port and transferred it via USB to a PC, this looked like a good solution to the problem so I thought I would give it a go. I used the following development board to create my gamecube rom dumper.

1) Lcsoft CY7C68013A Mini Board (cypress FX2LP) which I found on ebay for £10, used to transfer data to PC.

2) A Xilinx XC9572XL CPLD on a cool runner 2 development board (development kit was £60 from farnell) 

 

CPLD hardware

I configured the CPLD  (here's the VHDL code) to have two shift registers which clock data in on the positive edge of the clock (this is the edge rom chip uses) one was connected to SI and one connected to the SO. As soon as the gamecube starts up these  take data from the gamecubes rom SI and SO lines and convert it to a parallel data stream, 8bits for the SI line and 8 bits for the S0 line. 

Cypress hardware

I then configured the CY7C68013A to used as slave FIFO device this basically means it will take the information on its 16 bit parallel FIFO bus and transfer it to a internal fifo (4kb * 4 (quad buffered)) for automatic USB transmission to a PC whenever the fifo write line is toggled. As the internal 8051 core is not used this transfer configuration is fast, and can easily cope with the 3662kbytes a second coming out of the CPLD. Here's the code I used to configure the cypress device.    

Putting it all together

Here is a schematic of how I put the gamecube / CPLD / cypress hardware together to create my rom dumper and picture to go with it.

*Note: Used a 10k pull down to ground to stop this line floating when not driven

PC Dumping software                     

Now that I had the hardware to transfer the rom data to pc via usb I needed to create a pc application to capture this data. Luckly cypress provided a demo application (AN63620) written in c# that I could easily modify to capture the usb data. Here is the modified demo application you will need to compile it (use c# express 2010) basically you

and hopefully the software / hardware should produce a file that contains the data sniffed on the SI / SO lines of the rom chip (U10). Note I haven't tested this program fully I think it will crash if you try and dump the rom without selecting a file to download it to. Please follow the above steps in the order written.

Splitting up the dumped image

The image captured is of both the decrypted bios (SI line) and encrypted bios (SO line) combined therefore this image needs to be split up to be of any use. This simple command line application splits the dumped image into three files

To use the application type bl2_spliter followed by the name of the file that holds the dumped image.