More copy protection...

[Urs]

My husband says hi Urs!

Hi back

Btw. individual builds for each customer have become a lot less feasable since binaries have to be signed and/or notarised - factor in the reliability of certain services... difficult. Also, I reckon some of our products need 10 minutes to compile on a current machine. So even if we pre-build individual binaries for updates for all our customers up front, we either need to plan a few months ahead, or we'd need a pretty giant render farm. I think the approach doesn't scale well, at least if it's watermarking throughout the whole binary.

Cheers,

- Urs

[Hink]

well there's 35 minutes of my life I wont get back, let's not do this again please and just for the record in case people dont get not just in this thread...also I want to point out that suggesting someone releases cracked versions is akin to bragging about using warez, I realize there are differences but it can lead down the same path and open up more such conversations.

[ENV1]

they can practically rob him blind

Some do. Most don't. We'll keep doing what we do as long as it stays that way.

And i respect you for that because in doing so you are putting your customers before your bottomline, which can probably not be said about too many other devs.

[Richard_Synapse]

Thanks, that's the point I was looking for. Just getting a keyfile from someone, blocking the DAW with a firewall to ensure no homecalling is happening and done. Adding some sort of machine ID could be a small hurdle but once they found out how it's generated, it's over again.

Not exactly. The major advantage compared to a serial-only protection is that any crack requires repackaging everything (which is also quite a bit of work, and often the new installers lack something). But the worst issue for freeloaders is that they potentially end up with trojans, ransomware, etc., since they have no idea what they are installing. It simply becomes impossible that the original, signed/trusted binaries are distributed.

Richard

[quikquak]

But the worst issue for freeloaders is that they potentially end up with trojans, ransomware, etc., since they have no idea what they are installing. It simply becomes impossible that the original, signed/trusted binaries are distributed.

Don't these kids just get used to occasionally losing everything and reinstalling all their shit again?
How many times have you heard, "My hard-drive crashed!" - and really believed it to be a hardware fault?

[Richard_Synapse]

Don't these kids just get used to occasionally losing everything and reinstalling all their shit again?
How many times have you heard, "My hard-drive crashed!" - and really believed it to be a hardware fault?

Yep true, not all are kids though. Some are grown ups, or even pro producers with the money to purchase legit licenses. They just need some extra incentive

Richard

[quikquak]

Anyone who rips software is basically an irresponsible child in my eyes. I'm sorry, it just that I see 'grown ups' meaning grown-up! I can't help it.

[buddard]

Hence keep you symbol files (but goddammit strip them out of your release binaries), do a binary compare between original lib and cracked, and figure out what symbol was cracked. It's a quick and easy way to figure out what angle/vulnerability they used. Then, for next update, add a delayed check or two for exactly that angle.

Sorry for reviving this thread after such a long time...

This is exactly the point I'm at right now:

A crack has been released for one of my plugins, and I'm trying to figure out how they did it.
However, I can't seem to figure out how to do what Urs mentioned above, i e how to use symbol files from a debug build when running the cracked binary... (I strip the symbol files from my release builds, of course)

I usually develop in Xcode on Mac and only use Windows for building and testing, so I feel extra lost now trying to make this work in Windows 10 on Visual Studio 2017, where I'm barely able to browse the files in my project (I mean, what kind IDE doesn't even have a file tree on the left side where you can see all your source files??)... I feel so useless right now, hahaha!

What I tried to do was to install my "stripped" plugin from my own installer (before applying the crack, i e the pure release version), then do a debug build in VS (to generate symbol files), and finally attach it to Reaper. I figured that VS would find the symbol files, and somehow figure out that they belong to my running binary? Well, that doesn't seem to be the case, because when I add a breakpoint I get the warning about missing symbol files...
I'm using JUCE, by the way.

So does anyone have any pointers on how I can get this working? I would really appreciate it!

[mystran]

