Which software protector for a commercial vst

[elena2]

Hi, I am bothering here in the hope to find some advices... I tried asking the same on several forums without success, and on stackoverflow they simply ban my questions (what a nazi place lol)

I need to protect a commercial vst from disassembling and tampering, since it includes the custom protection/licensing code and several propertary dsp algorithms. Of course I am aware that everything can be cracked eventually, but I wanted to at least make the job hard and delay cracking the most possible.

First I thought of UPX, but any packed dll or exe can easily be unpacked even if one erases the headers (several tools exist to restore modified UPX files for unpacking). And I am not expert with assembly, so I can't definitely modify UPX sources to implement a custom packing/encrypting algorithm (unless somebody is aware of any suitable forks ???)

ConfuserEx was the perfect solution but it works with c# code only, not c/c++

Themida despite expensive was also a good option but it uses a virtual machine, and nobody would use such a thing with time critical code like realtime dsp !!! It looks like VM can't be disabled, and however one pays for it and it would be a wastage.

I googled extensively without finding the option for me yet.
To summarize, I need a dll protector (for stuff written in c, not .net!!!) possibly free or cheap (<100$) providing protection against disassembly/anti tampering and possibly (but not necessarily) even anti debugging. A Themida without VM or a ConfuserEx for c/c++ would be perfect.
I need no licensing support since my vst already implements its own.

Any suggestions?
Ps. please no OT advices if possible like "focus more on user support and product quality and less on software protection" and such common replies lol I am aware of that already

Thanks!

[mystran]

First I thought of UPX, but any packed dll or exe can easily be unpacked even if one erases the headers (several tools exist to restore modified UPX files for unpacking). And I am not expert with assembly, so I can't definitely modify UPX sources to implement a custom packing/encrypting algorithm (unless somebody is aware of any suitable forks ???)

Standard packers have standard unpackers. Non-standard packers are somewhat likely to upset Virus scanners. With UPX specifically I think their license specifically forbids modifying it to make it incompatible. Practically speaking packers might not even do that much to prevent disassembly as one could still run the binary (or load plugin, etc) and then break in a debugger once it's unpacked itself. On the other hand, anything that keeps the code obfuscated at runtime is likely to cause a significant performance hit... and if you only obfuscate parts of your code, then there's a chance that someone looking at the disassembly will just find the parts that look like they are obfuscated which kinda defeats the purpose.

Worrying about people trying to decipher your custom DSP algorithms is probably pure paranoia. The amount of work required is ridiculous compared to the probability of finding anything actually useful in some random plugin and there's a good chance that even if you find something useful the information obtained from the binary is not enough to understand it well enough to actually make any use of it.. so like.. why would anyone bother?

Worrying about people trying to bypass your licensing system is a more realistic concern. I believe the accepted wisdom here is to try to make sure that keygens are impossible (so an actual crack needs to be distributed) and then just add tons of different checks that fire at different random times to make it as tedious and time-consuming as possible to actually find it all (ie. increase the probability that someone release a crack that fails when it happens to be Friday the 13th). Don't forget that memory breakpoints are also a thing, so whatever data you use to validate your licenses, spread that around in memory too so finding all copies is tedious is equally tedious.

Just make sure you strip the binary of any local symbols. What you don't want people doing is firing up a debugger and looking at the symbols list and directly jumping into LicenseManager::validateLicense ..

[elena2]

Thanks Mystran. Well I already took all the most obvious measures you listed of course. Symbols are all stripped, code is highly optimized and all strings are obfuscated. The code which checks the license at activation and which generates the hardware bound keyfile is a remote php script. But the keyfile decoder is inside the plugin of course, as it is the code which prevents dsp operations in case of invalid keyfile, despite I tried to obfuscate and spread it the most I could. Despite that I would have felt safer if the plugin couldn't be easily disassembled... I admit I am getting a bit paranoid but try to understand, they pretty crack everything, they will surely crack even my plugin despite it will be sold for 50$ and not 500$... I am not a rich software company, I am a musician and coder who ended up with a nice piece of software mainly for my purposes, but from which I also wanted to earn something, just to compensate for my efforts and since I judged it could have some marketing potential. So I just wanted to defend with my nails the miserable incomes I may get, at least delaying the most possible the day I will see it in warez sites

[hugoderwolf]

