I’ve been thinking about how to create a demo version of my plugin that offers limited functionality without requiring a license. One idea is to incorporate a periodic burst of noise into the output signal to serve as a restriction.
While the most straightforward approach would involve distributing a single plugin and utilizing a license checker to eliminate the added noise upon successful license verification, I’ve observed that many plugin manufacturers opt for an alternative method. They distribute two versions of the plugin: a fully-featured one that, for example, completely bypasses the sound when not activated, and a separate demo version that includes the periodic burst of noise and cannot be activated.
I’m curious about the reasoning behind this choice.
My assumption is that it’s motivated by security concerns. By maintaining the same binary for both the demo and fully-featured versions, eventual crackers could potentially deactivate the license check and distribute a cracked variant.
I do have a doubt, though. If someone possesses the skills to disable the license checks, wouldn’t they also be capable of removing the periodic noise from the demo version of the plugin? Unless, of course, the noise addition is not performed in a straightforward way, but the same is valid for the license checks.
Am I missing something? What’s the safest way to make a demo version of a plugin?
If there is a license checker in the binary, hackers might more easily find where that checking is done vs you just having some randomly triggered noise or silence period in a separate demo binary (especially if it’s hard to know when it will occur)… however whether it’s worth the bother is debatable. In some cases you could argue that hacked/cracked copies actually are helping to promote your product… as mentioned in the presentation, the ideal situation is that you add some kind of feature limitation license double check that only appears after a long time of usage and would hopefully push people with cracked copies who really are regularly using the plugin to opt to eventually get a legitimate license.
Thank you for your answer. I’m familiar with that presentation and I took a lot of inspiration from it to implement my license checking scheme.
Still, it’s not clear to me how a simple line that adds some noise to an audio buffer is harder to identify/remove (from a demo only binary, without license checking) with respect to different license checks performed in different places in the unique binary solution.
The same situation can occur with the “feature limitation license double check that only appears after a long time of usage”. How harder would it be, with respect to the aforementioned solutions, to identify/disable the counter increment defining the long time of usage?
Having a separate demo and full version is less annoying for end users since they don’t need to fiddle with license keys. You also don’t need to manage license keys on your end, or provide support to people who lost their keys etc.
I think the opposite:
If they have to fiddle with license keys anyway, it is cleaner to have one installation.
You send an update and a user mixes up the demo install and the full install…
I’d be inclined to agree, a single download is easier/less frustrating for end users IMO.
As for a separate demo only mode build being less ‘hackable’ this might be because you could avoid having a specific time/UI action where the license is checked, and you could have multiple counters/flags accumulate at random times and add multiple checks at various locations/times for various combinations of those to then introduce noise or silence at various points in the processing…or you could just use multiple gradually accumulated values as volume controls for noise generators that are always active (but initially silent) in several locations in your processing (rather than some binary switch and only one specific part of code that adds noise)… but I think a bit too much hassle to maintain an extra build personally - and besides, your paid for licensed version would probably just get hacked anyway (even if payment is required before download is available, somebody will probably do it) - better to focus on securing that build as much as possible with the techniques mentioned in the presentation. Then there’s the freeware/buy me a coffee model - can work for some.
you could have multiple counters/flags accumulate at random times
Yeah, the more complex the noise addition, the harder it is to crack, of course, but the same is valid for the single binary solution, that’s why I wondered if I was missing anything.
I think a bit too much hassle to maintain an extra build personally
Kind of, nothing that I didn’t manage to handle with a build script, cmake and some preprocessor directives. I was more interested in the reasons behind it and why the 2 binaries option seems like the solution most are opting for.
I guess the main point is that your demo only build won’t have a license check… which apparently is easy to detect with the hacking/debugging tools, and the adding noise thing with multiple triggers is harder to hack.
The idea is that you wouldn’t use a license code in this case. Someone pays, they get a download link to the full version and that’s it. (You still may want to create a unique download link for everyone so that if a link gets shared you can disable it.)
(My philosophy is that if this is your first plug-in, your biggest problem isn’t piracy but obscurity: no one knows about your plug-in. Piracy can actually be beneficial here as it does some of the marketing for you. Rather than spending a lot of time on trying to make life difficult / more fun for pirates, I’d suggest spending that time and money on marketing and promotion instead, and on giving honest users the best possible experience. Not really what you asked for, but I thought I should mention it anyway. However, if you’re an established company, spending money to combat privacy might be worth it.)
Any code that uses a license check or demo timeout will ultimately be compromised. Your safest route to avoid the demo being tampered with is to distribute two versions, the demo having some important functionality removed such as session save/load code.
Whatever you do the retail version will be acquired “legitimately” and cracked though so all you’ll end up with is two versions to maintain.
See various other threads about how to protect your work, tl;dr you can choose between home made techniques that will be cracked quickly or commercial routes that are expensive but usually provide protection for much longer.
My experience tells that this is only true if you manage to release an interesting update later that is not cracked quickly. This is not an easy feat. Otherwise, it is true that it helps to promote it but everybody gets a free copy so your revenue plummets and you lose potential customers. Piracy can mean the end of your product if you don’t have the stamina or time/money left to invest in the aforementioned update.
In my opinion protecting the full version has higher priority and if your demo doesn’t include the license checks, the cracker could use a diff tool to find those by comparing demo and full versions. I don’t know how is easy is that though. On the other hand, you can always add hard-coded parts to the demo to limit it even after they remove the license checks.
It is also important to weight the time you will have to spend with support if you ask for a key for the demo version. I always get emails because they haven’t received the license or they have lost it.
The idea is that you wouldn’t use a license code in this case. Someone pays, they get a download link to the full version and that’s it.
Yeah, that’s not the situation I described but thanks!
My philosophy is
I have no idea why users tend to go philosophical every time a technical license manner is brought up. There are many other posts that are a better place to discuss philosophical matters
Your safest route to avoid the demo being tampered with is to distribute two versions, the demo having some important functionality removed such as session save/load code.
That’s what I thought. Periodic noise injection might be easy to spot, but if features are completely removed from the demo version, there is not much one could do about it, if not reverse engineer the whole thing and re-write it with the needed features.
Whatever you do the retail version will be acquired “legitimately” and cracked though so all you’ll end up with is two versions to maintain.
Sure, I agree. I guess it’s still a step more to perform for a cracker with respect to simply downloading the demo binary from the website. As of now I can simply add a -d Demo to my build script arguments and have the demo version generated instead. Hopefully maintaining won’t be much more painful than that.
Because the asker of the question might be trying to solve the wrong problem, and so it can be useful to try and get them to look at it from a different angle.
However, if you’re an established company, spending money to combat privacy might be worth it.)