logoalt Hacker News

ddtayloryesterday at 4:18 PM3 repliesview on HN

Is this similar to what CAPCOM did with their arcade system with that weird battery thing? If it powered off you had to send it back to CAPCOM to get it re-programmed. It was a DRM method used to combat piracy in the early arcade days.


Replies

dfxm12yesterday at 4:42 PM

I don't see how it is, but maybe you're referring to something else. I think you're talking about the CPS, or more famously the CPS2, which had a battery power its anti-piracy measures. You only had to send it in if the battery dipped below a certain voltage, after which it would destroy the security key (in memory), so the ROMs would remain encrypted. You could turn off the machine just fine. Arcade machines were regularly powered off. This coupled with the fact that the CPS2 batteries especially are prone to leak over critical components dubbed them the suicide batteries. These security measures have since been defeated in a few ways, all while removing the troublesome battery. You can replaced the encrypted ROMs on your board with Phoenix ROMs, which are decypted. You can solder on a PCB called the Infinikey, which loads the decryption key with power from the board and not the battery. Maybe there are others, too.

I think the HNG64 just had obscure/undumped/not understood hardware.

show 2 replies
kstenerudyesterday at 5:42 PM

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

show 2 replies
mschuster91yesterday at 4:58 PM

That shit is something you still find in the gambling world. Many of the modern one-armed bandits have HSMs with a loooot of protections, including batteries with drill through protections and god knows what else, although it's less used for anti-piracy but more to prevent tax fraud.

show 1 reply