Which software protector for a commercial vst

[elena2]

@chaotikmind you cracked a themida protected proggy ? Wow then you are a genius chapeau
But, in your opinion and honestly, would you or anyone else invest months of hard work to crack a plugin worth 50$ ? Which is perhaps not popular like, say, a Kontakt or a Serum ?

However I heard googling around that the last Themida version seems very hard to crack (btw one would apply virtualization only to the licensing code, not the dsp of course - I just wasn't aware of this possibility when I wrote the original post, and I wasn't too serious either when I expressed my concern that someone could reverse engineer the dsp part of course)

[elena2]

@ahribellah, yes but as I wrote I am not hoping to make my plugin uncrackable, only to delay this event the most possible.

I fully agree that a good protection must not penalize performance as it must not make the user feel frustrated. It is all a compromise

[Chaotikmind]

@chaotikmind you cracked a themida protected proggy ? Wow then you are a genius chapeau
But, in your opinion and honestly, would you or anyone else invest months of hard work to crack a plugin worth 50$ ? Which is perhaps not popular like, say, a Kontakt or a Serum ?

However I heard googling around that the last Themida version seems very hard to crack (btw one would apply virtualization only to the licensing code, not the dsp of course - I just wasn't aware of this possibility when I wrote the original post, and I wasn't too serious either when I expressed my concern that someone could reverse engineer the dsp part of course)

i'm an average reverser.. absolutely not a genius.

And the answer to why , because it is fun and instructive, it is like a huge puzzle for nerds
i seriously doubt many people does it for any money anyway, most release can be found in torrent
Also i'll speak only for myself here, but i don't believe in intellectual property in any shape or form, which doesn't mean that i would never pay for something that i think deserves it.


About virtualization : there was only one virtualization engine when i did that, it was very probably far more simple than the current choices, but it doesn't matter, once you figure it out, you can automate the decompiling -> translation to new assembly process (could be painful tho )

Yes i hope you would only virtualize your protection code in the case of a dsp app/plug, but now i know where the offending part is , you're basically pinpointing it for "me"

Also if you don't know exactly what're you're doing any "high level" protection can be pretty useless, i was recently pissed by a piece of software where the licensing system got in the way of my work, investigated 5 minutes, flexlm protection, was unsure if it would worth the invested time to fluidify my workflow, end of story : i noped a call, and that's it (shame on them on that one !)
i guess that was an incredible waste of money (and hassle to have to deal with the licensing for the user, for exemple in that case, slower startup of some tools that have to check the license each single time)

[Big Tick]

You can make parts of your code very hard to disassemble by embedding a scripting language, and scripting the code to protect. Then store an encrypted version of the script. This lets you do a lot of neat things that aren't possible (at least not easily) in c++, such as:
- self-modifying code
- multiple layers protection (c++ -> script -> c++ -> script ....)
- embed code in presets
- download code from your server (careful with that).
- code that can only be decoded and executed if you have a valid serial number.

and so on.....

[Chaotikmind]

You can make parts of your code very hard to disassemble by embedding a scripting language, and scripting the code to protect.

Which would mean developing an in-house scripting language otherwise i don't see the point

- self-modifying code

since we can do that in assembly, and assembly integrate very well with c/c++ ...
(and it is very very common in any decent protection as well)

- multiple layers protection (c++ -> script -> c++ -> script ....)

My favorite one in your propositions, well implemented it could be really painful

embed code in presets

i think it is pointless, once the code is decrypted/executed, i have it

download code from your server (careful with that).

if it is downloaded , that means i have it

code that can only be decoded and executed if you have a valid serial number.

i absolutely don't see the difference with a normal protection scheme, isn't it the main point of any protection scheme?




Also , it is just a matter of point of view, but a virtual machine IS a scripting language somewhat.

[Big Tick]

You can't do self-modifying code in assembly, not easily, nowadays. On Windows you'll be fighting with DEP settings, for starters. Good luck if you want to go that route though. You'll have to write things twice btw, for Intel and M1.

