More copy protection...

[audiothing]

My two cents...

I think that the most important step we can take to delay cracks is to make each version, each build, each format of a plugin, different.

If you use the same exact methods and variables for your copy protection in each version and format of your plugins, then the cracker’s job is going to be very easy.

If you have different methods, variables, time bombs, scrambled code, junk code, multiple obfuscation techniques, then, each time you release a new product or new version, the cracker needs to crack 7 different formats: macOS (VST2, VST3, AU, AAX), Windows (VST2, VST3, AAX).

This won't work if you have a leaked license or if you use a serial that can be easily keygenned.

RSA is the perfect opportunity as they'll never attempt to crack a 1024bit key (at least for now ), so they need to either replace the public key or bypass the copy protection method.
And that's where you can do all kinds of code obfuscation techniques and checks.
The copy protection method should do multiple things, even some light DSP if necessary. Dispatchers with array aliasing, opaque predicates/values, etc. are great, but they need to be different at every version/format.

We basically use some of the techniques that malware use to hide from anti-virus.

We "scramble" our copy protection source code directly every time a release build is performed. It takes a while to get something like that, build times are longer, and debugging can be a bit more tricky, but for us, it was worth it. The latest working cracks for our products are nearly 2 years old. Six new products have not been cracked (yet), which never happened before.

[Urs]

Re. Singleton

That's cool as long as the dispatcher lives in a single method. You don't want to have separate addresses to jump into because then it's easy to map out where calls to the various things you want to do come from. It's about creating a single pivotal address that is nondescript (aka "everything") which is used all over the executable so that non of those places tell the cracker what these places actually do.

[Music Engineer]

Sometimes crackers add little vanity pee marks, such as altering a string.

i once considered to exploit that vanity by striking a kind of covert deal with cracker by inviting them to alter a string that is displayed on the screen. like, a legally licensed version would display some sort of "Licensed to: ..." string on the GUI, and some hidden string in the binary invites the cracker to change that into a "Cracked by: ..." string. i would suppose that for most (semi)serious users, having such a blatantly obvious sign of a crack displayed all the time would be enough to deter them from using a crack. so far, i never actually implemented that, though. of course, such a scheme would require the cracker to cooperate - but why would they not?