I’m coming back to this thread after reading about this topic and working in a new copy protection system for a couple of months. I’m writing this from the perspective of a small dev with a small audience.
Some things that I have learned that might be useful to beginners (includes a recap of some things already mentioned in this thread):
First of all it is important to understand that copy protection is a part of our job, so I encourage everybody to learn some basics about it sooner rather than later or subcontract it (if you can afford it). It may sound obvious but I think we can all agree that it is the least rewarding of all tasks, so it is easy to be in denial about it…
One has to assume that a good cracker will eventually get the job done but your goal is to make it unworthy of their time by making sure that at least you are avoiding the most common mistakes. It is worth a try. I learned the hard way that if you don’t do it, you will be cracked very quickly (even if you are a small dev) and your sales are likely to take a serious hit. You may think now that with a very small revenue this is not important but it will probably lead you to abandon some projects. This particularly critical if your plugin/app is mature and users are already happy with it because they won’t feel the urge to upgrade to a later version after it has been cracked.
So what are those common mistakes?
Not encoding your strings (e.g. “License not valid” message) and checking the license only once. At least place a simple check when you validate the license, when you start the plugin and a “more serious one” somewhere else later.
Not encoding your RSA keys or making them easy to replace by pirated ones (key generator).
Tip 1: split them in parts.
Tip 2: don’t put anything at the beginning of the key that may identify them.
Tip 3: careful with one of the RSA public keys, it always looks quite similar so make an effort to encrypt this one.
Using a simple XOR key to encode your strings. There are a lot of examples in the internet of this method and it is almost useless. It is way too easy to crack if the cracker searches for some likely words and tries a few combinations. Try to do something at least slightly different.
Not rechecking your string encoding algorithm when you update your compiler (e.g. C++20 compilers are annoyingly good). Encoding strings in compile time and decoding them in run time is tricky because of the many optimizations of modern compilers. You may discover that your strings have been broken in smaller parts but are still readable in plain text after the optimizations.
Placing always a “return” after a failed license boolean check. Those are very easy to spot with a debugger and to remove. Do something else: e.g. add noise to the output.
Using the functions provided by JUCE or Openssl. The cracker may be able to quickly find where you are calling them. Try to avoid using them or, if that proves too difficult, introduce your own adhoc checks instead-of or in-addition to RSA.
Using the same copy protection code in several plugins/apps. If you do that, not only they will be all cracked at once but the cracker may actually use it to detect the copy protection code by looking at the shared bits with a simple diff.
Finally, if you have been cracked anyway, request the removal of the pirate links from the most popular searchers and illegal websites from day 1 and recheck every now and then (depending on how much of a difference it makes in revenue). Even if you will never be able to remove them from the internet, making your cracked plugin/app a bit difficult to find makes a difference and it is easy (5-10min) once you have learned how to do it.
Wow, this is some very interesting stuff. I’m now thinking how to use audio features to make it harder for the hacker to understand where’s the failure point. Cause if we can only make it harder for them, we have plenty of weapons in our arsenal. How about multiplying FFT/iFFT bins with the result of of the license check? This will make the hacker learn about negative frequencies and raising to the power of i, which is enough punishment if you want to crack my plugin.
That will probably be a complete waste of your time and energy.
Do you really think you can outsmart experienced hackers, if you have no knowledge and experience with how they work? You have to work at least at the level of the best hackers, otherwise your product will still be cracked. And you will not only be sad and hurt, but also frustrated.
I should have mentioned that I wrote that list of common pitfalls from the perspective of a small dev. In my personal experience, good hackers don’t spend too much time trying to crack products with a small audience. My point with avoiding easy mistakes is to make it unworthy of their time. If you have an important audience and a better budget, probably ilok is a better choice as others have said.
EDIT: I’ve included this now in the previous post.
I got that, and I respect your contributions and tips here.
I was replying to the post by @duvrin - with the enthusiastic but somewhat naive idea that a hacker might be dissecting audio plugins with his speakers on 10…
My point is that successful hackers are good at what they do. They have knowledge and experience that we likely do not have. Suppose 100 hackers in this world are looking at things to crack. Maybe you can make it harder for them and even “outsmart” 90, or 99, of them.
As long as there are more than 0 that persist, your product will be cracked and will be available for free.
Hackers do not spread themselves: users who download the results of their work do. So the net result of your efforts - no matter how clever and well designed - may be zero.
Please do not see this as a negative post.
I try to share to share some thoughts and experiences a year after I launched my first products and living from this work. Not so long ago I also thought that it should be possible to make it “more difficult” for hackers. Wrong, I have no idea how they work and what they know, so how can I prevent them from doing their “work”?
Well, it’s not impossible to learn this. This thread is pretty much about trying to guess how they work. Together we might be able to get a bit closer to it if we share what we have found out.
My statement was simplified, to underline that I cannot compete with hackers in any way.
After protecting my products with iLok I have learned a bit about how hackers can work. I personally see no point in discussing that online (and I have signed an NDA of course).
Easy mate. I was just using humor and having fun with the idea of FFT encryption if such a thing can be invented. We all agree that it’s just a matter of time and effort to get any software hacked, so my suggestion was to use the pain of calculous. Like saying “you don’t need to actually hack anything, just read this Fourier Transform article and the plugin is yours”.
I was referring to the proposed idea, which was to basically force hackers into a position where they would have to outsmart an experienced person outside their core competence. It is absolutely conceivable that in such a hypothetical case, in a hypothetical hacker forum discussing how to break such a mechanism, someone might come up with the same “don’t even try” argument.
In essence, I think that the “don’t even try” argument isn’t very helpful. Practically it all comes down to making it “just hard enough” with a reasonable and economically viable amount of effort, be it by implementing own protection mechanisms or simply wiring some money to PACE (like I do myself).
And even when outsourcing copy protection, it is still important to discuss details, mechanisms and possible approaches here, even if it’s just to scrutinize PACE’s offerings. They themselves will - of course - go out of their way to describe those evil hackers as absolute geniuses that nobody except them could ever possibly outsmart.
In the end, hackers and the nice people at PACE alike are simply humans that put on their pants one leg at a time.
If you have a smart and unique idea for a copy protection strategy, I wouldn’t recommend discussing it on a public forum that developers in the industry are known to frequent. You’re going to make it less unique to your implementation, and easier for an attacker to potentially work out what is going on.
Copy protection ultimately doesn’t work in the long run, period, but the objective is to delay compromises by as much as possible. Talking publicly about the part nobody has ever done before runs counter to the objective, so discretion is an important part of a broader strategy to buy as much time as possible.
That’s one way of doing, but definitely not a strong one. A better solution would include different checks, performed in different locations and at different points in time.
technically yes, but if the attacker attaches a debugger and finds this boolean check it is trivial to change it to return always licensed=yes.
If that’s all it takes, it is a short race. You can at least make it a few iterations by checking in different ways at different times.
The juce code returns a var instead of a plain bool. But there would still be a conversion to bool at some point in the code, but it’s a bit more obfuscated.