Disassembly is rarely required to "steal" DSP algorithms. Most things can be easily reverse engineered by a capable individual. For someone able to actually understand a piece of advanced DSP from some disassembly, it's usually still easier to just reverse engineer with a black box approach. And even then, most of the time said capable individual will rather come up with something themselves than caring so much about your invention (which you yourself don't sound extremely confident in).

If you've done most of the things mystran proposed, then you'll be fine. If your product is a flop, no amount of copy protection effort will lead to more sales. If it's good, it will sell enough even if it's cracked eventually (just make it hard enough).

[mystran]

One thing I want to add is that if you're generating an encrypted keyfile on the server and then decoding it in the plugin, use standard known-secure public-key crypto (eg. RSA or similar). The server gets the private key for encryption, the plugin gets the public key for decoding. This way someone that wants to generate new keyfiles has exactly two options: break into your server and steal the private key or patch a different public key into the plugin binary.

While patching a different public key into the binary (once someone figures out where and how it's stored) might not seem like the most difficult thing, you've still prevented keygenerators for an unmodified binary. This means that whenever you release an update, the updated binary also needs to be patched. If the way the key is stored is changed slightly from one version to the next, then even if someone tries to write a patcher, that also needs to be updated for every new version.

[mystran]

Disassembly is rarely required to "steal" DSP algorithms. Most things can be easily reverse engineered by a capable individual. For someone able to actually understand a piece of advanced DSP from some disassembly, it's usually still easier to just reverse engineer with a black box approach. And even then, most of the time said capable individual will rather come up with something themselves than caring so much about your invention (which you yourself don't sound extremely confident in).

My point exactly. There are so many alternative options with much better return of investment (such as developing something new) that it's just not generally worth the trouble.

[BertKoor]

mystran already gave a good tl;dr, but this long thread is a good read, especially the posts by Urs:
viewtopic.php?t=472847

[mystran]

mystran already gave a good tl;dr, but this long thread is a good read, especially the posts by Urs:
viewtopic.php?t=472847

Since Urs says "don't bother with RSA" I want to emphasize that I'm not suggesting it makes cracking harder by a significant margin, rather I'm just suggesting that it's one straight-forward way to force a crack rather than a keygen.

Basically, from the point of view of logistics, distributing a keygen is easier than distributing a patcher and distributing a patcher is easier than distributing the whole cracked thing (especially if your installation package has a fair filesize). So it makes sense to make keygens impossible and make sure patchers only work with a specific version so that their logistics become even worse than a full crack since now you need to find matching versions of a patcher and an installation package and hopefully all they can find is obsolete stuff that no longer works.

Again, just like with trying to make actually cracking the thing as annoying as possible, you can also do your best to try and make the logistics as annoying as possible. While it's all good to waste some misfit's time, it's even better to waste your potential customer's (ie. those that try to avoid paying) time, because some of them might eventually give up and just buy the thing so they don't need to worry about it anymore.

In general the goal here is not to be technically sophisticated as much as the goal is just to be as annoying as possible for everyone trying to avoid following the rules.

[Urs]

Agreed. Keygen is the first and highest priority to defeat. It can be done quickly, and with RSA for sure.

Expertise in defeating cracks requires patience, both in learning how to defeat them and in waiting for a crack to actually be defeated. I'm convinced it requires being cracked first to figure out what kinds of angles there are for a given software. And then you'd take those angles away, step by step.

[elena2]

Fact is, one must always choose a good compromise between security and annoying the user the least. For example forcing usage of a dongle or forcing the user to reactivate the software at every updates are things which can annoy the user a lot imho. If I really must pay for a software, and if I really am forced to have a keyfile bound to my machine, at least I would like to have to perform just one activation, and once done, to be free to use my software forever on that machine, and if I have to reinstall everything I have just to copy some files (including the keyfile) back in place. This policy is incompatible with Mystran's suggestion to change the key characteristics at every update sadly...
Since the algorithms used are propertary and quite intricated I don't think one could easily understand how to generate a fake keyfile without disassembling the decoder...
However Themida team told me that I can enable VM selectively in my code, i.e virtualize all the licensing/protection parts and not the actual dsp code... this would help a lot and I don't think (my guess) that a hacker would invest so much time and energy to crack a Themida protection for a plugin worth 50$... unless some automatical "de-themiding" tools exist out there (no idea)...
Just rambling...

