And I'm glad they didn't. Protecting the installer keeps honest people honest. Protecting the runtime after installed means reduced performance and/or support headaches. That said I hope the developer didn't pay too much for this copy protection when some bespoke checks on the installer would have sufficed.
I'm just glad they didn't use iLok. It's been a pain for me as a legitimate user of a few iLok protected plugins.
I think he should be mainly throwing it at the VST vendor, as opposed to the protection software, since the main issue in the article comes from the vst vendor protecting the installer but not the actual software (that said, they also show that the protection software is fairly trivial to hook and bypass)
Question: Why go through the effort of removing most of the key throughout the article just to have it in a chunk of code in the article anyways? I'm not trying to throw shade here, I am legitimately curious about the reasoning
Runtime checks aren't an impossible effort to defeat either. If you're into this stuff, you should build a plugin with them yourself and then figure out how to crack it. It's a great learning exercise.
As another commenter wrote, the protection is there to keep honest people honest, like locking the front door of your house.
It's not foolproof and doesn't need to be. It's role is to make sure respectful users know that you'd genuinely prefer they not steal your stuff (not everyone actually does care about that).
Or maybe they knew about the runtime checks, but made a decision not to add them? As others have pointed out, this plugin can be used during live performances. The last thing a plugin author wants is a reputation for their software being flaky at really bad times. A runtime copy protection check might fail for spurious reasons, who knows.
