More copy protection...

DSP, Plug-in and Host development discussion.
Fender19
KVRist
380 posts since 30 Aug, 2012

Post Wed Sep 11, 2019 8:16 am

Rockatansky wrote:
Sat Feb 02, 2019 8:04 pm
I would recommend investing the time to work out a serial number mechanism, one that doesn't count activations, doesn't require an Internet connection, doesn't require additional hardware, doesn't require additional software. Maybe it's crackable, most likely it won't take long. But the honest users will usually purchase your software anyway, so giving them a personal serial number and a little treat like maybe their name or a special badge on the user interface, or some extra features, will feel like a reward worth pursuing (and paying for) to them. Those who use cracks would probably not purchase the software anyway, they're just in it to collect and brag, click around a bit, upload their beats to SoundCloud and get a few clicks. There are always black sheep, serious commercial users that use cracks, but I guess that's what lawyers are for.
Can someone explain the general concept of how serial numbers are used to authorize plugins? AFAIK, all plugin code is "read only" - so how are these serial numbers being entered by the customer and stored WITH the plugin at runtime?

User avatar
Rockatansky
KVRist
331 posts since 3 Jun, 2017

Re: More copy protection...

Post Wed Sep 11, 2019 10:38 am

Fender19 wrote:
Wed Sep 11, 2019 8:16 am
Can someone explain the general concept of how serial numbers are used to authorize plugins? AFAIK, all plugin code is "read only" - so how are these serial numbers being entered by the customer and stored WITH the plugin at runtime?
Simply (he writes, knowing fully well that both macOS and Windows will do everything in their power and beyond to make this simple task a living nightmare for a developer) save a successfully verified serial number to file. When the plugin starts up, try to load the file. If it's not there, ask for a serial number. If it's there, try to load the saved serial number from it. Check the validity of the loaded serial number. If you feel like it, you can encode and decode the serial in the file, maybe using a machine ID or something as a salt. But the evildoers will most likely figure out what you're doing pretty soon, so why bother. Unencoded serials also make it easy to manually create keyfiles, which can be very handy at times, in a positive way. That's the still relatively easy approach. The frailty of this process lies in the fact that somewhere in your plugin, you'll probably have something like an 'if decodedSerial = whatItShouldBe' evaluation. This can relatively easily be reversed in machine code by crackers, so you'll have to think of a few tricks yourself to work around this.
Confucamus.

User avatar
aciddose
KVRAF
12318 posts since 7 Dec, 2004

Re: More copy protection...

Post Fri Sep 13, 2019 6:07 pm

There is a massive preference for keygens, so if you use a method to generate key files that isn't trivially reversible (like inverted public key signatures, used in most modern keys/serials) that will make writing a keygen impossible for the crackers.

This creates a lot of extra work for them to reverse every little bugfix release you make. They also need to fully distribute the crack or pre-cracked version of your software, since you can quickly make your demo download incompatible with their crack and even detect the crack and pop up a message like "hi! thanks for trying the demo! we've detected you're using a pirate key and would like to ask you to please consider supporting the developers of this software by *LINK* purchasing a license from our website */LINK*. if the demo limitations prevent you from testing the software adequately please contact our support for assistance."

This thread is filled with comments by Urs about how to switch on these detection methods and make them difficult to identify until specific dates or after specific actions.

Using a secure key method (private/public key pair cryptography) is a very good idea. Even though it is possible for crackers to work around your protection, it's similar to a garden fence.

Are you going to plant a field of peas with no fence and allow herds of rabbits and deer to eat it? Or put up a simple fence? Some deer might still be able to jump in, but the difference will be very significant. The certainty of you having your peas eaten down to the roots will drop from 99.99% to 10% or similar.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.

Fender19
KVRist
380 posts since 30 Aug, 2012

Re: More copy protection...

Post Sun Sep 15, 2019 10:09 pm

