As described in this post on ASSEMblergames.com and in this post, there is still a secret left that needs to be lifted for the newer “Type 3” triforces.

As a short summary, the new type triforce is probably a cost reduction of the old hardware. As part of this cost reduction, handling of the GDROM and security PIC, which was previously implemented in an SH-4 CPU, was “removed”. The network stuff was now handled separately on a MIPS cpu, but several strings that are proven to exist do not exist anymore in the flash rom, at least not as plaintext.

On a closer look, a mysterious file “firmware.asic” was introduced, 96k in size. Using the Dolphin emulator patches (which are finally integrated, by the way! Thanks to everyone involved!) I could change the emulated “INQUIRY” response. Depending on the first byte, which seems to be a version number, the emulated segaboot would either boot normally, or upload the very firmware.asic file. Apparently the Type-3 triforce needs this firmware before it can work.

As a final hint, segaboot displays, depending on the “version”, either “VxWorks” or “RX850”. While “VxWorks” makes sense - the old triforce’s NETDIMM is VxWorks based - a “RX850” couldn’t be found anywhere. Searching for RX850 yields a NEC (now Renesas) embedded CPU. Would firmware.asic be code for this CPU?

But looking at firmware.asic yields code that looks encrypted. Again we see repeating 8 byte patterns, a strong sign for a non-chaining block cipher. But - this time there is no external storage (like the security PIC for games) that would store the key. The key is probably hardcoded and stored deep within the silicon. My guess is that it’s still DES, given that they use DES for the games.

Brute-forcing the key would be a theoretical solution. After all, we can guess the plaintext for the repeating patterns (usually either all-zero or all-ones). There is a possibility that 8 byte blocks have to be reversed again (like for games). That gives us 4 potential ciphertexts to look for (normal, reversed, inverted, reversed-and-inverted) when encrypting zeros. After all, we only want to walk the keyspace once…

Today, after only a few hours of parallel search on 9 Xilinx V2P50 FPGAs, I’d like to announce: 00 22 44 66 88 aa cc ee. Brute-forcing the key is a practical solution. Thanks for keeping the key so simple! The leading zero bits really helped finding the key so fast.

For more details on the brute-force hardware and software setup, see my upcoming 27C3 Talk.