8 ms·

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

49 points by Lrigikithumer 12y ago

Borogravia 12y ago
Fascinating.
deleted 12y ago
[deleted]
- sp332 12y ago
  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."
  - slipstream- 12y ago
    Doesn't the article also say they considered checking multiple times but decided against it to prevent too long load times?
    - sp332 12y ago
      The original comment was about the choice of checksum (CRC32), and a different algorithm might have made that harder if they had bothered to attack it.
- brandon 12y ago
  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.
- yalue 12y ago
  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.
  - AlyssaRowan 12y ago
    Overlapping checksums and delayed trap flags have been completely normal stock-in-trade of copy protection techniques for 30 years - Dungeon Master from the Atari ST was on here not long ago, to give one specific case study. Another post indicates that attackers have a budget here. That's misunderstanding the nature of your attacker, which is probably "a skilled determined cracker with time on their hands". Challenges interest crackers. Budgets are only really significant if you're talking about hardware dongle analysis, or if you're offering a bounty to a +veteran for something rare and tricky. Software analysis mainly just takes skill, and time - but no, probably not weeks to a skilled cracker, or money. Two, three days maybe (although they will need to actually find the time)? Perhaps there's a greater emphasis on first-day sales now, but perhaps that's the nature of publishers' expectations at the moment. Some publishers think they benefit from copy protection. Do developers really benefit from copy protection? Do users? Surely not, but it depends on how intrusive the copy protection is - and decades of experience shows that the more effective a copy protection technique is designed to be, the more intrusive and twitchy it is and the more of an inconvenience or disaster it is to the users (who, in such extreme cases, are actually very glad to be rid of it). Meanwhile, a copy protection that tries hard to not be intrusive - Steam - owns most of the PC gaming market by presenting a platform that's actually convenient, inexpensive, and fairly reasonably. With years of developers viewing copy protection as a publisher demand, hence the lazy crypter-wrapper-based protections which are just plug and go, maybe that's lowered the effort crackers needed to put in too. If the publishers are demanding more effort into it now (with the games industry thriving from a vibrant indie scene all the way up to Hollywood blockbuster budgets despite decades of nigh-unstoppable piracy) they're only really gradually rediscovering techniques some developers (and a few crackers) have forgotten - and ones the users would like to forget. I don't know about you, but I don't want a return to the bad old days of words from the manual or black-on-black code wheels.
- TazeTSchnitzel 12y ago
  They acknowledge CRC's weaknesses in the article. But this is 2000.
- Kliment 12y ago
  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-biondi/bh-eu-06-biondi-up.pdf https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06...
  - jnbiche 12y ago
    I deleted it before I saw there were responses, because I mistakenly assumed this article was relatively recent (I mean, retro look is a thing in video games, right?). I had no idea it was from 2001 until the "(2001)" was added after it was first posted (I'm not a gamer at all). Sorry for the confusion, about 5 people responded at the same time right as I was deleting it (didn't know the comments were incoming). 2001 obviously makes a big difference. I'll pay more attention to dates now. That said, I don't understand why you wrote "data you don't actually need to hide". Wasn't that the point? I mean, holding off cracks for a month or two was good, but wouldn't holding them off for years be ideal? And yes (I can't tell if you're being disdainful or honestly amazed) but we do now live in a world when you don't have to worry about performance implications of using SHA in all but the most resource constrained environments (and even then, SHA hardware acceleration is often available). But you make some other good points I had not considered.
hias 12y ago
Earthbound / Mother 2 for the SNES also did this, way before Spyro.
- danielweber 12y ago
  Among other things, you'd get to the end boss and then everything would break. http://earthboundcentral.com/2011/05/earthbounds-copy-protection/ http://earthboundcentral.com/2011/05/earthbounds-copy-protec...
TazeTSchnitzel 12y ago
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).
- NoMoreNicksLeft 12y ago
  > cracks are obviously a serious concern if developers like this one would go to so much effort to prevent them. If your crazy uncle wears tinfoil hats to combat CIA mind-rays, this doesn't mean CIA mind control technology is a concern. It just means your uncle is mentally ill. > 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 This is no proof that sales were hurt. It could be true (and almost certainly is) that people who did this would not have bought extra games even if the flash carts had been unavailable. If the 12 yr old pirates $17,000 (retail price) of music, this does not mean the record companies are out $17,000... 12 yr olds don't have $17,000 to spend even if they are prevented from pirating. You're not being logical, you're just parroting anti-copying propaganda. It's more than a little sick.
  - phpnode 12y ago
    You're not being logical, you're just parroting anti-anti-copying propaganda. > If the 12 yr old pirates $17,000 (retail price) of music, this does not mean the record companies are out $17,000... 12 yr olds don't have $17,000 to spend even if they are prevented from pirating. Right, but it does not mean that the record companies are out $0 either. They are probably missing out on at least several hundred dollars worth of revenue for that particular person.
    - NoMoreNicksLeft 12y ago
