[_nullandnull_]

> 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]

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.

[_nullandnull_]

Thank you for the response. I never really thought about defense-in-depth from the angle of slowing an attacker down. I have always thought about it from a detection standpoint. You make a good point. Cheers.