With all due respect, you're kinda missing the point. With code embedded in presets, you can add extra protection checks that will only kick in when the booby-trapped preset is loaded. There's no way for a hacker to find these. You can add these extra checks to preset expansions. You can blacklist leaked serials by releasing new presets. You can do a lot of things that, most importantly, you don't need to plan for from the start.

And no, you don't need your own scripting language. The point of a copy protection scheme is to give you the most options for obfuscation without having to write everything yourself. Sure, you can make a virtual machine and write your own language and compiler for it. Personally I'd rather spend time writing plugins, and integrate angelscript, duktape, or whichever language you want.

[audiothing]

You can make parts of your code very hard to disassemble by embedding a scripting language, and scripting the code to protect. Then store an encrypted version of the script. This lets you do a lot of neat things that aren't possible (at least not easily) in c++

We do that as well for some products. However, they tend to bypass it altogether unless it's really tied to something outside the licensing itself, but that could be risky.

You can make parts of your code very hard to disassemble by embedding a scripting language, and scripting the code to protect.

Which would mean developing an in-house scripting language otherwise i don't see the point

You could even use javascript, properly encrypted of course. It doesn't really matter what you use. It's just an additional layer that lets you do things that might be harder to spot.

- self-modifying code

since we can do that in assembly, and assembly integrate very well with c/c++ ...
(and it is very very common in any decent protection as well)

But assembly is not portable though. Or you could implement that for Windows only perhaps, macOS cracks are much easier to prevent.

embed code in presets

i think it is pointless, once the code is decrypted/executed, i have it

Like everything else, once there's a license leak, they have everything. But it doesn't mean it's completely pointless. It could be a good place to put time bombs/checks that are not easy to spot.

[Big Tick]

You can make parts of your code very hard to disassemble by embedding a scripting language, and scripting the code to protect. Then store an encrypted version of the script. This lets you do a lot of neat things that aren't possible (at least not easily) in c++

We do that as well for some products. However, they tend to bypass it altogether unless it's really tied to something outside the licensing itself, but that could be risky.

We scripted the whole UI too, so there's no way to turn off scripting. There's also no extra cost for using the script interpreter for copy protection.

[mystran]

- multiple layers protection (c++ -> script -> c++ -> script ....)

My favorite one in your propositions, well implemented it could be really painful

I don't think it's necessarily the scripting language here "as such" that makes these types of constructs hard to debug (and I assume what applies to debugging, generally applies to reversing as well). Rather it's the fact that we're blurring the line between code and data, encoding some of the logic in code and some of the logic in data. A Bison-generated parser isn't hard to read because it's generated; it's hard to read because it encodes much of the logic in tables that are pretty much impossible for a human to decode in the format presented.

The extreme example of this would be something like https://tromp.github.io/cl/lazy-k.html where if you look at the "source code" (and much less some partially evaluated memory snapshot) you don't really even know what is code and what is data, because it's all just function soup. You encode booleans as functions that pick one function or another, you encode integers as church numerals. You even encode all dataflow as functions that curry other functions and if all you've got is the combinator soup it's really really hard to say what is going on, because you can't easily divide and conquer any of it (well, you can substitute combinators with lambda expressions and do partial evaluation, but then you're still left with lambda soup that isn't necessarily that much better).

[Big Tick]

I don't think it's necessarily the scripting language here "as such" that makes these types of constructs hard to debug (and I assume what applies to debugging, generally applies to reversing as well). Rather it's the fact that we're blurring the line between code and data, encoding some of the logic in code and some of the logic in data.

Spot on. However we still need to write some of the logic. Personally I'd rather write javascript or lua, than lazy-k

[Big Tick]

Like everything else, once there's a license leak, they have everything. But it doesn't mean it's completely pointless. It could be a good place to put time bombs/checks that are not easy to spot.

They don't, if (as you should) you partition your users space so they don't all trigger the same checks.

[mystran]

Spot on. However we still need to write some of the logic. Personally I'd rather write javascript or lua, than lazy-k