[mystran]

This policy is incompatible with Mystran's suggestion to change the key characteristics at every update sadly...

Oh, I'm not suggesting you change the actual license keys every update. What I'm suggesting is that if you have something like a public key scheme, you change the way the key is stored in the binary so that someone can't just write a simple patcher that does a string match against your original key and replaces it with something else that can then be keygenned.

Since the algorithms used are propertary and quite intricated I don't think one could easily understand how to generate a fake keyfile without disassembling the decoder...

The absolute first thing any would be cracker is going to do is fire up some suitable disassembly tool (eg. IDA or similar)... and the next thing they'll probably do is fire up a debugger and breakpoint where you access the keyfile so they know where to start analysing the disassembly and you should generally expect these types of people read disassembly like it was source code.

Trying to prevent this is futile. If everything else fails they'll run your code in a CPU emulator. Understanding and trying to defeat custom decoders is absolutely the very thing that motivation that drives many of the people actually doing the work. What most people don't want to do is spend hours and hours on tracing through irrelevant garbage and dismissing breakpoints triggered by false alarms, so what you want to do is flood those people with exactly that. Don't make it more intellectually challenging, just making orders of magnitude more tedious and boring.

However Themida team told me that I can enable VM selectively in my code, i.e virtualize all the licensing/protection parts and not the actual dsp code... this would help a lot and I don't think (my guess) that a hacker would invest so much time and energy to crack a Themida protection for a plugin worth 50$... unless some automatical "de-themiding" tools exist out there (no idea)...

If there isn't a decoder for an off-the-shelf software protection VM, then someone somewhere is probably already working on one.

[elena2]

Thanks for your elaborations Mystrain. I will see what I can do to improve the key mechanism as you suggested. However I decided, I will use Themida anyway, it is quite expensive for me but I am testing the demo and I am liking all its features more and more.
All these measures put together should really discourage cracking a 50$ plugin imho! Which maybe it isn't even going to become too popular (forecasting that is not easy btw)

[elena2]

Btw thanks @BertKoor for the link of that post by Urs, very interesting!

[Chaotikmind]

Thanks for your elaborations Mystrain. I will see what I can do to improve the key mechanism as you suggested. However I decided, I will use Themida anyway, it is quite expensive for me but I am testing the demo and I am liking all its features more and more.
All these measures put together should really discourage cracking a 50$ plugin imho! Which maybe it isn't even going to become too popular (forecasting that is not easy btw)

Themida is strong but it is also very deafeatable, i think the 1st crack i did for a software protected by Themida took me one month (it was quite a long time ago, and there were no info on Themida in the wild, also that was probably the first time i attacked a serious packer)

But right now, there are quite well known methods to defeat the nanomites or the virtualized intruction and most of the annoying protection scheme

Also if you use the highest level of protection, like instruction virtualization, the performance hit is enormous depending of the part you virtualize.....


Read the post made by Urs about protecting your app/plugin, his approach make much more sense, and you won't ave to pay any licence for something, which when it is used "everywhere" also have all the protection already deafeated....

[ahribellah]

There are a lot of things to unpack here:

1) As others have said, if a determined person wants to reverse engineer your code, they will. That's just the way of things.

2) No protection is bulletproof. No company buys DRM protection to keep their software from being cracked. They buy it to keep it from being cracked for x amount of time.

3) Want proof of 2? Look on popular warez sites (before anyone scoffs at this, if you're going to be in a business, you should be aware of its piracy scene). Even the previously "uncrackable" Codemeter has fallen. A far cry from their, what was it, "we'll give $1m to anyone who can crack our DRM"?

4) As others have said, DRM causes a performance hit. This will only affect legitimate users. When your software, if it's popular enough, inevitably gets cracked, pirates will have a better experience. The only exceptions to these rules, ever, are if your software has a *lot* of online components, which is a completely different issue and still not a guarantee that pirates won't have a better time than legitimate users.

The way I understand it is that a large number of DRMs work such that they obfuscate the legitimate code by creating branching paths that lead to dead ends, making it difficult for would-be crackers to find the legitimate calls. This inflates the size of the executable, RAM usage, and CPU usage. Crackers just strip all of that out and leave the legitimate code.

You tell me whether your customers would be happy about having a worse product than pirates. Spoilers: I've seen it before. They wouldn't be.