How to make Trial Plugins for 10 days

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

[Lindon]

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

@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?

Yes you are right but the crucial difference here is that we are forcing the pirate to modify the code of the plugin, something they dont have to do with a keygen - with a keygen hack they ONLY need to distribute the keygen - they tell their "clients" to go download the product form the developers own page.

I get a weekly report about downloads from my site - and one of my products, that has a keygen available for it far outstrips all other downloads and I havent sold a single copy of this product in over 6 months. Guess who I think is downloading my product? Hint: not genuine potential buyers...

So being forced to hack(change) my code is the first step to making it harder for pirates and easier for me. I can add functionality and release new versions (without changing the authentication process in any way) and the pirate has to re-hack my code every time...

As to the call-home problem - three reasons:

1. A very large percentage of your potential customer base (sadly) dont trust you, and when you call-home in your product they are suspicious of what you are sending back about their machine...

2. A very large percentage of your potential customer base worry about what happens if you go out of business - your server goes away and they can then no longer use a piece of software they've purchased.

3. A very large percentage of your potential customer base worry about the scenario where they are "on a job" and the internet fails or is unavailable - they cant use the product they purchased in that case. Sure you can defer and have intermittent call-home - but the principle applies.

[ustk]

@d-healey said in How to make Trial Plugins for 10 days:

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

You just do that only once at first authorisation, not every time. Many companies do this, including @Christoph-Hart
I'm not talking about massive data collection every time you use it, it is just an authorisation process. Of course, everyone sees what is best for themselves. I am personally against data collection we see everywhere, but I don't think plugin developers are using my computer ID for marketing purposes... You already sent much more just by the process of buying something online.

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.

I don't mind the process of activating online for offline machines. Without this, you don't even need any authorisation system since it'll be hacked in no time. (except maybe @Lindon's one which seems to overcome this)
Nothing stops you from selling more than one activation so users can activate a mix of online and offline computers.
Also, for offline users, they need to use an online machine and send the binaries to the offline one, I think the worst is done and activating doesn't add much stress. Offline users know they'll have to struggle a bit more.

@Lindon Yep, this is where your solution seems to be a good one!
EDIT: Except that instead of making hackers to struggle with a keygen, they just have to share a legit license (until you change your code, but this applies to any kind of protection)

There's just one thing I might not have explained clearly enough, I am not talking about calling the server every time but only at authorisation time. I wouldn't have a product that calls the server every time I use it and I won't trust it either
On top of that, I much prefer making a manager that takes the process of authorising the products, so plugins don't need any connection. I don't like when my plugins are trying to connect (even only once), but I am not against deciding when it happens by launching the company's product manager app. It is much more trustable IMHO

[d.healey]

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

You already sent much more just by the process of buying something online.

I hate this too :D we should be able to buy things anonymously.

Without this, you don't even need any authorisation system since it'll be hacked in no time.

As far as I know none of my HISE plugins have been cracked ;)

[ustk]

@d-healey We should be able to buy anything for free

I cross my finger your protection holds for long :)

[d.healey]

@ustk

I cross my finger your protection holds for long

[Christoph Hart]

A few things:

• A RSA key in HiseScript doesn't make sense. The scripting code is not encrypted in any way - it's base64 encoded plain text embedded into the binary, so it's much more easy for a cracker to modify HiseScript code than actual binary code. The ScriptUnlocker class implements the entire copy protection in C++ (with a properly obfuscated RSA key in the binary and varying places where it checks for the serial). On the scripting layer you just ask unlocked.isUnlocked() in order to show an activation window, so the HiseScript code contains little to no sensitive information or vital protection logic.

• The "private" in "Private RSA key" means that this key must not ever be leaked or the entire encryption system is compromised so putting both the private and public key into the script is pointless. Usually the private key is used for encrypting stuff and the public key (which might be leaked) is only useful for reading stuff. This is why a robust copy protection system needs to hide the private key to the server, which cannot be hacked.

• So now that we know that the server needs to hold the private key and we need online authorization I wouldn't care about data privacy at this point - there is no additional data being gathered than a random system ID. What is a super big no-no of course is requiring an internet connection and calling home each time the plugin is opened. This is why there is a license key file that is stored after the first authorization so there is no unasked internet request in the default use case.

@ustk yeah sure please send me a PM with your ideas.

Oh and a little addition from my experience:

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.

We have removed offline authorization from PercX (it was there in Hexeract but was used maybe once or twice) and have not gotten a single request for offline authorization there.

[Lindon]

@Christoph-Hart well I think this isnt what i'm talking about, I'm not suggesting we RSA encrypt the scripts...which is where we might be getting confused, all I want to do is:

1. generate a set of serial numbers (not in HISE)
2. RSA encrypt each of them using a private key ( again not in HISE, and so the private key does not end up in the script - it stays private.)
3. ship one of each of these encrypted strings to each paying customer
4. in HISE - get the shipped "string" and decrypt it using a function and a public key

• if the serial number resulting then passes authorisation, then I can be reasonably confident that its a valid authorisation code.

I think this system makes it pretty impossible for pirates to build a keygen crack for products - sure they can alter the HISEscript code - but thats harder and more time consuming as I role out versions at some level of frequency.

So the only thing we are missing from this (weak) authorisation method is a function in HISE that decrypts a string using RSA and a public key....

[Christoph Hart]

@Lindon I see various lines of attack here:

• purchase it with a fraudulent credit card, then ship the key with the binary as there is no activation limitation.
• make a keygen with another RSA pair, swap the public key against the public key of the "rogue" pair (which is pretty easy because it's plain text readable in HiseScript) and distribute the cracked binary with the keygen.

What might increase the security on the second case is if you could use the RSA key that's embedded for the ScriptUnlocker without the actual unlocking features. Then you could just use Engine.decryptWithRSA() and Engine.encryptWithRSA() without including the RSA key in the script code. And you could write a little side script that you'll run inside HISE for the actual key generation and it automatically uses the proper RSA key pair.

[Lindon]

@Christoph-Hart said in How to make Trial Plugins for 10 days:

@Lindon I see various lines of attack here:

• purchase it with a fraudulent credit card, then ship the key with the binary as there is no activation limitation.
• make a keygen with another RSA pair, swap the public key against the public key of the "rogue" pair (which is pretty easy because it's plain text readable in HiseScript) and distribute the cracked binary with the keygen.

What might increase the security on the second case is if you could use the RSA key that's embedded for the ScriptUnlocker without the actual unlocking features. Then you could just use Engine.decryptWithRSA() and Engine.encryptWithRSA() without including the RSA key in the script code. And you could write a little side script that you'll run inside HISE for the actual key generation and it automatically uses the proper RSA key pair.

Yes I know the "stolen credit card" scenario isnt catered for in this - but then again - I cant think of a "dont-call-home" solution that does account for this...and you are right its probably a trivial crack of the code to swap in their own key pair...I dont think I understand what you mean by this little side script...