Last plugin I released was cracked within the same day, which completely sucks.
I’ve always had in mind that fighting against piracy is a bit meaningless since everything will eventually be cracked. However, having it cracked within the same day was a bit too much, so I’m thinking of ways to make the hacker’s job a bit harder.
For my next plugin I will release two installers: the demo one and the full one, which can be authorized entering your username and serial number. That way, the hacker will need to actually buy a license to get the full installer.
Also, I’ve seen in a few plugin that an anti-debugger functionality is implemented. How is that done?
Is there anything that you implemented that immediately made your scheme more robust? I’m curious to know what it can be done to better protect our work.
This has happened to me numerous times, and they even cracked one of my freeware plugins only because it showed a promotional page with links to other products of mine. Yes, piracy sucks, but I’m afraid there’s nothing really effective against it.
They use suppliers, people who honestly buy the software they use but also supply it to the cracker groups. Why they do it is still a mistery to me.
A few things that could make their life harder could be:
enable the compiler option to strip all symbols, but this would also make your life harder if you need to debug the executable using a crash dump file. Alternatively, just use fuzzy symbol names for the variables and methods that deal with copy protection, for example instead of having a bool variable of type bool licenseIsValid = true; call it something like bool __f0e3b6c0 = true;
don’t have the license check happen only once, set up a timer that repeats the license check at random intervals or whenever a given event occurs, such as a button pressed by the user, or something else that isn’t crucial in audio performace;
use a C/R method that requires checking the license with your server at least once a day;
There could be many other ways, but in my experience none of these has ever solved the problem.
After spending over 10 years on this, along with the development of our products, this is what I learned:
You will be cracked. The scope is to not get cracked within the first month of the product release, which is the most important for your cash flow. In the end, it all comes down to a bool check that will be always easily hacked with jump instructions placed to the proper addresses.
Focus on integrity checks. According the plugin is activated (either in a legit way or via a crack) you should be able to check that the activation has been done the expected way. That’s rather easy if you use keyfiles. A bit tricky if you are dealing with serials
Place checks randomly everywhere in your code. Random checks, at random places, different checks and places for each plugin format on each OS platform
If you are using public key encryption, also place random checks on portions of the public key
Always strip your binaries and encrypt your strings
You have to make the cracker life a bit harder, to the point they will consider cracking you a waste of time. That’s a great advantage small devs as us have, since we don’t have the reputation of bigger names
You should also make a bit harder the life of who uses cracked versions of your plugins. Don’t mind the casual downloader. These will never convert. Power users, who have these plugins loaded in ongoing projects, are more likely to convert if their projects get stuck
Always download the cracked versions of your plugins. Load them on a VM and study! Security is a process, not a solution
I have also been hit hard and I was about to post about this topic too. Anybody knows of a way to insert a personalized digital watermark to a file from a PHP script as additional protection?
I have learned that one of the first thing that crackers do is remove all network connections. A simple firewall also prevents that. Last but not least, some users don’t want their production computers to be connected to the internet and I absolutely understand that (e.g. preventing windows updates that can make the system unstable is already a good reason).
So I don’t think it is worth it to invest in any methods that involve a server connection outside of the activation process.
Yes, you’re right. Maybe it is too far a stretch but I’m thinking that server compiling the code with an input user id and random macro defined license checks could be a pretty solid solution? Would a one-per-user notarization be allowed?
If I remember correctly, the company Redmatica (later bought by Apple) did issue installers that were bound to the user’s machines and couldn’t be used on any other computer.
The traditional Redmatica installers were personally keyed with your user and machine ID’s - so you cannot use anyone else’s installers on your machine
However, that was before the introduction of notarization. I don’t know if it could be feasible now: it might be there is some (documented or not) cap at how many installers one can submit to Apple for notarization without causing concern and/or hitting some limit.
I think the question you should ask yourself is what will you do once the watermark allows you to know the origin of the cracked version. Maybe the origin customer will be some random guy in Belarus, or a teacher in Oklahoma etc… What can you do, once you know that ? You won’t even know if he did knowingly crack the software / post it on a forum of crackers / just had it stolen by a student.
I don’t see the point in watermarking a binary unless you are prepared to spend the money taking somebody to court for cracking or supplying, but by then the damage is done anyway. If you think it’s going to deter crackers in a country that is likely not going to be very friendly to your legal process, or that you’re going to catch and punish somebody for the greater good, then you’re likely wrong. In most cases people that buy legit software and supply to crackers use stolen credit card details and burner emails anyway because it’s so easy to do it and you’ll struggle to identify anyone.
Supposing you went this way though and caught them red-handed, and were prepared to spend so much money to go after crackers or suppliers in an expensive legal process, you’d have been far better off spending that money on something that will actually protect your software which is to just suck it up and use iLok. That will buy you months and usually years of protection, and some very client-friendly licensing options (USB, cloud and machine), it also makes resale of licenses easy, and facilitates secure refunds. All worth having.
If you try and do this yourself, in almost all cases, they’ve seen it all before and will find a hole in your solution. How many times do you want to fail, refortify, and go through the loop? For people that enjoy the sport, ok, but if you’d rather spend your energy developing audio IP it’s just not a good use of your time.
Don’t worry about potential clients complaining about iLok, the silent majority just gets on with it. I expected to be dragged through the mud when I went iLok after spending several years with basic licensing files, in reality I had a handful of people complain at the time and perhaps now two or three nasty emails about it a year and a few ‘never will I ever…’ posts on forums and social comments. It’s really not been much of a problem.
Don’t worry about the cost if you’ve found this is hurting your sales because then it will pay for itself anyway.
If I can include the user id in the binary (watermark or compiling the binary with it), I can also save it with the plugin data and don’t allow users that save data with a cracked plugin, to use their previous projects with newer versions of the plugin.
I admit that it is quite useless to identify the user who cracked the plugin, but it feels like a small victory to force that individual to buy another license. Maybe it is just sentimental but it bothers me that he or she is getting free updates at the moment.
Regarding code-signing on macOS there is a way to deal with it.
Create a nested bundle inside the plugin bundle
Add dummy files to the bundle
Sign the nested bundle
Sign the plugin bundle
Swap out the dummy files
Re-sign the nested bundle only! (you must use the same certificate as before)
This is basically a way to add files to a bundle after the main bundle was signed without resigning the whole thing.
For notarisation I think there are ways to have the notarisation ignore some parts, for example if you had a large sample library you may not want all that uploaded and notarised as part of the process. If you do this I wonder if it’s possible to swap the files out (in this case the nested bundle) without breaking anything? I’ve never tried this though.
I will also say that not all implementations have to come down to a single boolean choice somewhere. You just need to make sure your plugin can break in multiple ways (better still have some of those ways take time or be subtle so it’s much harder work for the cracker to know when they are done). The key is to have multiple different checks each of which must be completely independent of each other, any function or common code between them will be a vulnerability.
Although all the above may be possible, I probably wouldn’t advise it. Having done iLok protection before I would probably initially be opting for at least the simplest protection they offer so I could get on and concentrate on my core business. Whichever route you take costs some amount money, but figuring out how much is down to individual circumstances…
Ignore it - loss of sales
Attend to it yourself - your time and the cost of taking that time away from other products and therefore sales
Third party protection such as PACE iLok - The amount you pay them
In regards to loosing customers, yeah some people are opposed to it but there are also others who insist on PACE iLok protection. Some people actually like that all their licences can be kept together making it easier to bring their own licences to a studio.
Another little advise is to “know your enemy”. Set up a Google Alert with your brand name, so you’ll be able to find when you get cracked. Also, you have to follow the places where these cracks are released. They can be VERY informative. A notorious team was used to add a lot of info in their NFO files, but now they had backed down with that. You’ll find out that some 3rd party licensing solutions are cracked on the same they of the product release.
About the “serialised” building for each customer: I once thought about that, but it’s a bloodbath in terms of cost and time. A customer won’t wait the build time and you’ll get a lot of tickets or refund requests. This will impact more the legit customers than the ones using the cracked versions, so it’s not worth it, imho.
We have recently noticed that some teams have stopped trying to break our licensing system and started focusing on removing the demo limitations. This was a weak spot since I was too much focused on the license. Integrity checks are difficult to implement but, imho, that’s one of the most important key aspects to focus on.
