More copy protection...

[Kickflip]

Ok cool, will investigate stl/boost first. I'm using the crypto++ library for now, will see if there's anything that looks appropriate in there as well.

[Vertion]

[Vertion]

Mental Acrobatics:
If you want to combine a flurry of complex serial numbers into a single mesh, run a few of these over the list of serials.. and output a function.. tada.. when you run a few of them concurrently on the same data set, the error rate quickly moves to zero, storing a potentially larger number of serials.

https://en.wikipedia.org/wiki/Bloom_filter
To offer my own improvement upon this algorithm .. I call the Analog Bloom Filter.. which essentially stores values to the max or to the average by recording onto per input array accessible via remapped indexing from 0.0 to 1.0. But that into Machine Learning waters...

[aciddose]

It really doesn't make the least bit of sense to use a hash or Bloom function to throw out useful data unless there is a reason to do so.

It makes sense to pack data into a serial number using a specific alphabet, but only where you aren't discarding any useful data.

There is absolutely no reason to rely today upon hand-typed "serial codes" when you can trivially use a key file that is multiple mega-bytes in size. There is absolutely no limitation on storage or bandwidth that would ever necessitate such.

[Richard_Synapse]

Forcing users to hand-type makes no sense ihmo (we allow copy/paste, very quick).

Generally speaking, however, one must find a way to prevent many users from using the same key (or keyfile). This is really the weak link of any protection. There is little benefit in knowing that the keyfile of "John Doe" went public, if that person does not even exist or never ordered your software to begin with (e.g. stolen CC).

Richard

[Urs]

There is little benefit in knowing that the keyfile of "John Doe" went public, if that person does not even exist or never ordered your software to begin with (e.g. stolen CC).

It's a very good thing in the long run, if you have the time and patience.

We do not blacklist leaked serials immediately, we blacklist them, say, in December (x-mas time) and when certain things happen (certain presets, certain settings, certain notes patterns, certain mouse clicks). So after about two or three years people pretty much only have these versions with the leaked serials. As these are uncracked binaries, we just switch the normal demo mode back on.

The result is quite stunning. A polite reminder to "upgrade" to the full version does work for many people.

[PurpleSunray]

I'm wondering why nobody jumped into the DRM-train yet for protecting plugins.
The problem you are struggling with is a very common one when it comes to digital rights management.
I'm not saying you should run a Widvine or FairPlay infrastructure to deliver & authenticate your plugins.. but stuff like creating device identifiers with long-term persistence, protect keys from inspection or misuse, offline authentication, managing licenses (i.e. only allow one installation at a time) , ect. pp has been solved by Google (Widvine), Apple (FairPlay) and Microsoft (PlayReady) at least already and they all came up with a quite simliar concept (so if you want to invent it again, it will also be simliar to exsting solultions I suppose, so no real need to re-invent).

[Vertion]

We do not blacklist leaked serials immediately, we blacklist them, say, in December (x-mas time) and when certain things happen....

Not sure what you put in those soundpacks, I tried to load a preset with a demo mode Ace and my computer caught a fire, sparks flying out of the power supply, I didn't even crack the program.. I believe that gets me one free Ace serial according the terms of Urs x-mas list for all his favorite customers and free-spirited commentators.

[aciddose]

I believe you will find that warranty for spontaneous combustion, struck down by lightning bolts, boiling hot lava, rivers of blood and gore and other "acts of god (including vengeful god)" is disclaimed in the warranty/disclaimer sections of the agreement.

[Vertion]

"acts of god (including vengeful god)"

Urs may have smited my computer using only his mind, but I wouldn't go that far.

[FabienTDR]

The result is quite stunning. A polite reminder to "upgrade" to the full version does work for many people.

I've found that this type of politeness dramatically reduces the ROI of copy protection.

[plusfer]

About the trials/expiration dates, if the user changes the system date, he will be able to continue using the plugin.
Do you read the date from the system? or use some other method?

[Urs]

About the trials/expiration dates, if the user changes the system date, he will be able to continue using the plugin.
Do you read the date from the system? or use some other method?

You can count samples processed. Then you can count seconds, hours, days, all without accessing the system date. If, after 5 days or so of processing, the system date hasn't moved, I guess you know what happened.

Likewise, count the times the system date of a new session is more than a day or two before the last. Cancel the demo period if it happens twice or so.

[plusfer]

You can count samples processed. Then you can count seconds, hours, days, all without accessing the system date. If, after 5 days or so of processing, the system date hasn't moved, I guess you know what happened.

Likewise, count the times the system date of a new session is more than a day or two before the last. Cancel the demo period if it happens twice or so.

That sounds good,
Now I wonder, someone with some knowledge can find the hidden files where this data is saved and reset it.
With these "apps to crack apps", is it possible to trace all the file opens?
I imagine several files, encrypted and hidden, but there is always an initial state that the cracker can capture.

[Urs]

You can count samples processed. Then you can count seconds, hours, days, all without accessing the system date. If, after 5 days or so of processing, the system date hasn't moved, I guess you know what happened.

Likewise, count the times the system date of a new session is more than a day or two before the last. Cancel the demo period if it happens twice or so.

That sounds good,
Now I wonder, someone with some knowledge can find the hidden files where this data is saved and reset it.
With these "apps to crack apps", is it possible to trace all the file opens?
I imagine several files, encrypted and hidden, but there is always an initial state that the cracker can capture.

Well, it's two different things. User resetting demo period date and cracker cracking things. I guess one common crack is to crack the date check. Hence, if you do another date check based on samples processed, you catch that too.

A cool trick to store such information is in presets. If you manage to detect when an instance is saved with song, you can embed and retrieve the information from the preset set when a sessions is reopened. But you would neglect it if it is set by loading a preset from hand.

Thing is however, if you want to keep thing user friendly and unintrusive, you'll end up being cracked. Hence keep you symbol files (but goddammit strip them out of your release binaries), do a binary compare between original lib and cracked, and figure out what symbol was cracked. It's a quick and easy way to figure out what angle/vulnerability they used. Then, for next update, add a delayed check or two for exactly that angle.

Often enough, people (not necessarily crackers, but also just some random script kiddies) apply the same crack to the updated version and upload it to warez sites. That's when you pwn them.

Maybe they fix it, maybe they don't. If they do, you have a new vulnerability to catch up with for the next update.

After a few years the warez sites are full of working and non-working cracks. After some time people will realise that working cracks are old and current versions with great features have to be paid for.

It's a process. It gets better over time. Until one day:

DemoVoice.png

Yes, hell we do!