What I tried to do was to install my "stripped" plugin from my own installer (before applying the crack, i e the pure release version), then do a debug build in VS (to generate symbol files), and finally attach it to Reaper. I figured that VS would find the symbol files, and somehow figure out that they belong to my running binary? Well, that doesn't seem to be the case, because when I add a breakpoint I get the warning about missing symbol files...
I'm using JUCE, by the way.

The symbols are different for every build. They literally store offsets into the binary and even with the same compiler just changing some optimization settings or linking the object files in a different order will typically make the debug symbols entirely different.

On Windows the debug symbols are stored in a separate file, so what you need is the PDB file from the original build and this means the very exact binary you built for release. If the original was built without debug info, then you're pretty much out of luck.

[Urs]

Ok, here's what I would do ion this situation:

1. Figure out how to make builds without symbols for which you keep an external file that contains that information, and figure out how to read it. This is not only important for anti piracy, it's also important when users report bugs and have a crash log. You'll want to relate the stack trace to the actual symbols.

(Maybe also prepare a storage solution, like a NAS, where you store any build that leaves the house with all the symbol files and also the whole build log, make files etc. etc.)

2. It may still be worth it doing a binary compare of cracked and untampered dll. Sometimes crackers add little vanity pee marks, such as altering a string. This would be your first funky angle to defeat them. You could make a delayed check that takes a checksum of such an altered string, and if the checksum doesn't add up... but don't forget to add a unit test that performs this check on every build, such that, if you ever change that string yourself you won't trigger loads of false positives...

3. Add a new killer feature and update your software. Next time around you'll be much more prepared.

[buddard]

The symbols are different for every build. They literally store offsets into the binary and even with the same compiler just changing some optimization settings or linking the object files in a different order will typically make the debug symbols entirely different.

On Windows the debug symbols are stored in a separate file, so what you need is the PDB file from the original build and this means the very exact binary you built for release. If the original was built without debug info, then you're pretty much out of luck.

Ok, here's what I would do ion this situation:

1. Figure out how to make builds without symbols for which you keep an external file that contains that information, and figure out how to read it. This is not only important for anti piracy, it's also important when users report bugs and have a crash log. You'll want to relate the stack trace to the actual symbols.

(Maybe also prepare a storage solution, like a NAS, where you store any build that leaves the house with all the symbol files and also the whole build log, make files etc. etc.)

2. It may still be worth it doing a binary compare of cracked and untampered dll. Sometimes crackers add little vanity pee marks, such as altering a string. This would be your first funky angle to defeat them. You could make a delayed check that takes a checksum of such an altered string, and if the checksum doesn't add up... but don't forget to add a unit test that performs this check on every build, such that, if you ever change that string yourself you won't trigger loads of false positives...

3. Add a new killer feature and update your software. Next time around you'll be much more prepared.

Thanks to the both of you for your replies, I really appreciate it!

OK, that explains why it won't match my symbol files with the binary. Then I will make sure to save the PDB files in the future. We have a huge Dropbox where we store the release binaries, so I'll just add folders for the PDB's there. I've got the source code and makefiles under version control, too, of course.

After testing the "crack" I've realized that it's pretty primitive (and also annoying for the users since they have to click through the registration forms on every plugin instance they load!). They seem to have basically "short-circuited" the call to the validation check when the user enters the license key in the GUI. So I think I'll just add a couple of independent delayed checks elsewhere in the code.

And yes, I'm planning to include this in the next feature update, it will hopefully provide enough incentive to convert at least a few freeloaders.

[Urs]

And yes, I'm planning to include this in the next feature update, it will hopefully provide enough incentive to convert at least a few freeloaders.

In our experience it is best to be "patient". Make the delayed check so that the same crack works for some time. So people who actually use your software and update it will run into the delayed check after a month or two. A year even.

