How to make Trial Plugins for 10 days

[orange]

@Casey-Kolb I haven't used Tracksaur yet but I've heard good things about them.

Regarding the cracking, according to my experience I am 100% sure that the hackers can see the source code of the plugins clearly. They can do it very quickly with decompiling the plugin (it requires deep programming skills) and then read the source code and find an optimum way to crack.

[crd]

@orange How does that grant them access to download sample content? I see how it's easy to grab the registration code for the vst but if you are using a download manager or something, isn't it possible to keep them from downloading the samples?

I know the pulse downloader talks about having some extra steps to protect against piracy but I have no experience with it.

[Casey Kolb]

@crd said in How to make Trial Plugins for 10 days:

@orange How does that grant them access to download sample content? I see how it's easy to grab the registration code for the vst but if you are using a download manager or something, isn't it possible to keep them from downloading the samples?

I know the pulse downloader talks about having some extra steps to protect against piracy but I have no experience with it.

Someone just uploads the samples to the torrent sites. That's the easy part I think.

@orange said in How to make Trial Plugins for 10 days:

@Casey-Kolb I haven't used Tracksaur yet but I've heard good things about them.

Regarding the cracking, according to my experience I am 100% sure that the hackers can see the source code of the plugins clearly. They can do it very quickly with decompiling the plugin (it requires deep programming skills) and then read the source code and find an optimum way to crack.

Very spooky! It doesn't seem worth it to try to outsmart them. Removing the links seems worthwhile though to prevent the average user from finding the cracks.

[orange]

@crd said in How to make Trial Plugins for 10 days:

@orange How does that grant them access to download sample content?

Like Casey said, I think samples are the easiest part. They even buy plugins before cracking, so grabbing samples is easy.

@Casey-Kolb

Very spooky! It doesn't seem worth it to try to outsmart them.

Look at this, they haven't been cracked since 2019. https://www.kvraudio.com/forum/viewtopic.php?t=472847&start=375

They say:

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

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.

There are a few companies that haven't been cracked. But unfortunately 99% of the rest are being cracked.

[Casey Kolb]

@orange I remember reading that post a while back. Really valuable info. I'm not even sure how I'd begin doing that for our copy protection system, but seems worth a shot.

[crd]

@orange it's so bizarre for me to think of someone spending $100 + dollars just to upload it to a torrent site

[d.healey]

@crd People make money by sharing content, so $100 is an investment. Most crackers aren't uploading directly to torrent sites - someone posted a breakdown of the warez lifecycle a while ago either here or on VI-Control, I can't remember.

[Lindon]

If I'm not mistaken(and more than willing to be corrected) if HISE had a public-private key decyption function (for say RSA) then we could use private keys to generate distributable serials and the function would decrypt them ready for validation..getting us around the keygen problem....

[d.healey]

@Lindon I don't know the details but I think this is how the new-ish unlocker system works:
https://docs.hise.audio/scripting/scripting-api/engine/index.html#createlicenseunlocker
https://docs.hise.audio/scripting/scripting-api/unlocker/index.html

Still can be cracked of course, but as you suggest it should eliminate the keygen issue.

[orange]

@Lindon RSA is a great way to make it harder, but I think code Obfuscation is also needed with it. Other than that, this is not a 100% escape. Even with code Obfuscation, it's not.

Let me give you an example. I embedded a license system into one of my plugins under a bundle name that this bundle hasn't been released yet. So nobody knows the bundle name but me, right?

Also there was a 32 char PIN algorithm that is a combination of the Machine ID and constant values for the encryption.

Guess what? R2R cracked it after 2 weeks of the release, with a not-released bundle name Keygen generator with encrypted files! That is the conclusive evidence that they can clearly see the source code. Other than that, they wouldn't know this information. They don't even try to unlock the encryption key, because they can see the algorithm of the PIN.

Also they don't crack the plugin, they crack the activation system that plugin works on.

[d.healey]

@orange said in How to make Trial Plugins for 10 days:

I think code Obfuscation is also needed with it.

Security through obscurity is rarely a good idea, and even less so with an open source system.

[orange]

@d-healey Obfuscation is not the total one way security, just like RSA. Multiple ways should be combined like the "Audio Things" did.

Besides, almost everyone uses JUCE, so like all the things in JUCE, any generic encryption / licensing system will be known well by everybody.

[Lindon]

@orange - yes but a bit no too...

So lets say we have an authorisation system in the plugin that uses a serial, so yes a hacker can see the authorisation code and reverse engineer a set of authorisation codes ( and even build a keygen)...

So now we encrypt the serial number with a private RSA key...and decrypt it (in plain view to the hacker) using the public key. So now they need to generate valid serials, but they dont have the private key so they cant.

Sure they can alter the code base to work around the authentication, but this is harder than simply generating a set of valid keys....

[Lindon]

@d-healey - great! - now all I need is some sort of guidance how to use this new fangled thing.

[d.healey]

@Lindon said in How to make Trial Plugins for 10 days:

@d-healey - great! - now all I need is some sort of guidance how to use this new fangled thing.

build failed with copy protection enabled

@ustk You don't need to define those preprocessors when building HISE, just put them in your project_info.xml. HISE itself has a dedicated "development" unlo...

Forum (forum.hise.audio)

This JUCE doc might also be relevant - https://docs.juce.com/master/tutorial_online_unlock_status.html

[Lindon]

@d-healey yes I see.. a server side system, I was trying for something WAAAY more simple than this... a simple decryption function using RSA...where I pass it an encrypted serial - and it passes me back the serial...

[d.healey]

@Lindon said in How to make Trial Plugins for 10 days:

@d-healey yes I see.. a server side system, I was trying for something WAAAY more simple than this... a simple decryption function using RSA...where I pass it an encrypted serial - and it passes me back the serial...

I think you could still do that. Instead of a server providing a key file you allow the user to manually select a key file that you've provided to them.

[orange]

@Lindon said in How to make Trial Plugins for 10 days:

So now they need to generate valid serials, but they dont have the private key so they can't.

Are you sure? :) There are tons of software that have been cracked using RSA key.

Sure they can alter the code base to work around the authentication, but this is harder than simply generating a set of valid keys....

Yes a bit harder, but... as even the iLok has been cracked, nothing to mention here :)

I think multiple options should be combined like "Audio Thing" did. Obfuscation, RSA, time bombs, different methodology for each version...etc.

[Lindon]

@orange - yes everything is crackable - it depends on the effort tho right?

[ustk]

The server-side RSA encryption is a necessary basic for any serious protection, everything else is crackable in days or so. It prevents the creation of a keygen because the private part is secure (unless they put their hands on a quantum computer...). Instead, they have to release a crack, which requires more work, and it's not always easy if the locks are spread everywhere in the code (this is where obfuscation makes sense, but it isn't mandatory). On the contrary, if you have only one statement to unlock the product, it's dead easy to force.
The unlocker does just all we need (without the obfuscation part).

@Christoph-Hart I have a suggestion (if doable, and I don't know if it's JUCE dependent...) to enforce the actual unlocker that wouldn't be wise to talk about publicly...