How to make Trial Plugins for 10 days

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