One of our most successful checks is triggered in November/December for the Black Friday and x-mas season. When we still had Google Analytics we could trace dozens - if not hundreds - of sales to these delayed checks. We'd simply display a modal dialog with a link to our shop asking to upgrade to the full version. Sometimes that's all it takes.

[tdsp]

The symbols are different for every build. They literally store offsets into the binary and even with the same compiler just changing some optimization settings or linking the object files in a different order will typically make the debug symbols entirely different.

On Windows the debug symbols are stored in a separate file, so what you need is the PDB file from the original build and this means the very exact binary you built for release. If the original was built without debug info, then you're pretty much out of luck.

Ok, here's what I would do ion this situation:

1. Figure out how to make builds without symbols for which you keep an external file that contains that information, and figure out how to read it. This is not only important for anti piracy, it's also important when users report bugs and have a crash log. You'll want to relate the stack trace to the actual symbols.

(Maybe also prepare a storage solution, like a NAS, where you store any build that leaves the house with all the symbol files and also the whole build log, make files etc. etc.)

2. It may still be worth it doing a binary compare of cracked and untampered dll. Sometimes crackers add little vanity pee marks, such as altering a string. This would be your first funky angle to defeat them. You could make a delayed check that takes a checksum of such an altered string, and if the checksum doesn't add up... but don't forget to add a unit test that performs this check on every build, such that, if you ever change that string yourself you won't trigger loads of false positives...

3. Add a new killer feature and update your software. Next time around you'll be much more prepared.

Thanks to the both of you for your replies, I really appreciate it!

OK, that explains why it won't match my symbol files with the binary. Then I will make sure to save the PDB files in the future. We have a huge Dropbox where we store the release binaries, so I'll just add folders for the PDB's there. I've got the source code and makefiles under version control, too, of course.

After testing the "crack" I've realized that it's pretty primitive (and also annoying for the users since they have to click through the registration forms on every plugin instance they load!). They seem to have basically "short-circuited" the call to the validation check when the user enters the license key in the GUI. So I think I'll just add a couple of independent delayed checks elsewhere in the code.

And yes, I'm planning to include this in the next feature update, it will hopefully provide enough incentive to convert at least a few freeloaders.

From my point of view, one of the most powerfull technics to protect you validation code is to use binary code obfuscation. If you have any experience in the system programming, you can try to write some kind of binary translator with a multi-dispatcher interpeter. Also good technics is to use polymorphic encrytion and garbage generation for interpreter. But yes! This methods also can be cracked and for it implementation you need have reverse-engeneering/security skills

[Urs]

From my point of view, one of the most powerfull technics to protect you validation code is to use binary code obfuscation. If you have any experience in the system programming, you can try to write some kind of binary translator with a multi-dispatcher interpeter. Also good technics is to use polymorphic encrytion and garbage generation for interpreter. But yes! This methods also can be cracked and for it implementation you need have reverse-engeneering/security skills

I often propose a slight variation to this which does a similar trick, but is pretty easy to implement.

One technique that crackers use is to trace system calls (file opens etc.) to figure out when the software accesses, say, a license file or a dialog box. This can be done both with static analysis as well as debugging.

Therefore I propose a dispatcher for all system calls and more. This would be a single, non-inlining function that is called for file opens, dialog boxes, string conversion, hashes, checksums, date, time, milliseconds, ticks, locale and also maybe a few DSP functions that are not time critical. The more things you stuff in it the merrier.

Now, because this dispatcher is called from a 100+ places in the binary, it's not obvious anymore which part of the binary actually deals with copy protection. This makes IDA Pro a big deal less powerful. Thus the crackers will revert to breakpoints in the dispatcher and a debugging approach. This is where delayed checks are great because they can't debug something that isn't called. Or, if the code that opens the license file is also used to open 1000 pics for the GUI - happy debugging!

While a VM creates complexity by moving logic from code to data, this approach creates complexity by hammering the obvious targets with a cacophony of calls.

[Audiority]

would it make sense to have that as a singleton?