debugmo.de

As my original Triforce  is not reachable for me at the moment, I’ve bought another one. This time it was a “newer-type” Triforce, without the detachable DIMM board. Those are also called “type 3″. At first it looked as they only integrated the DIMM board into the triforce housing, but after more investigations, it looks like this was a complete redesign. On the other hand, the Base board (handling JVS IO) and the gamecube remained identical. The previously FPGA-based Media Board attached to the DIMM board - now, the Media Board contains the DIMMs, a fat SEGA chip (I call it “asic”), the GD-ROM connector, an unused IDE-style header, the SegaBoot flash (Media board bios) and the backup battery. Also, the “Security” PIC attaches to this board. There is no SH-4 CPU anymore. However, there is also a “network board”. While there was already a separate network board in the old triforce, previously it only contained the NIC. Now it contains a MIPS CPU (AMD AU1500), with a separate flash rom. The “Netfirm”, as the firmware on this board is called, is still VxWorks-based - however, all GD-ROM and PIC functionality is not present there. That’s interesting - there is no other firmware or obvious CPU on any of those boards. But it must be SOMEWHERE.

After thinking about this mystery for some time, I decided that probably the best bet is that the big-fat-Sega-chip now also contains a (small) CPU, which would be in charge for doing the GD-ROM access and the security PIC handling. But where is the firmware?

Disassembling the newer SegaBoot gives a possible answer: While the original Triforce BIOS only accepted one type of DI Inquiry response (0×21), the new firmware also looks for 0×29 and 0xA9. If it finds 0×29, it will upload a blob of data - actually, a file called “firmware.asic”, which lives inside the SegaBoot GCM. It’s 96kb, and looks encrypted. Actually, we see repeating 8byte patterns. My guess is DES. However, the first 0×10 bytes seem to have a special meaning, but that would go too much into details at this point. I was not yet able to decrypt the firmware.

As a side note, the Netfirm can communicate with the gamecube software over specific DI commands (or, technically, answers: the gamecube constantly polls for queries from the DIMM board/netfirm). The Netfirm has a nice “debug-mode”/”development”/”backdoor” on tcp port 10703, which allows you to read/write gamcube memory (isn’t that nice?) as well as DIMM memory as well as the DES key for the uploaded content (as decryption happens on the fly)…  … … Guess what we will see next.

Some (older) emulation screenshots after the break…

(more…)

Just a small tool to decrypt Triforce images:

decrypt.py

Have fun! You have to point it to the right place for the keys. Also, you need to unpack the ISO filesystem first. I do this by

• Converting the GD-ROM data session to 2048 bytes/sector (UltraISO offers this functionality in the context menu),
• extracting the game files with extract.exe

A bit ugly, but that works.

See decrypt.py for more details on how this works. Thanks to TheGuru for hosting the keys!

 [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.

Step 1: $40k overpriced LA (could be replaced easily with a $150 FPGA board), some wires

<

Step 2: 20 lines of python code

Difference between those? Just some simple XOR and ADD.

(more…)

I’ve spent some time on understanding the exact protocol spoken to the baseboard. Thanks to dolphin, I could run the software (for example, media board bios) and log all EXI/SI transfers. More details later, but I could replay them on the Triforce, thus grabbing the right responses, and emulating them properly in dolphin.

There is still a lot left to do, of course. :) The media board emulation is more than incomplete (it only emulates reads, so far), and there is no JVS IO yet.

I almost forgot to write about the successful execution of Task 3:

I basically patched the SegaLoader (i.e. the Media Board payload) to break after initializing the GD-ROM, i.e. after reading the GD-ROM into Dimm-Board’s memory. Then I just repeated the steps I did for dumping the Media Board (after the Media Board is switched into “Dimm Board”-mode, the same read commands will read the data from the DIMM Board instead of the onboard flash). The result is a (~300 MB, in my case) .gcm file with the game data. It won’t run as it is on a Gamecube due to the main board/media board dependencies, but I’m not going to say that this cannot be patched. An interesting property is that the unused data (i.e. after the game data - the image is not padded with garbage, like usual Gamecube discs are) doesn’t look like uninitialized ram. Instead, it looks like random garbage, but repeating, sometimes changing. I don’t think that the RAM will be intentionally filled with that data - instead I believe that one of the SEGA chips on the DIMM board decrypt the data on the fly, and the data is stored in RAM in encrypted form.