Rockatansky wrote:
Wed Sep 11, 2019 10:38 am
Fender19 wrote:
Wed Sep 11, 2019 8:16 am
Can someone explain the general concept of how serial numbers are used to authorize plugins? AFAIK, all plugin code is "read only" - so how are these serial numbers being entered by the customer and stored WITH the plugin at runtime?
... save a successfully verified serial number to file. When the plugin starts up, try to load the file. If it's not there, ask for a serial number. If it's there, try to load the saved serial number from it. Check the validity of the loaded serial number.
I understand the concept but not the implementation. Where are you storing the "valid" serial number that you are comparing to the serial number the user types in? Unless you are using web-based C/R of some kind the only other source is the plugin code itself, right? How do you embed serial numbers into that code without compiling unique .dlls/.vst3s, etc., for every serial number?

The "lightbulb" hasn't come on yet - can you please explain in more detail? Thank you!

matt42
KVRian
1139 posts since 9 Jan, 2006

Re: More copy protection...

Post Sun Sep 15, 2019 10:20 pm

I think the Urs scheme is to use a number of encryptions of the username, or whatever. Then when the plugin is loaded you check against one of these. Eventually this will be cracked, but you have numerous "time bombs" hidden in the code to break the crack at a later point in time. Some of these checks can be omitted and added to later releases, so theres no way they could be cracked in the initial release. If a crack user updates your plugin it will continue to function, for a time, before hitting a new time bomb. Urs had additional ideas on how to structure the code to make it more of a pain for the crackers to search for hidden checks.

Fender19
KVRist
380 posts since 30 Aug, 2012

Re: More copy protection...

Post Mon Sep 16, 2019 12:36 pm

matt42 wrote:
Sun Sep 15, 2019 10:20 pm
I think the Urs scheme is to use a number of encryptions of the username, or whatever. Then when the plugin is loaded you check against one of these.
OK, but I think I see a glaring flaw in the serial number protection method. Once a serial number has been issued to a user couldn't that serial number and associated plugin file be simply copied and distributed as a pair to create an unlimited number of "unlocked" versions?

Soundplex
KVRist
230 posts since 22 Sep, 2015

Re: More copy protection...

Post Mon Sep 16, 2019 12:46 pm

Fender19 wrote:
Mon Sep 16, 2019 12:36 pm
Once a serial number has been issued to a user couldn't that serial number and associated plugin file be simply copied and distributed as a pair to create an unlimited number of "unlocked" versions?
That's a question I've asked myself too a lot of times. Unless there's a new plugin version with the blacklisted serial in it or a license blacklist via online connection (in both cases the dev must be aware of the "crack" first) or some machine specific encryption, cracking would simply mean sharing the serial/keyfile!?

User avatar
aciddose
KVRAF
12318 posts since 7 Dec, 2004

Re: More copy protection...

Post Mon Sep 16, 2019 6:14 pm

That's not a weakness. What do you think people searching for warez will do when they read about a new "version 1.23 with feature X" but they can only find "version 1.21" with a key?

Suddenly regular feature upgrades start to drive sales. By providing regular improvements and upgrades, piracy is reduced. Splattering minor patches between feature upgrades is also essential... such that the pirate version might be "1.21", but "1.22" is the fixed version that doesn't randomly crash, and "1.23" is the only version with "feature X" that can load the new preset banks.

Now look at the way plug-ins are released and promoted today, do you think that's a coincidence?

As Urs has said, it's merely a question of the cost vs. benefit. It isn't about making it impossible to infringe software copyright, and it isn't about making it impossible to crack software. It's about making it slightly more difficult to do so than to purchase a valid license.

When you make it easier to download the warez version, unsurprisingly a lot of people are going to buy the full licensed version and then immediately download the crack to remove the stupid copy protection challenge-response or dongle or whatever else. With systems like bittorrent the consequence of that is increasing the availability of pirate versions - the more people downloading / using, the more available it becomes to others.
Last edited by aciddose on Mon Sep 16, 2019 6:22 pm, edited 1 time in total.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.

marzelli
KVRist
70 posts since 13 May, 2018

Re: More copy protection...

Post Mon Sep 16, 2019 6:21 pm

Waiting a short period of time until someone bought & shared it again. Keyfiles get "lost" or are bought via credit card scam. It's not like pirates suddenly start buying. No magic feature update (unless it's a monster synth with a jump from v2 to v3) could initiate that, it's just the mentality of the user you're fighting with.