Writing Lazy-K is actually not that bad, because there's a compiler (written in Scheme I think, so you can build fancy macrosystems and whatever easily on top) that takes lambda-expression in Lisp syntax and outputs Lazy-K. The real problem is performance, because lazy evaluation of untyped pure SKI-calculus is horribly inefficient.

edit: The main point I was trying to make though is that you could reasonably find other ways beyond scripting languages to mix code and data in a way that makes it confusing for someone to understand what is going on.

[elena2]

i'm an average reverser.. absolutely not a genius.

And the answer to why , because it is fun and instructive, it is like a huge puzzle for nerds
i seriously doubt many people does it for any money anyway, most release can be found in torrent
Also i'll speak only for myself here, but i don't believe in intellectual property in any shape or form, which doesn't mean that i would never pay for something that i think deserves it.

Said friendly and without offence of course, and by one bad gal who *has been using tons of warez in the past* before she started coding her stuff, I think your position is quite unrespectful of the hard work of who invests energy and time coding good stuff and perhaps tries to earn something to compensate his/her efforts. I am sure that you are talking this way because you never created or released any plugin or software in general, otherwise (trust me) you would have definitely a different position, and you would *not* like so much the idea that somebody may want to crack your stuff

[FabienTDR]

I apologize upfront if I give you "that type" of answer you don't want to hear.

IMHO, all this type of "protection" is completely unnecessary and irrational. It's clearly harmful in terms of PR (network effects, long term branding, etc). Starting from zero, you want your product to become a "go to" asap, you directly depend on the cracking scene's favour. They literally run the cheapest customer acquisition services around. Too many people do linear doomsday prediction and forget that humans constantly age, evolve, some of them find great jobs, and start a prestigious career as a customer. This scene builds an excellent substrate for planting "go to" seeds early.

Same goes trying to protect algorithms. I think it's a ridiculous idea to obstruct such aspects. Very likely this tech is not that new, faulty or not that clever - but it will take years to find out if ever, as absolutely nobody will be able or willing to help you. You'll take much longer to develop and maintain the software, possibly slower than the software ages.

Both produce gigantic opportunity costs often ignored. Many software startups in this market went bankrupt, never found any grip, never got in contact with their audience, took absurd amount of time to ever support modern hardware, specifically because of too much copy protection. Protection is a liability throughout lifetime, not an investment.


We've been running our software venture for more than 10 years in this market, without "protecting" any aspect of registration or technology. We update our products too often for crackers or reverse engineers to have any effect (never met a capable RE that had bad intentions, but well).
Despite us being completely open about our tech and solutions, we make about 40% of our revenues with consultancy and licensing our tech/libraries to third parties.

What we do, though, is non-upgradable demos, with full editions only accessible to license holders. A bit of watermarking trickery then gives us the "pull the plug" capabilities we need whenever idiots show up. But that's it. As cheap as it gets.

[elena2]

People sorry to resume the thread but after much brainstorming I fear there is really something which I miss about the commonly used and suggested private/public key scheme. Very sorry in advance.

The scheme I came to was conceived as follows:
The plugin once bought (to be activated) sends to a remote php script the user name and machine id. The php script, once it verifies that the purchase is valid (this is another story, I have no issues with it) creates a keyfile which contains user name and machine id encrypted, and sends it to the user (either by email or directly to be saved by the plugin in the right folder).
The plugin on startup looks for a valid key file. If it can be decoded and the machine id contained corresponds to the local machine id, the plugin becomes operational, and the user name can be displayed in the about panel.

However this scheme does NOT contemplate the public/private key encryption afaik. Fact is, my brain is stuck and I have no idea how to implement the asymmetrical scheme properly in this scenario.
Can you point me on some link where such a scheme is explained, and most important, how to apply it to the specific case of a keyfile ??

It is this concept of public and private keys which I fail to understand... once I understand it properly I have no issues to implement it of course. But I really miss the key concept..

Perhaps the php encoder should encode the keyfile using both a private and public key, and the plugin should just need a public key to decode it ? Or the keyfile itself has to be considered a 'key' ?

If you can explain me the concept clearly I would be grateful. Thx