[I’ve started writing this a few days after the last post. I was still waiting for some things to develop, but I’m a bit out reach at the moment, so this might take some time. So this post isn’t as finished as I hoped it it would be. But these “news” already started to smell funny.]

In the first 3 parts I explained how I could modify the Gamecube board inside the Triforce to dump the plain game images. This requires disassembling the whole unit, attaching a Gamecube BIOS replacement, requires a USB-Gecko and requires the Triforce region to be compatible with the game.

Another idea is to dump the GD-ROMs, then decrypting them, which should yield an identical image. Now ripping GD-ROMs with a PC-drive is rocket science. And it seems that I’m just not made for constructing rockets. I managed to dump a part of the data, but after that, I had a terrible accident (basically, the magnetic thing which holds the CD in place slided away, still rotating, making a terrible sound, and scratched my GD-ROM bad enough that the, already bad-quality, Triforce GD-ROM reader wouldn’t access the disc anymore). So I can’t even play VS2002 anymore :(. But the dumped data already yielded interesting results: repeating 8 byte patterns, a strong indication for a block cipher in ECB mode. I described before that when I dumped uninitialized RAM, it also looked like this, indicating that the decryption happens when reading the data from RAM, and not before. My first idea was: DES (but in fact it could have been any other 8b/8b blockcipher).

After breaking the PIC “security”, I got hold of a “8 byte key”, which is written directly into a hardware register. At first, it didn’t seem to work out. Decrypting the repeating strings with that key yielded only garbage. A day and a discussion with MrSporty later, I ran a test over my key: DES-keys in fact are only 56bit instead of 64bit, so every byte contains one bit of parity (each key byte should have an odd number of bits set). Magically, my key did have that property. And another key, provided by MrSporty (who hacked the PIC security ages before I did even know how a Triforce looks like), also had this property. This couldn’t be random luck - I’ve tried various endianness swappings again, with both the key and the data. Finally, a result: When byte-reversing both the key and each 8-byte block, my repeating data decrypted to … ALL ZEROS! Yay!

A test with other data showed that in fact this was the correct algorithm. With the key from the PIC, it’s now possible to decrypt GD-ROM dumps done with a PC CDROM drive (or a Dreamcast). Isn’t that great?

Speaking of this, we’ve managed to replicate both the previous hack (using the Triforce to read out the plain data, as well as sniffing the key) at some other person (not sure if he wants to be named here, though). Thanks!

On the emulation side, I’ve drastically improved the media board emulation. It will now handle all the communication (basically a shared memory buffer and a doorbell), emulates the loading progress, I can go trough the system test menu, query the serial number etc. What’s still missing is the JVS IO stuff. If anyone happens to have some non-Japanese JVS documentation, please help!

Unfortunately I’m currently 9000km away from my Triforce, which makes testing things a bit harder.