Different Encryption Types in HISE?
-
@Lindon I think dave is right with his bigger lock on a half open door though. The attack vector is most likely not reverse engineering the private key but simply remove that check or replace the public key in the plugin with another one that matches the private key of the keygen.
In order to reverse engineer the private key you have to extract it and then run brute force stuff for a certain amount of time, but as soon as you know where to find the public key in the binary application file, you can as well just modify it and save the CPU cycles required for brute forcing that private key.
-
@Christoph-Hart said in Different Encryption Types in HISE?:
In order to reverse engineer the private key you have to extract it and then run brute force stuff for a certain amount of time…
But a 512 bit key could be cracked under one hour a few years back. I don’t know what solution a hacker is most likely to investigate…
I can't help pressing F5 in the forum...
-
@ustk Does the hacker know it's a 512 key without opening the code?
-
@ustk I haven't done this process myself (lol), but I would imagine that in order to run the brute force reverse engineering, you need the public key (that you somehow need to find and strip from the binary app) and a message that you then run through random private keys until the decoded message is the correct thing. If you can't "isolate" the public key like this you would have to run the activation check for each private key pair, and this would be orders of magnitude slower so the protection still holds (I would say for this naive approach a 64bit RSA key would be enough).
So even if that takes an hour to do with a 512 RSA key, you can just not do that but modify the app to use a public key that you fabricated and know the private key and I think this is the main route that crackers go.
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).
-
@Christoph-Hart Well that’s the problem, once they put the exe through a decompiler, they see all the basic assembly code, from their they can find the public key with some prowling through the code. Then they can just remove all the code related to copy protection and ship that as a crack software, that’s possible with any software that exists, there’s no way we can stop that. But the thing is, that crack exists for a certain version of the software (ex. 1.3.1) something like @Lindon said in
https://forum.hise.audio//post/73652
Once we release a new version, they’ll need to make a new crack for the updated version, and this somewhat discourages them as it’s one more software on their plate they have to crack. The major problem are keygen. Once a keygen is made, you’ll be screwed. This is because a keygen is a replica of the code you use to generate keys and it produces valid license keys that are real, and in the world of piracy, softwares with keygen are often the most pirated. A keygen can be used for multiple versions and even future versions. The thing is, changing an encryption scheme is hard once you already have it running and if there is a keygen, you need to find a way to migrate all your users and their licenses, even the ones with illegitimate keys and set up a new solution. Having a very unkeygenable system from the get go is much better than having to change the system. A single hacker may not take time to crack a 512 key now, but if your software reaches various cracking groups who have the proper hardware and experience, it’ll be pretty trivial for them to crack a 512 key, and that’s when your encryption system gets in shambles -
would a checksum validation be a good idea? the abillity of the plugin to verify its own hash. You would first declare it as a set of zeroes, compile, check manually, then hardcode that in. i see that JUCE has the MD5 class but beyond that have no idea if it can check the hash.
If you don't have any debug symbols, how would you know where to look and what to set an instruction to? If you have a single long boolean check and of these is regarding a successful license validation, it's not like it spells it out like that in x64dbg.
I think HISE encodes all the strings from the script, no? I just tried compiling something with hardcoded strings, opened the app in x64dbg and while there are 66700 strings, none of them are the ones I hardcoded in.
Maybe TeamR2R and co are very clever and there's nothing that can stop them, but your overall primary concern should be whether your payment processor cares about stolen credit cards i.e. how good its fraud detection is. The pirates aren't buying your expensive instruments with their own money.
The actual problem is/was sales to Russia and India and always via PayPal. I suppose Paypal + cards from these countries are somewhat of a security hole. it's also harder to vet PayPal than a direct credit card. Once you see a purchase with a weird name come through, it's over. Next week your instruments are all over the "cheap kontakt libraries" websites being sold for pennies. Beyond a certain price point, sales to Russia and India become so insignificant (below 0.2%) that it's probably a good idea just to block them altogether, or at least block PayPal usage from these countries.
Of course having any sort of online validation invalidates this threat, until someone who can open up your file and find then bypass security measures.
-
how do you even store a "validation successful" file on the computer? it is a mix of the license and the machine ID encoded, and the plugin then checks that on load? how would you bypass the need to call back home for a check like that?
-
@aaronventure said in Different Encryption Types in HISE?:
If you don't have any debug symbols, how would you know where to look and what to set an instruction to?
HISE scripts show up as plain text in the binary.
https://forum.hise.audio/topic/4854/how-to-make-trial-plugins-for-10-days/184?_=1705170153661
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
@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)
i make music
-
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.
-
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
-
@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.
-
@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
-
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.
-
@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?
-
@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.
-
@Christoph-Hart thanks!
-
@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?
-
@aaronventure everything can be cracked, sure.
-
@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.
HISE Development for hire.
www.channelrobot.com
