Or: The “I cracked it open, so you don’t need to”-series.
I just figured out that there is a firmware upgrade available for Apple’s $29 miniDP->VGA Dongle. Yes, that’s right. That thing isn’t just plastic with some wires. It isn’t just a passive level adaption. It has real hardware inside. In this case, it’s a ST / genesis microchip gm58009. I couldn’t find much information about that thing (can anyone help?), but running strings B4Flasher.efi |objcopy -I ihex -O binary  on the firmware update reveals some secrets: That thing has 64k of firmware, a full debugmode (over some UART, I assume) and, accordings to strings, HDCP, OSD and all kind of video processing support. Picture after the break. (more…)

07: ffff000000000f00
08: 000f000000000f00
09: 00ffff0ffff00ff0
10: 000f000f0f0f0f0f
11: 0000ff0f0f0f0ff0

I’m sitting on this for a while now, and it didn’t change a lot. That means it’s either 100% finished or completely useless. It’s a python script which talks to the NetDIMM board on a Triforce/Naomi/Chihiro, and implements the “Satellite” protocol for uploading and running games. I dunno if it really works.
Have fun!
Here it is:triforcetools.py

I’m terribly annoyed by the fact that grep(1) cannot look for binary strings. I’m even more annoyed by the fact that a simple search for “binary grep” doesn’t yield a tool which could do that. So I wrote one.

Have fun: bgrep.c. Usage is simple: Just give it a hex string (without spaces) as first argument, and possibly use ‘??’ to mask out bytes. It will print matching files and the offset.

Introduction

Abstract

In this series of articles, I will talk about the design, implementation and fall of an optical media authentication used on a popular, but past, gaming console. I will show that it’s possible to reverse engineer such stuff without access to expensive equipment or insider information.While I will not talk about practical implementation of attacks against the discussed scheme, I will show that this has been done, and I will analyze how this has been done. More after the break.
(more…)

See some hardware pr0n after the break.  (more…)

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…)