The next step now is to understand the process of decrypting the GD-ROM data. For that, I started with reversing the DIMM Board firmware. I also tried to dump the GD-ROM data directly, with mixed success (due to my setup. I should use a real Dreamcast). But I dumped enough to see repeating 8 byte patterns, which is a strong indication for a 8byte block cipher in ECB mode. Maybe a simple DES? Who knows… This data is probably loaded, as it is, into the DIMM board’s RAM. I’ve searched for decryption functions in the firmware, and didn’t found any block cipher. Thus I’d say that it’s done directly in hardware.

Now the “security PIC” (each game comes with a specific one) comes into the scene: What I did found in the DIMM Firmware was something which looked like something that bitbangs stuff, after a lot of obfuscation, over a GPIO bus. 8-byte strings are send, with 8-byte strings received as the answer. Two example string is “Akeycode” and “Bkeycode”. The result of these commands (7 bytes of the first response + 1 byte of the second respopnse) are written into a specific register. Might that be the decryption key for the game data? There are some other commands, and something which looks like a challenge/response, but that’s nothing I care about at the moment.

Ok, this post is a bit lame. First, I know that captchas are random, and there are a lot of funny words in a 26^6-space. Second, it only works in German, if you want translate it: “po” means “butt”. So yes, it’s a lame sexual reference. Still interested? Fine, then read on.

(more…)

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 0×81300000. 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, 0×41C64E6D. 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.)

I’ve already described that the heart of the beast is a basically unmodified retail Gamecube board. Rumors tell it has 48MB of (MEM1-)RAM, but based on the memory chip quantity and description, I cannot confirm that - they exactly match a retail Gamecube. As a side note, games seem to be 512MB max. I won’t give any further comment about the possible implications of these facts ;).

However what is modified versus a retail Gamecube board is that a different IPL is installed. The IPL is basically the BIOS of the Gamecube. It’s stored in a serial ROM chip in encrypted form. This encryption has been partially cracked already, which allowed developing of Hardware devices to override the stock IPL with a custom variant. There exist several homebrew and commercial modchips ([1], [2]). While those devices can be used installing a BIOS mod which enables piracy, they are also very helpful for running homebrew software right from the start.

To dump the IPL of the Triforce Gamecube board, I’ve attached a qoob modchip to the Triforce board. This allowed me to override the Triforce IPL with my own code. I’ve then flashed a modified version of my IPL replacement, which allowed me to dump the Triforce IPL. I had to force progressive videomode to make the VGA video output of the Triforce working correctly (it doesn’t seem to set the correct ID pins). One small problem is that the original setup uses the serial 1 port for the IO board, whereas I need it for the network adapter (BBA). But it’s possible to disconnect the serial port, and attach the BBA, if you remove the BBA housing. It’s not nice, but it works. (The problem is that the physical space is rather constrained, but without an extension cord of the proprietary serial and DI connectors, it’s impossible to use the Gamecube board outside of the Triforce power supply, which in turn is coupled to the IO and Media board. Some slight PCB bending however allows using the BBA in the Triforce setup - no showstopper here. Note that it’s also possible to use the Gamecube board in a stock Gamecube housing.

A quick analysis of the (quite small) IPL shows that it reads the next loader from the media board, possibly using simplified or custom DI commands. If you boot without the media board, all you get is a “MEDIA BOARD MISSING” error message. If you install the media board (without the DIMM board), you get the Triforce-logo and an error message that the DIMM board doesn’t work. This gives the conclusion that the the logo and the rest of the loader are stored in the Media Board Flash memory.

Next step will be acquring an image of what’s contained there, preferable using the DI. If I can’t work this out, I need to resort to reading out the flash directly or inserting debug hooks in the IPL, then run it.

(Sorry, I don’t have pictures of the setup yet, but I will provide them. My jailbroken iPhone didn’t saved the pics. That’s what you get when using hacked software ;)

What is “The Beast”? Other than what you find on wikipedia, the Triforce can be described as a tweaked Gamecube.

The heart is a standard, retail Gamecube board, allegedly with twice the amount of MEM1, and a custom IPL. Instead of the DVD drive, the Triforce has a Sega-developed “media board” which interfaces to a “DIMM board”. The “DIMM board” is an embedded computer running VxWorks. It has a large amount of buffer RAM (my unit has 512MB), and interfaces to a NAOMI GD-ROM. The board will preload the complete gamedata from the optical medium into the buffer RAM. Also, it features an ethernet and a serial port, probably to link several arcade machines. The media board will then provide the glue logic from the DI (Gamecube’s DVD Interface) to the DIMM board. The DIMM board also contains a security PIC, which has to match the game disc. That is, game discs come with a “hardware dongle”.