More copy protection...

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Rockatansky wrote: Sun Feb 03, 2019 4:04 am 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?

Post

Fender19 wrote: Wed Sep 11, 2019 4:16 pmCan 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.

Post

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.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

Rockatansky wrote: Wed Sep 11, 2019 6:38 pm
Fender19 wrote: Wed Sep 11, 2019 4:16 pmCan 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!

Post

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.

Post

matt42 wrote: Mon Sep 16, 2019 6:20 am 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?

Post

Fender19 wrote: Mon Sep 16, 2019 8:36 pmOnce 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!?

Post

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 Tue Sep 17, 2019 2:22 am, edited 1 time in total.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

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...

Post

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.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

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

Post

aciddose wrote: Tue Sep 17, 2019 2:27 am 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.

Post

Frantz wrote: Tue Sep 17, 2019 2:40 am 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:

Post

Fender19 wrote: Mon Sep 16, 2019 6:09 am 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.

Post

Fender19 wrote: Mon Sep 16, 2019 8:36 pm
matt42 wrote: Mon Sep 16, 2019 6:20 am 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.

Post Reply

Return to “DSP and Plugin Development”