Anyways a I'd stay away from a company that doesn't fix bugs just to do it over a couple versions or nags me with a new update every week...

User avatar
aciddose
KVRAF
12318 posts since 7 Dec, 2004

Re: More copy protection...

Post Mon Sep 16, 2019 6:27 pm

Just jump back to page #1 of this thread and read the whole thread so you can see Urs and others talk about the answers to all these redundant oft-repeated "questions".
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.

User avatar
Frantz
KVRAF
5267 posts since 18 Jul, 2008 from New York

Re: More copy protection...

Post Mon Sep 16, 2019 6:40 pm

There is an interesting discussion here:
https://stackoverflow.com/questions/599 ... icense-key

Fender19
KVRist
380 posts since 30 Aug, 2012

Re: More copy protection...

Post Mon Sep 16, 2019 8:42 pm

aciddose wrote:
Mon Sep 16, 2019 6:27 pm
Just jump back to page #1 of this thread and read the whole thread so you can see Urs and others talk about the answers to all these redundant oft-repeated "questions".
Why is "questions" in quotes? Is there an effective, customer-friendly solution somewhere here in this 22 pages of discussion? I don't see it.

Fender19
KVRist
380 posts since 30 Aug, 2012

Re: More copy protection...

Post Mon Sep 16, 2019 9:15 pm

Frantz wrote:
Mon Sep 16, 2019 6:40 pm
There is an interesting discussion here:
https://stackoverflow.com/questions/599 ... icense-key
Yes, I read that thread earlier. Good, clear explanation of the approach with the caveat that all of that effort basically provides ZERO copy protection! :roll:

lobanov
KVRist
408 posts since 7 Oct, 2005

Re: More copy protection...

Post Tue Sep 17, 2019 3:38 am

Fender19 wrote:
Sun Sep 15, 2019 10:09 pm
I understand the concept but not the implementation. Where are you storing the "valid" serial number that you are comparing to the serial number the user types in? Unless you are using web-based C/R of some kind the only other source is the plugin code itself, right? How do you embed serial numbers into that code without compiling unique .dlls/.vst3s, etc., for every serial number?

The "lightbulb" hasn't come on yet - can you please explain in more detail? Thank you!
One of the ways consists in cheking a serial "on the fly". You get user data (name, e-mail etc., you can keep this info in a file or in the registry) and verify a serial by computing it. If you reveal your algorithm (the whole algo) you will be keygened. But if you check one part (two or three symbols) of a key each version you will be safe. The crackers don't know the whole algorithm, they cannot make a keygen for future versions or create a comletely valid new key.

https://stackoverflow.com/questions/228 ... rification

Also it is possible to keep keys encrypted, keep hashes of them or use Bloom filter. But in such a case you need to keep the data for all your users in your program. Hashes and Bloom filter are more safe as they are not invertible, noone can get keys from them.

And yes, reread the whole thread, there are cool ideas here how to check serials.

matt42
KVRian
1139 posts since 9 Jan, 2006

Re: More copy protection...

Post Wed Sep 18, 2019 4:14 am

Fender19 wrote:
Mon Sep 16, 2019 12:36 pm
matt42 wrote:
Sun Sep 15, 2019 10:20 pm
I think the Urs scheme is to use a number of encryptions of the username, or whatever. Then when the plugin is loaded you check against one of these.
OK, but I think I see a glaring flaw in the serial number protection method. Once a serial number has been issued to a user couldn't that serial number and associated plugin file be simply copied and distributed as a pair to create an unlimited number of "unlocked" versions?
I guess the idea behind this approach is trying to turn threats into opportunities while also causing minimal pain to legit users. If a valid serial gets leaked and shared 40000 times then you now have 40000 people with a fully functional demo. At the next update you may be able to convert a small % of that into sales (depending how crucial the upgrade is).

Alternatively you could add a hardware serial number into the mix, but then you now have to administer authorisations and you have a greater chance of causing issues to your users. Can a small business be relied on to maintain such a system indefinitely, so users don't lose access to a favourite plugin when the upgrade their hardware.

Return to “DSP and Plug-in Development”