How to make Trial Plugins for 10 days

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

17

1.8k

10.4k

90.6k