I cracked a $200 software protection with xcopy

27 points by vmfunc 2 hours ago|13 comments

•

Nexxxeh 29 minutes ago

Is it not more "VST author just does the bare minimum to keep honest people honest, because more invasive DRM risks ruining a live performance"? I'm not understanding why TFA author has such an attitude about this. Is the VST author a horrible person or running a toxic business model or something?

•

bigyabai 12 minutes ago

I didn't read it as them having any attitude. They targeted an obviously low-effort VST plugin and found exactly the implementation failure they suspected.

If the Bass Bully developer didn't want the spotlight, maybe they should have programmed their $200 (!!!) plugin better. HN has gotten soft.

•

jrflowers 17 minutes ago

I think the VST author and the DRM vendor are different people and the author is poking fun at the latter. It’s possible that the VST author isn’t aware that the fancy DRM protection they paid for doesn’t cover runtime.

•

stavros 11 minutes ago

I think the VST author knew that fine, but they figured that:

1) Protecting the installer will take care of most casual piracy

2) Protecting the VST might lead to unpredictable performance and issues on something that needs to run in real-time

So they chose to only protect the installer, which seems like a very user-friendly choice. I both enjoyed the writeup and want to second supporting the developer by buying a license.

•

Liftyee 11 minutes ago

This is definitely just me, but the diagram with "motivation to buy" was amusing to me. I (try to) refuse to be manipulated by these tactics - if I think the software is worth buying, I will purchase and use it, otherwise I will look elsewhere! Nothing sets my "motivation to buy" to zero quicker than aggressive, "uncrackable" DRM. In fact, it usually skyrockets my "motivation to reverse", whether or not I actually need the thing (though usually this is overruled by having better things to do with my time).

•

stevefan1999 46 minutes ago

For VST performance and timing is important so you can't protect the actual plugin

•

charcircuit 2 minutes ago

It only affects the timing of starting it up.

•

kaszanka 23 minutes ago

> no winhttp.dll, wininet.dll, or ws2_32.dll. offline validation only. all crypto is local, so theoretically extractable.

You can't possibly know that by the mere lack of these DLLs from the import directory.

•

muststopmyths 11 minutes ago

TFA is checking those via imports, not copied DLLs.

I suppose they could LoadLibrary/GetProcAddress at runtime, but that'd be a lot of effort for obfuscation.

•

vmfunc 2 hours ago

author here. the irony is enigma protector's documentation literally explains how to add runtime checks to your payload. they just... didn't read it

•

adzm 20 minutes ago

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.

•

swatcoder 19 minutes ago

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).

•

VoidWhisperer 26 minutes ago

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