How to make Trial Plugins for 10 days

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

[Lindon]

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

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

I dont understand why the server needs to be involved interactively, its generating a serial number and encypting it with a private key (and I understand uses the machine ID too, so its extra secure) but if I just went and generated 500 serial numbers and then encrypted them with a private key - and gave one to each buyer how is this "considerably" less secure? Sure they buyer could give the encrypted serial away but thats not the problem we are trying to solve here, we are trying to solve the KeyGen problem no?

[ustk]

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

but if I just went and generated 500 serial numbers and then encrypted them with a private key

because it's not dynamic, it's even easier than preventing keygens, since they effectively just have to leak one key for everyone... Even if you make your own decryption in the binary, a key is something static so it'll work everywhere. The remedy is then to encrypt a dynamic element (so a machine id or whatever), and this can only be made on the server.

[ustk]

@Lindon

its generating a serial number and encrypting it

Nope, you send a dynamic element that you encrypt so only the computer in question can decrypt it (well, in fact everyone can decrypt it, but it is no use. I should have said "use it"...). There's no point in generating a key on the server because it would work with any machine once it is shared... You need something that is proper to the computer you want to unlock

[Lindon]

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

@Lindon

its generating a serial number and encrypting it

Nope, you send a dynamic element that you encrypt so only the computer in question can decrypt it (well, in fact everyone can decrypt it, but it is no use. I should have said "use it"...). There's no point in generating a key on the server because it would work with any machine once it is shared... You need something that is proper to the computer you want to unlock

--you are solving a problem I am not trying to solve, and your solution calls-home - something MANY MANY users object to.

[ustk]

@Lindon Sorry if I don't understand well...
Effectively if you encrypt your keys and decrypt them in the binary for authorising, I guess it is ok and no one could make a keygen for those encrypted keys. That being said, a simple crack to bypass the decryption part would allow making a keygen just for generating the original keys. (I imagine you want your own algo that analyses the original key after decryption)

your solution calls-home - something MANY MANY users object to.

Any idea why?

[d.healey]

@ustk

Any idea why?

Would you like to inform the manufacturer of your car every time you use it? ;)

Lots of users, including me, are opposed to sending any information to anyone unless absolutely necessary. It is necessary for DRM systems to be proprietary, as such it is impossible for a user to know what data the software is collecting and sending to a server. One way to avoid the massive trust issue this creates is to not send any data ever.

On a practical level some users like to work on an offline machine and installing on an online machine just for licensing is annoying, also if the license is locked to the machine used for registering then they can't use it on their offline machine at all.