How to make Trial Plugins for 10 days

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:

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

alt text

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:

generate a set of serial numbers (not in HISE)
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.)
ship one of each of these encrypted strings to each paying customer
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...

Lindon

@simarsingh07 -- whoa these bots are getting pretty good now....but if this user id wasnt also busy trying to sell office furniture as well it might be more convincing...

Christoph Hart

I dont think I understand what you mean by this little side script

Nevermind, I just realized that as soon as the copy protection is done on the scripting layer and the hacker has access to the plain HiseScript code, it's game over anyway so tucking away the RSA key into binary code doesn't help.

Lindon

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

I dont think I understand what you mean by this little side script

Nevermind, I just realized that as soon as the copy protection is done on the scripting layer and the hacker has access to the plain HiseScript code, it's game over anyway so tucking away the RSA key into binary code doesn't help.

yes sure. That's why I'm suggesting encrypting the serial with the private key outside HISE, and thus only the public key is available in the HISE Script. But you are right this only defeats the keygen issue - not the "go change the HISE Script" method, still this would I think be a very useful addition to the normal serial system. I guess I should take a look at: Engine.decryptWithRSA()

d.healey

@Lindon

That's why I'm suggesting encrypting the serial with the private key outside HISE,

Couldn't you do that with the existing system at the time the user downloads the product?

Lindon

@d-healey -yes I'm sure I could...but why would I write a web server side activity to do something I do once at the creation of the product - where I create 1,000 serials(say) and encrypt each of them individually with the private key...

Plus this "create a key as you downland" approach really really doesn't work with 3rd-party distributors.

Christoph Hart

@Lindon You don't need RSA encryption for that scheme. If your line of defense is "when the crackers access the scripting code, then it's game over", then any simple "encryption" of your credential information is sufficient. You could eg. use the already existing Blowfish encryption in combination with a temporary file:

const credentials =
{
	"Product": "MySynth",
	"Version": "1.0.5",
	"Salt": 1234
};


const key = "adsnfv2140984";

const var f = FileSystem.getFolder(FileSystem.Desktop).getChildFile("Serial.txt");



inline function encode(objectToEncode)
{
	f.writeEncryptedObject(credentials, key);
	local k = f.loadAsString();
	f.deleteFileOrDirectory();
	return k;
}


inline function decode(encryptedData)
{
	f.writeString(encryptedData);
	local obj = f.loadEncryptedObject(key);
	f.deleteFileOrDirectory();
	return obj;
}



const secretData = encode(credentials);

const decryptedCredentials = decode(secretData);

Obviously you don't need to include the encode method in your plugin but use that to create "valid" encrypted data which will be decoded in your plugin and verified.

Lindon

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

@Lindon You don't need RSA encryption for that scheme. If your line of defense is "when the crackers access the scripting code, then it's game over", then any simple "encryption" of your credential information is sufficient. You could eg. use the already existing Blowfish encryption in combination with a temporary file:
const credentials =
{
	"Product": "MySynth",
	"Version": "1.0.5",
	"Salt": 1234
};


const key = "adsnfv2140984";

const var f = FileSystem.getFolder(FileSystem.Desktop).getChildFile("Serial.txt");



inline function encode(objectToEncode)
{
	f.writeEncryptedObject(credentials, key);
	local k = f.loadAsString();
	f.deleteFileOrDirectory();
	return k;
}


inline function decode(encryptedData)
{
	f.writeString(encryptedData);
	local obj = f.loadEncryptedObject(key);
	f.deleteFileOrDirectory();
	return obj;
}



const secretData = encode(credentials);

const decryptedCredentials = decode(secretData);
Obviously you don't need to include the encode method in your plugin but use that to create "valid" encrypted data which will be decoded in your plugin and verified.

err...no (I think) this uses THE SAME KEY to encrypt and decrypt doesnt it? Unless Im very much mistaken...(often the case) -if so then this is virtually useless....

I'm not saying "when the crackers access the scripting code, then it's game over", I'm saying: in order to "crack" my product you MUST change the source code in some way....

Having the smarts to read the key from the openly available source is a little different from having to modify the code FOR EVERY RELEASE.

I cant seem to get this across as a concept. So let me walk thru it...:

I encode 1,00 serials using a PRIVATE key
I build a version of my product , lets call it 1.0 this includes my standard authorization algorithm and the PUBLIC KEY to get to the serial.
Everyone who buys the product gets an encrypted serial.
The product reads the encypted SERIAL and decrypts it with the PUBLIC key - it then runs a check to make sure the serial is valid.
A hacker gets my product and starts to read the source code.
They DONT know the private key so they cant build a keygen
So they circumvent the serial decryption and authorisation and build a cracked version of Version 1.0 of the product
I release Version 1.1 of the product - it uses EXACTLY THE SAME serial system and encryption/decryption keys....so no effort from me beyond adding functionality.....
The hacker gets a copy of 1.1 - same as last time they have to hack the code AGAIN, and again and again and again.....for every release of the software.

Yes this isnt perfect, yes I will get hacked. But it solves two IMPORTANT problems:

I dont have to have some server side generator-which would pretty much exclude me offering the product through the many 3rd-party distributors
Valid legal users of Version 1.0 can simply download Version 1.1, 1.2, 2.4, 3.7 etc. etc. and use their existing encrypted serial number.

If I keep a high enough cadence for releases - hackers will always be chasing their tail...

So the VITAL part of this is a public/private key pair system.....such as RSA

ustk

@Lindon I'm afraid you are focusing not on the main weakness here. I mean, I understand you don't want to fight against all possible hacks, but they don't even need to think about cracking the binary since any key can unlock it (because you can't change the RSA pair if you want the users to unlock futur versions as you said)
So in the end, it seems that you offer the easiest hackable solution, which is key sharing.
To me it adds more work on your side than the simple copy protection system of the Hise tutorials, but with the exact same weaknesses.
You effectively prevent a keygen to be developed, but what's the point if keys can be shared?
All of this unless I'm wrong of course…

Lindon

@ustk
really, I give up.

How to make Trial Plugins for 10 days

25

1.8k

10.4k

90.7k