The Media Board contains an FPGA which interfaces to the DI bus, i.e. replaces the DVD-ROM. However, A quick test shows that the original DVD commands don’t work. Here the modchip’ed triforce comes handy again: The qoob bios leaves the original bootrom (i.e. the triforce IPL) at 0x81300000. I could then upload my own test tool via network, patch the IPL (for example I’ve redirected OSReport to the screen and to the USBGecko), and let it run.

After setting some “Breakpoints” at strategic places, I’ve came across some HUGE function structure, which all developed a dependency to a certain constant, 0x41C64E6D. A quick googling shows that this is just the constant of the original K&R rand() function. Some further reversing shows a more strange stuff: several high-entropy values are sent to the DI (or, almost sent - most of them are just written into the command register, not actually executed). The “read”-function, for example, writes a command which doesn’t resemble anything structured. Some further reversing shows that there is “obscurity in progress” - all DI commands are “encrypted”. Basically, there is a session key (which is sent first), which get XORed to the DI value. Then the session key gets scheduled by a simple method: It’s multiplied (modulo 2^32) with a random value, and that random value is also sent, so the key for the next command can be derived. No, it’s not secure (you can deduce the last value if you know the plaintext command, which you do), but it’s a pita.

In the phase of the initial key negotiation, a lot of junk is sent, which doesn’t serve any purpose. Between them, some “important” commands carry the key data. This somehow reminds me of how the Cobra code (for the Viper gamecube modchip) was obscured… But probably just coincidence.

I’ve defeated the code by corrupting the random function to always return zero. Then, the session key was zero, and multiplying zero with something yields… zero. XORing something with zero yields.. the plaintext. So, by corrupting the random generator, I could place the Media Board into a mode where communication was not encrypted. In fact, all you need is to send two DI commands (“01010000 00000101 00000000” and “01010000 00000000 0000ffff”), and then you have setup a zero session key.

However, DI commands are still different to the original one. For example, the “READ” command is usually a8000000, whereas here it’s “000100a8”. But knowing that was enough to just read all data from the media board, and dumping it via the USB Gecko.

Looking at the data yields something interesting: It’s a standard “GCM”, i.e. a disc image. It has an apploader, an FST and a main DOL. It’s 2MB in size, fitting the size of on-board flash memory. The DOL inside will show the fancy Triforce logo, control the loading of the GD-ROM into the DIMM Board, and will then launch that.

(Don’t worry, I have some pictures ready for you. It’s just that I currently only have GPRS internet, so uploading would take ages. Sorry, I’ll put them here later.)