Originally posted by atomsymbol
There is no hardware encryption of memory.
If the encryption-related bits used by Denuvo aren't partially hidden in the hardware (CPU, memory, PCIe card), there exists a way to crack it.
But at the end of day, if attacker could physically access system and fiddle with it, determined attacker would eventually prevail. Efficient way to defer it would be using some heavily customized scheme unique to particular product, so no attackers are familiar with it and have to spend their time AFTER product has been released. If it going to be popular DRM scheme used before, there is high chance attackers would use previous knowledge to crack it quickly. To make it real PITA for attackers, it better to be inherent part of original product, so it nearly impossible to remove it completely. This would make cracking extremely unrewarding, say, plagued by bugs. Such things could put a nasty surprises like e.g. running for few hours so cracker thinks its okay, but then randomly crashing or displaying alerts anyway. Happy cracker releases patch, users are getting plenty of woes and can't contact support for obvious reasons. Cracker gets poor reputations, users "enjoy" by half-working program. Bummer. If program "copy" is truly unique, so it is no longer copy, but a customer-specific build, one could also put plenty of subtle, unique watermarks. It would not stop piracy, but authors would get very clear idea who is pirate. Even a mere build date could be unique identification of customer (and who the hell suspects mere build date is enough to get idea who has pirated the program). E.g. Ida Pro used these techniques a lot, and numerous pirates were caught and their keys were cancelled, despite of attempts to "neuter" watermarks. Even innocent-looking file creation date could be (ab)used as unique customer ID. On downside, custom protection scheme would make develoment more costly and lengthy process.
Porting:Porting is much easier than cracking.
Comment