Different Encryption Types in HISE?

[Casmat]

@aaronventure yeah I don’t know if HISE encodes their strings (edit: yup it doesn’t, thanks @d-healey), but having a checksum would also be pretty minor? Of course, it creates another roadblock for ppl like r2r to change in the decompiler, so yup, definitely could help, but could be somewhat removed easily in cracks. For my offline auth purpose, im planning to store a license.dat file with the rsa key in their and check that upon loading (it is also good to have random checks on the license on various components of the plugin, such as save preset, to make it harder for crackers to crack)

[Christoph Hart]

I think HISE encodes all the strings

It just uses Base64 encoding and zstd compression so nothing that should have any cryptographic value.

But guys, I think we're right in the middle of a "just one more lane bro" problem. The basic cryptography is there to prevent naive copying without license checks but as soon as a cracking crews start working on a crack it's game over and I don't see a reason to go down that path trying to make their life harder. If you have that desire for copy protection, you can implement the iLok SDK or whatever, but that's as far as my cryptographic ambitions go.

[Casmat]

I have a question, how would someone go about HWID in an offline authentication scenario such as mine? Is their a way or is it necessary to call home once to register the hwid

[Christoph Hart]

@Casmat Sure, just fetch the ID, write it to a XML or JSON file and have the user upload this. If you're smart about the server implementation, it takes the same route as the online activation but lets you download the response (aka license file) which the user can then take back to their offline system.

[Casmat]

@Christoph-Hart yup, it can help to make their lives harder but if they are dedicated enough (which is definitely true) they’ll crack it eventually and note it for future releases making it pointless (unless we rotate the obstacles each release which is a worthless hassle). The main idea of copy protection is to stop keygens, and having a rsa 2048 or ed25519 :beaming_face_with_smiling_eyes: solution would pretty much solve that. If one makes an online authentication system, then it’s pretty much game over for keygens, hence you don’t see adobe photoshop keygens anymore

[Christoph Hart]

If one makes an online authentication system, then it’s pretty much game over for keygens, hence you don’t see adobe photoshop keygens anymore

If you make a "must-call-home-to-use-the-plugin" copy protection you'll get the righteous wrath of your legit user base and anything else can be bypassed with a crack.

[Casmat]

@Christoph-Hart no one likes adobe haha, people have supported cracking of their software, but with the outrageous pricing, I can see where they’re coming from haha.

Im not planning on making an online system as of now, due to time constraints, but is it frowned upon to send the hwid once to home and then another time when deregistering it, instead of making the users life harder by uploading the file?

Edit: or allow the user to upload the hwid if they want to opt out maybe?

[Christoph Hart]

@Casmat said in Different Encryption Types in HISE?:

but is it frowned upon to send the hwid once to home and then another time

Not at all and this is how basically everybody (including us) is handling it. What I find optional is the route of being able to create a license file for a computer that is always offline, then copy that file to a system with online access and make the activation. This is getting less and less of an issue because the time where studio computers were offline for whatever reasons is a dying habit.

[Casmat]

@Christoph-Hart thanks!

[aaronventure]

@Christoph-Hart said in Different Encryption Types in HISE?:

If one makes an online authentication system, then it’s pretty much game over for keygens, hence you don’t see adobe photoshop keygens anymore

If you make a "must-call-home-to-use-the-plugin" copy protection you'll get the righteous wrath of your legit user base and anything else can be bypassed with a crack.

Can't this be bypassed by a crack, too? If the script is not encoded you can just... remove the boolean, no?

[Christoph Hart]

@aaronventure everything can be cracked, sure.

[Lindon]

@Christoph-Hart said in Different Encryption Types in HISE?:

If that was the procedure, the cracked release will contain a modified binary (which is most often the case, because otherwise the "crack release" will contain only a 200kb keygen which I've never encountered in my life so far).

Well thats exactly what happened to me with Atmosia 2.0 - people are still downloading (at my cost) the binary and trying to apply the keygen generated code - even if I went to RSA with V2.5.... so its def. a problem.

[Lindon]

So to be clear -

• Yes everything can be hacked...
• RSA and many other schemes(including the unlocker) can be hacked by a dedicated serious pirate group

But here we are asking for a better encryption method NOT because this will stop the dedicated pirate groups hacking the code and delivering a hacked-binary - because this wont, but more on this in a minute. No we are trying to stop the keygen attacks only. These are the worst for reasons @Casmat outlined in https://forum.hise.audio//post/73852

So first to deal with @Christoph-Hart s issue that "key gens are rare", which I think is a manifestation of the black-swan problem, just because you haven't seen them doesn't make them rare. Because my experience is that they are not rare at all.

Second - why keygens are really bad: Because they generate valid keys, and no matter how many places and how many timed-to-activate-only-at-a-future-date elements you put in your code then the key gen defeats them in one single step.

I strongly recommend everyone interested in this stuff go look at the advice and experiences Urs Heckman of (UHe) has posted in the DSP forum at KSPAudio, here's some of his advice:

• have your validation code in several places
• have your validation code additionally execute at some future date

There's more but both these things are an attempt to fight off the dedicated hacking groups with their shipped-hacked-binary approach. Both these things are utterly defeated at the outset by a KeyGen.

[d.healey]

@Lindon said in Different Encryption Types in HISE?:

people are still downloading (at my cost) the binary

Why are they able to download it from you without a valid purchase?

[Lindon]

@d-healey demo

[d.healey]

@Lindon Is there a way you could limit the content in the demo until they activate it with a license key that you can confirm is genuine via a server call? And then download the additional content.

[Lindon]

@d-healey said in Different Encryption Types in HISE?:

@Lindon Is there a way you could limit the content in the demo until they activate it with a license key that you can confirm is genuine via a server call? And then download the additional content.

of course...but.....

[d.healey]

@Lindon said in Different Encryption Types in HISE?:

I think is a manifestation of the black-swan problem

Sign up to some of the cracker groups on FB, you'll see keygens

This just popped up in my feed. FB doesn't do anything when you report the groups...

[Casmat]

@d-healey yup haha, I had seen the same thing, the thing with keygens is that everyone’s starting to realize that using encryption is the way to go, and keygens have died down because these cracker groups are unable to find any way to get real keys, but they still pop up with systems with some sort of error in the code that gives out the private key or it not having any encryption at all, which there are still many because people don’t know much about encryption and still want to stick with an outdated system

FB doesn't do anything when you report the groups....

Classic FB (and other piracy sites), unless a dmca takedown is issued, they’ll just sit around

[Casmat]

I also suggest taking a look at this which definitely helps consolidate everything into a nice blog post:

https://keygen.sh/blog/how-to-generate-license-keys/