gpcz 12y ago
The biggest takeaway of this article is that effective security comes from proper threat modeling and analyzing the cost dynamics. Most media companies in that era attempted to build an "uncrackable" system which always got cracked in short order because the mechanism depended on one tactic. By acknowledging that all protection schemes eventually get figured out and acknowledging the adversary's strengths and weaknesses, the author could then employ defense-in-depth techniques to maximize the cost of cracking the system. Remember that every adversary has a budget.
- _nullandnull_ 12y ago
  > the author could then employ defense-in-depth techniques to maximize the cost of cracking the system. Can you provide more details on this statement? I understand defense-in-depth and the different methodologies for cracking software but your statement doesn't make sense when applied as a whole. Do you have any examples?
  - gpcz 12y ago
    The real meat of the defense-in-depth analysis is on page three of the article. Spyro had a two-layer defense-in-depth scheme: one layer that looked like a normal PSX cracking problem, and another that would look fine for a while and then mess up the game over time, which forced the crackers to make a complete play-through (and probably multiple failed play-throughs) to verify that their cracks worked. This served to make the cracker's feedback loops as long as possible. The author also acknowledges that it was impractical to add more layers of protection due to computational/IO/space costs, but that it would have offered more security, such as having multiple copies of the game's executable code on disc that are separately encrypted and randomly used, using custom compression algorithms, etc. At its philosophical core, defense-in-depth is the idea of delaying an attacker rather than preventing an attack. In a military or IT situation this delay usually lets the defender detect the attack and counterattack/prosecute. In the cracking world, the delay IS the counterattack, since release groups measure their performance based on release quickness and the company (theoretically) gains revenue from the game not being on Kazaa during that critical sales season.
minimaxir 12y ago
Previous discussion: https://news.ycombinator.com/item?id=8807135 https://news.ycombinator.com/item?id=8807135
towelguy 12y ago
It would be interesting to see the difference in sales in the 3rd month between US and Europe, since the European version took one more month to crack.

49 points by Lrigikithumer 12y ago

Borogravia 12y ago

Fascinating.

deleted 12y ago

[deleted]

sp332 12y ago
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."
- slipstream- 12y ago
  Doesn't the article also say they considered checking multiple times but decided against it to prevent too long load times?
  - sp332 12y ago
    The original comment was about the choice of checksum (CRC32), and a different algorithm might have made that harder if they had bothered to attack it.
brandon 12y ago
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.
yalue 12y ago
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.
- AlyssaRowan 12y ago
  Overlapping checksums and delayed trap flags have been completely normal stock-in-trade of copy protection techniques for 30 years - Dungeon Master from the Atari ST was on here not long ago, to give one specific case study. Another post indicates that attackers have a budget here. That's misunderstanding the nature of your attacker, which is probably "a skilled determined cracker with time on their hands". Challenges interest crackers. Budgets are only really significant if you're talking about hardware dongle analysis, or if you're offering a bounty to a +veteran for something rare and tricky. Software analysis mainly just takes skill, and time - but no, probably not weeks to a skilled cracker, or money. Two, three days maybe (although they will need to actually find the time)? Perhaps there's a greater emphasis on first-day sales now, but perhaps that's the nature of publishers' expectations at the moment. Some publishers think they benefit from copy protection. Do developers really benefit from copy protection? Do users? Surely not, but it depends on how intrusive the copy protection is - and decades of experience shows that the more effective a copy protection technique is designed to be, the more intrusive and twitchy it is and the more of an inconvenience or disaster it is to the users (who, in such extreme cases, are actually very glad to be rid of it). Meanwhile, a copy protection that tries hard to not be intrusive - Steam - owns most of the PC gaming market by presenting a platform that's actually convenient, inexpensive, and fairly reasonably. With years of developers viewing copy protection as a publisher demand, hence the lazy crypter-wrapper-based protections which are just plug and go, maybe that's lowered the effort crackers needed to put in too. If the publishers are demanding more effort into it now (with the games industry thriving from a vibrant indie scene all the way up to Hollywood blockbuster budgets despite decades of nigh-unstoppable piracy) they're only really gradually rediscovering techniques some developers (and a few crackers) have forgotten - and ones the users would like to forget. I don't know about you, but I don't want a return to the bad old days of words from the manual or black-on-black code wheels.
