Live data from Hacker News

Keeping the Pirates at Bay – Copy and Crack Protection (2001)

gamasutra.com

1–10 of 60 posts

Re: Keeping the Pirates at Bay – Copy and Crack Protection (2001)

#4
post #3

[deleted]

It didn't seem to matter in this case. "I know YOTD was vulnerable because the copy protection was only run once, at boot time. I assume the crack bypassed the copy protection and then restored the data to its original state."

Re: Keeping the Pirates at Bay – Copy and Crack Protection (2001)

#5
post #3

[deleted]

Don't forget that the PlayStation shipped with a 33MHz MIPS CPU before the SHA1 standard was even published.

This game came years later, but it's possible that CRC was the most effective option from a performance perspective.

Re: Keeping the Pirates at Bay – Copy and Crack Protection (2001)

#6
post #3

[deleted]

As someone else already wrote, it didn't really matter here. They already knew that whatever they did would be crackable, but it would just be a matter of time. They basically did an obfuscated checksum procedure (and they didn't use just one, but multiple checksums of overlapping regions). The thing this helped with was not to prevent cracking, but to prevent trivial cracking. This must have made the attackers think for a couple weeks at least, before they figured out all the parts of code they needed to modify to remove the checks. And, for those couple of weeks, many would-be pirates would have no choice but to buy the game if they wanted it.

Re: Keeping the Pirates at Bay – Copy and Crack Protection (2001)

#8
post #3

[deleted]

I can think of a few reasons:

First, this was a decade and a half ago. SHA was slow, open source SHA implementations were rare at the time, crypto had a stigma due to export restrictions, and was generally problematic to work with due to limited hardware support and speed.

Second, several different implementations were needed and they needed to be different enough that a simple pattern search would not find them all. SHA implementations LOOK a lot like SHA implementations in the disassembly, and it's hard to modify them in a way that leaves them functional but different enough that the compiler doesn't optimize away differences. A CRC is simple enough that you can do things like that.

Third, these things were all over the code, and run frequently. They couldn't just set a global flag and be done with it. They had to be fast. I am not sure, but I think the Playstation had hardware CRC support, but no hardware SHA support.

It's amazing that we now live in a world where you wouldn't think twice about using a cryptographically secure algorithm for data you don't actually need to hide (just obfuscate for a month or two) and not have any concern about performance.

Incidentally, if you're interested in an application of essentially every known antidebugging and antimodification technique known at the time in the same binary, have a look at https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06...

Re: Keeping the Pirates at Bay – Copy and Crack Protection (2001)

#10
I've often heard people say that piracy isn't harmful, but looking at what it does to video game developers, I'm not sure it always isn't. Day 1 cracks are obviously a serious concern if developers like this one would go to so much effort to prevent them. And I remember Nintendo saying piracy had hurt DS software sales in Europe (understandably: instead of buying several full titles, people would buy a cheap "R4" or similar flash cart and play hundreds of games for free - I recall having friends who did this).
Post reply on HN