logoalt Hacker News

kstenerudyesterday at 5:42 PM2 repliesview on HN

Yes, it was a 2-part scheme:

They had a proprietary decryptor chip that sat between the program roms and the CPU. The decryptor used a table held in a small SRAM that was powered by a battery. When the SRAM lost power (battery died, or someone was trying to reverse engineer the board), the decryption key would be lost.

We broke it because someone noticed that the FC1 pin was tied to the drcyptor chip. In retrospect this made sense because only the program roms were encrypted, not the gfx roms (FC1 and FC0 pins were 01 for data access and 10 for program access [1]). Whenever the 68000 was requesting an instruction, it would set FC0 low and FC1 high, and when requesting data it would be opposite - this is how the decryptor knew when to decrypt.

But there was an achilles heel!

If you use PC-relative addressing, this ALSO causes FC0 low and FC1 high (because PC-relative is assumed to be accessing more program code). So all you had to do was fetch each address using PC-relative MOVEs, and it would happily give you the decrypted instruction words.

But then there was a secondary protection scheme: The decryptor chip would mysteriously shut down after a short while! WTF!

It wasn't until Capcom released their home console based off the original CPS board, along with backports of games like Street Fighter Zero, that the penny dropped. These backports were full of mysterious reads of weird addresses that made no sense.

It turns out that these weird addresses were what the decryptor chip was waiting for on the address bus. If no such address appeared within a timeout period, the chip would stop decrypting until you reset.

But the guys backporting CPS2 games didn't take the instructions doing these accesses out - even though the original CPS board didn't need it (probably it would have been a lot of work), so that secret leaked out.

After that, it was a simple matter of writing a program that read via PC-relative addresses, sent those weird accesses from time to time to keep the watchdog happy, and then output to a dumper via IO pins.

[1] Section 3.8: PROCESSOR FUNCTION CODES (FC0, FC1, FC2)

https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf


Replies

pansa2yesterday at 6:20 PM

> The decryptor used a table held in a small SRAM that was powered by a battery.

IIRC Sega’s System 16 did something similar. Was that board’s encryption cracked in the same way?

Was this style of anti-piracy measure widely used at the time, or was it only on a few 68000-based systems?

show 1 reply
sixothreeyesterday at 6:04 PM

Great explanation. The address bus reminds me of port knocking.