I would like to offer a demo version for my next plugin, with sporadic noise or silence (eg 5 sec every minute or so).
The question is how to do such a thing without having something too easy to hack like a counter and an if statement in the process block.
Any idea or experience you could share on the matter would be much welcome
Roll you own basic implementation and spend more time on other areas of plug-in development. This will be cracked quickly if your plug-in becomes slightly popular.
Put a lot of effort into a bespoke anti-piracy system. Depending on how sophisticated this is it might resist cracking for a handful of months, but, ultimately, the most probable outcome is that it will be cracked pretty swiftly.
Use PACEâs tools. (JUCE is owned by PACE, but I hope this quick summary is fairly uncontroversial.)
Iâd advise against attempting option 2 unless you have the corresponding expertise and infrastructure.
I am well aware of the situation and the different options available, and I would like to stick with a reasonable solution 1.
I should have specified that the demo version would be a separate build. The idea is to have something that cannot be so easily (if at all) turned into the normal version, by entirely removing important parts (eg set/get state, or some functionalities), printing an explicit (and obfuscated) demo message on the UI, and inserting silences (or noise).
It is that last part that I would like to address here: any basic idea or recipe for something reasonably more elaborated than a simple counter with a test?
Hackers have been known to either deobfuscate or replace entire components of effects with their own implementations. Any kind of elaborate conditional can be reverse engineered, even when itâs mixed in with the actual audio processing algorithm itself.
The first option of actually compiling out functionality would be a better approach. You then risk people grumbling that they canât activate the demo in-place, but this simplifies things on your side a lot.
My approach to anti-piracy measures is simply, donât bother.
People who are willing to pay for your products will just pay, and those that arenât wonât. No oneâs going to see that your product is hard to hack and so cave in and buy a legit copy instead, theyâre just not going to use it.
So you could spend hours making sure that when you release only 1000 people get hold of a pirated copy instead of 2000, but youâre going to sell the same number of copies either way. You may as well spend that time adding features to increase the number of sales.
If you really wanted to deter hackers, you could take the approach that the makers of Game Dev Tycoon took and âleakâ a fake version of your product on piracy websites. They made a version of the game that was impossible to win and released it on various piracy sites for free. When people then wrote in and complained they simply said âwell you should have paid usâ.
You canât stop crackers getting a hold of a fully licensed copy, they will simply use a stolen card to buy it from you and youâll be none the wiser for a few weeks until the chargeback hits (which you canât tell from a regular chargeback anyway, so you learn nothing). So really there is no point making two builds, youâre just making extra work for yourself.
There really ought to be a âCopy Protectionâ pinned topic or perhaps better: a FAQ forum category where stuff like this topic could go and therefore be more easily discovered.
Itâs a regular topic and the discussion results in always the same talking points:
Donât bother with copy protection
Make an extremely simple licensing system that you donât waste too much time implementing
Pay PACE
Iâve no idea what the 3rd option involves, but I imagine itâs a) not cheap b) not something a solo developer can undertake easily.
Iâm personally a fan of the 2nd option, it stops the casual pirates, gives the people who did pay some kind of peace of mind that their investment is âprotectedâ, but wonât stop R2R (or whoever) from easily reverse engineering your code. The key thing is donât bother wasting time trying to be clever, it wonât work and your time is better spent making cool products.
But the 1st option always gets a lot of backing too, every 6 months that this question arises.
My reasoning behind option 2 is two fold:
My products can be used without a license, but they continually nag you into buying a license after a certain time of installing
People have to trust that the crack didnât install a cryptominer or ransomware as an added âbonusâ
One thing I would caution against: annoying âinternet requiredâ activation. Theyâre just a PITA for users (and more complex, so youâll be wasting yet more time on protection that would be better spent making cool shit!). Also if you go out of business youâve screwed over all your previous customers who can no longer activate the software they paid for in good faith.
A solo developer can undertake a Pace protection task, itâs not a ten minute job but itâs not difficult for a competent developer by any stretch. Costs might be a bit intimidating for somebody just starting out, but so are many other costs like hiring a graphics designer or a marketing consultant that are worth doing and will pay off in the long run. Itâs probably something to think about for a second project when you know how well or not well the first one did.
There are some 3rd party solutions that are good. Iâm using LimeLM and quite happy with it. Obviously it wonât stop hackers nor people used to download pirated stuff, but it will reliably prevent users from sharing with their friends, so thatâs a real plus.
On the down side itâs not cheap (about $120/month) and requires some time to set it up and keep it updated. But it works on Mac and Windows, so thatâs also a big plus.
Itâs server based, but I guess if we go out of business, we can always release an unprotected update;-)
Know or anticipate the needs of your intended clients, picking the right type of protection for the right audience is very important. There is actually a very large proportion of users that want iLok based protection because it is as close to an industry standard as we have, many of their existing tools are using it and it becomes very convenient to add another license to their existing collection without having to work through / remember how another licensing scheme works. Lots of folk still actually like using a dongle too because they can move between studios very easily, and getting cloud+machine auths with zero additional effort is helpful. Conversely there is a proportion of users that wonât touch anything that uses Pace at all and you could lose those people for good. Itâs important to do your research since that part of the experience can be as important as the plugin itself.
One of my most important clients was introduced to my plugins at a seminar as somebody just happened to have a license on a dongle on their keychain. They were able to just throw it up and give them a quick demo as they thought theyâd like it. Today they could have logged into cloud as well, and the session can be closed remotely. It was a very powerful exchange, and good licensing schemes enable chance events and can help promote your work like this rather than getting in the way. It can be very easy to get focused on the up-front cost, or the up-front engineering time needed, those only seeing friction - the bigger picture can be harder to see sometimes but itâs arguably more important.
Thank you for all your responses. Once again let me stress the fact that I am aware of the pros and cons of the different strategies (and yes, I have read all the related topics on this forum as well as KVR).
I decided on a strategy when I released my last plugin two years ago, with an approach that I think is reasonable, user-friendly, and compatible with my situation and ideology. I want to stick with it as it has proven good enough for me and my users.
Now I want to offer a demo version for my new plugin, and my question is code-related:
I want to implement a simple periodic silence in that demo build, and would be delighted if members would be willing to share tips and ideas on how to do it a way that would be obfuscated enough to deter unseasoned hackers.
I donât understand what youâre trying to achieve here. Do you think you can glide under the radar of the most capable crack teams and outsmart the less experienced crack teams? This is folly.
You need a place to store the start of the demo. Give it an unsuspicious name.
When the file is not present, create it and store the current timestamp. Bonus points if you encrypt it e.g. using Blowfish (symmetric is enough, since the key can be found in the binary anyway). Even rot13 or XOR would be good enough.
I would also add a marketing screen, i.e. when the file to start the demo is created I would also set a flag so the next time the user opens the GUI they are presented with a marketing screen "If you like the plugin buy it at yada-yada.com", which also returns when the demo period is expired.
Thatâs all you need and what you can do reasonably without running a server where you actually check licenses.
Thanks Daniel!
I donât want to limit the trial period, as that would imply registering an email, etc.
What I want to do is:
add a nag screen, as you suggested
limit to a single instance
no state load/save
noise or silence every minute or so
This is this last point for which I would love to get suggestions.
So far I have a sample counter and apply a different gain based on its value, and also reflect that state on the UI.
I would argue this is a licensing strategy, not a protection strategy. Theyâre very different things. It would be a shame to see somebody think theyâd have any chance of avoiding a crack with such a technique, so Iâm just trying to be realistic.
What you have already with simplistic sample counting and zeroing values is sufficient. That will stop 100% of people that canât analyse and influence a binary, which is 99.9% of people that have no interest in cracking. Trying to outsmart some of those with more skill than this but less skill than others than this is just a waste of your time. The techniques u-he employ are about the best Iâve seen without using Pace, but it costs them plenty of time and effort and their stuff gets partially/fully cracked anyway resulting in an endless cat and mouse game over the years.
We all go through this, thinking maybe there is hope of holding back the sea from part of the beach with some sandbags.
Make it very obvious what is happening. Using noise or silence would make the plugin appear broken, so most users will delete it and not bother again.
Instead I would use a real sample, e.g. record a tuning fork or anything that shows it is there intentionally.
There are plenty of very competent hackers though, so as mentioned, trying to be clever is a waste of your time. Also mentioned was the fact that the cracking crew will use a stolen CC to purchase your full version and crack that; so again wasting time trying to be clever protecting your demo version is yet more folly.
Really the only argument against any of these points is if you enjoy the challenge of trying to thwart them, just donât be disappointed when you inevitably fail.
Something to think about is that hackers probably wonât bother cracking a program which is fully functional except for a little nag screen. And regular users will eventually tire of the nag screen and happily buy the program. But limiting the functionality by adding some silence or noise immediately gives hackes an incentive to do what they are so good at.
I should have specified that the demo version would be a separate build
no state load/save
As your demo build isnât fully functional (as it doesnât contain any code to load/recall the plugin state) I donât think that any team will bother cracking it. So you donât have to worry about the noise/silence code that is in your demo build, that wonât make a difference.
Hackers will just try to crack the full version imo.