TazeTSchnitzel 12y ago
They acknowledge CRC's weaknesses in the article. But this is 2000.
Kliment 12y ago
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-biondi/bh-eu-06-biondi-up.pdf https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06...
- jnbiche 12y ago
  I deleted it before I saw there were responses, because I mistakenly assumed this article was relatively recent (I mean, retro look is a thing in video games, right?). I had no idea it was from 2001 until the "(2001)" was added after it was first posted (I'm not a gamer at all). Sorry for the confusion, about 5 people responded at the same time right as I was deleting it (didn't know the comments were incoming). 2001 obviously makes a big difference. I'll pay more attention to dates now. That said, I don't understand why you wrote "data you don't actually need to hide". Wasn't that the point? I mean, holding off cracks for a month or two was good, but wouldn't holding them off for years be ideal? And yes (I can't tell if you're being disdainful or honestly amazed) but we do now live in a world when you don't have to worry about performance implications of using SHA in all but the most resource constrained environments (and even then, SHA hardware acceleration is often available). But you make some other good points I had not considered.

hias 12y ago

Earthbound / Mother 2 for the SNES also did this, way before Spyro.

danielweber 12y ago
Among other things, you'd get to the end boss and then everything would break. http://earthboundcentral.com/2011/05/earthbounds-copy-protection/ http://earthboundcentral.com/2011/05/earthbounds-copy-protec...

TazeTSchnitzel 12y ago

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

NoMoreNicksLeft 12y ago
> cracks are obviously a serious concern if developers like this one would go to so much effort to prevent them. If your crazy uncle wears tinfoil hats to combat CIA mind-rays, this doesn't mean CIA mind control technology is a concern. It just means your uncle is mentally ill. > 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 This is no proof that sales were hurt. It could be true (and almost certainly is) that people who did this would not have bought extra games even if the flash carts had been unavailable. If the 12 yr old pirates $17,000 (retail price) of music, this does not mean the record companies are out $17,000... 12 yr olds don't have $17,000 to spend even if they are prevented from pirating. You're not being logical, you're just parroting anti-copying propaganda. It's more than a little sick.
- phpnode 12y ago
  You're not being logical, you're just parroting anti-anti-copying propaganda. > If the 12 yr old pirates $17,000 (retail price) of music, this does not mean the record companies are out $17,000... 12 yr olds don't have $17,000 to spend even if they are prevented from pirating. Right, but it does not mean that the record companies are out $0 either. They are probably missing out on at least several hundred dollars worth of revenue for that particular person.
  - NoMoreNicksLeft 12y ago

gpcz 12y ago

The biggest takeaway of this article is that effective security comes from proper threat modeling and analyzing the cost dynamics. Most media companies in that era attempted to build an "uncrackable" system which always got cracked in short order because the mechanism depended on one tactic. By acknowledging that all protection schemes eventually get figured out and acknowledging the adversary's strengths and weaknesses, the author could then employ defense-in-depth techniques to maximize the cost of cracking the system. Remember that every adversary has a budget.

_nullandnull_ 12y ago
> the author could then employ defense-in-depth techniques to maximize the cost of cracking the system. Can you provide more details on this statement? I understand defense-in-depth and the different methodologies for cracking software but your statement doesn't make sense when applied as a whole. Do you have any examples?
- gpcz 12y ago
  The real meat of the defense-in-depth analysis is on page three of the article. Spyro had a two-layer defense-in-depth scheme: one layer that looked like a normal PSX cracking problem, and another that would look fine for a while and then mess up the game over time, which forced the crackers to make a complete play-through (and probably multiple failed play-throughs) to verify that their cracks worked. This served to make the cracker's feedback loops as long as possible. The author also acknowledges that it was impractical to add more layers of protection due to computational/IO/space costs, but that it would have offered more security, such as having multiple copies of the game's executable code on disc that are separately encrypted and randomly used, using custom compression algorithms, etc. At its philosophical core, defense-in-depth is the idea of delaying an attacker rather than preventing an attack. In a military or IT situation this delay usually lets the defender detect the attack and counterattack/prosecute. In the cracking world, the delay IS the counterattack, since release groups measure their performance based on release quickness and the company (theoretically) gains revenue from the game not being on Kazaa during that critical sales season.

minimaxir 12y ago

Previous discussion: https://news.ycombinator.com/item?id=8807135 https://news.ycombinator.com/item?id=8807135

towelguy 12y ago

It would be interesting to see the difference in sales in the 3rd month between US and Europe, since the European version took one more month to crack.