More copy protection...

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

'Once a serial number has been issued to a user couldn't that serial number and associated plugin file be simply copied and distributed as a pair to create an unlimited number of "unlocked" versions? '

No. Usually a serial number will be based on a 'fingerprint' of the user's system requesting the serial number.

Post

My husband is an expert in this area. Let me dispel the myths here. No matter what software is written, if it has software copy protection it can be broken. Once it is broken, it can be copied and distributed an unlimited number of times. End of story.

There are avenues to make software copy protection more difficult to break, and more difficult to distribute. Obfuscation, emcryption, delay code and dummy code can confuse and slow down crackers.

Reduce distribution by limiting and identification. Limit by only giving binaries with full functionality to paying customers who must login to acquire/download. Additionally, make compile a unique binary for every customer. That way, it is easy to identify which paying customer has distributed the full function version/software, and prevent further updates for that customer. Never place full code in a demo version, that way the demo cannot internally be rewritten to use those functions as the full bersion does.

Finally, add a simple serial number for the full functioning version. This can further limit distribution issues.If each binary codebase is customized to each paying user, only one serial number needs to be checked for and only one serial will work.

Finally keep updating and altering the codebase to keep them guessing. A cracker will often rely on a similar code pattern in updates so they can simply repeat prior successful copy protection attacks.

Good luck.
SLH - Yes, I am a woman, deal with it.

Post

Vertion, +100!!!

@Fender19

It seems you're searching for the uncrackable scheme. Such a scheme doesn't exist. If such a scheme existed all developers would use it. All schemes are crackable, it's a matter of time (and efforts of crackers). If you need to protect something choose one of the schemes depending on your needs and possibilities. It would be more or less difficult to crack, free from errors, simple to mantain etc. Choose the scheme that fits your situation.

You will be cracked, your serials will leak. It's inevitable. So, think about how you will deal with it when you will be cracked. And how to make the crackers life a bit harder.

Post

Especially think of your legit customers and the hassle you might introduce to them for more intrusive copy protection schemes.

If you do your best you can only buy some more time. Make your customers want to pay for your products by publishing with fair prices, frequent updates, improvements, ...

Post

Vertion wrote: Thu Sep 19, 2019 1:31 am..compile a unique binary for every customer. That way, it is easy to identify which paying customer has distributed the full function version/software, and prevent further updates for that customer.
That would be really effective, both for prevention and policing, especially if combined with a serial number. But how would you do it without spending hours a day compiling and distributing custom builds? Also, most plugin customers expect to use their plugins right after purchase - would they be willing to wait a day for this?

For something really expensive and low volume this might make sense, but for plugins, IDK. Just curious if some of you actually do this? Automated, if so, I would assume.

Post

Fender19 wrote: Mon Sep 16, 2019 6:09 am
Rockatansky wrote: Wed Sep 11, 2019 6:38 pm
Fender19 wrote: Wed Sep 11, 2019 4:16 pmCan someone explain the general concept of how serial numbers are used to authorize plugins? AFAIK, all plugin code is "read only" - so how are these serial numbers being entered by the customer and stored WITH the plugin at runtime?
... save a successfully verified serial number to file. When the plugin starts up, try to load the file. If it's not there, ask for a serial number. If it's there, try to load the saved serial number from it. Check the validity of the loaded serial number.
I understand the concept but not the implementation. Where are you storing the "valid" serial number that you are comparing to the serial number the user types in? Unless you are using web-based C/R of some kind the only other source is the plugin code itself, right? How do you embed serial numbers into that code without compiling unique .dlls/.vst3s, etc., for every serial number?

The "lightbulb" hasn't come on yet - can you please explain in more detail? Thank you!
You need to do some research about cryptography and signature algorithms used to implement systems like RSA/https.

Here's your answer (partially): https://en.wikipedia.org/wiki/Digital_S ... _Algorithm

In short: it isn't possible to fully encrypt data when you send it to your end point. What you can do is have pre-arranged keys. This is how public key cryptography works. There is a key that is given to the user in advance that they get directly from the source (inside the software binary.)

That key can encrypt data that can only be "unlocked" by the source... but you might say this isn't what you want, since it's "backwards" of course. That's where the signature algorithms enter into the picture. It's also possible to use the public key to verify a "signature" from the source.

This means that if your key file contains a signature to identify it as valid, the public key (in your software) can be used to verify that... but a valid signature is while not mathematically impossible, totally impractical (thousands of years of time to process) to produce without the private key held in secret by the source (you.)

The obvious question is then "can't we just crack the binary so it always says the signature + key pair are valid?"; yes, absolutely. That is where all the comments about deferred checks and validation in this thread enter into the picture as a solution.

Once it is impossible for the crack to write a valid signed key file, it becomes a game of how they work around the problem with a lot of time invested. If you start to put some of this load on to the user of a pirate version/key (their project suddenly refuses to load saying: "PIRATE KEY DETECTED") they'll suddenly be a lot more willing to pay the license fee in order to have a working VALID key file and a proper working binary distributed from a TRUSTED and reliable source.

That is why when customers have a problem we need them to present their key: if you have a valid license you get support and we fix the problem. If you don't have a valid license you're welcome to purchase one.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

aciddose wrote: Thu Sep 19, 2019 5:26 amThat's where the signature algorithms enter into the picture. It's also possible to use the public key to verify a "signature" from the source.

This means that if your key file contains a signature to identify it as valid, the public key (in your software) can be used to verify that... but a valid signature is while not mathematically impossible, totally impractical (thousands of years of time to process) to produce without the private key held in secret by the source (you.)
That's what I was getting at here: viewtopic.php?f=33&t=531430

So the answer to that thread should have been "YES, but like this..."

Thank you for the info.

Post

More on that: let's assume for a moment the goal is to fully protect some portion of the code that is never supposed to be available to the user. So we know we can encode data and transmit keys in both directions... but the decoding/decryption process happens on the user's system...

So if we're sending the unlock key to the user... what is there to stop them from turning the lock on the door that says "NO UNAUTHORIZED ENTRY" ?

The issue is then that the system is under control of the user. So we would need a system that is entirely secure and out of the control of the user. This is how some of the secure dongles work.

We can transmit an encoded/encrypted key and allow the user to pass it along to the dongle device. The dongle then contains the unlock key which opens the lock to get the software key. The software key is then used to open an additional locked package provided by the software binary. This package usually contains instructions for the dongle device to execute internally and return a result.

For example we can process the configuration/allocation procedures for loading presets inside the dongle so the entire process is secure. The user never gets to see a raw copy of the preset data... that only gets "unlocked" internally inside the dongle. The dongle then hands back the data it has computed which is specific to that instance of the software running on that user's system with that user's key.

Without a secure system (dongle, chip, server or otherwise) you can't maintain secrecy, so you don't have true security. That said, forcing users to own and maintain a dongle is a lot of strain on those users and puts you in a situation where "lost keys" lead to no solution.

There are many other layers and details of such a secure system, but I assure you all the answers do already exist. You can gain access to them if you qualify according to the owners of the dongle hardware/software (the manufacturers/authors) and primary keys.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.

Post

Anybody ever got an email from a frustrated cracker?

Just wondering. I'm sure there has been feedback here complaining about how devs do certain things. And it is easy to tell what is a legit problem and what's not.

BTW I honestly recommend buying a licensing product from a legit company and not doing it all on your own.

Post

trewq wrote: Thu Sep 19, 2019 6:36 pm Anybody ever got an email from a frustrated cracker?
Yup (in reply to sending them a scenario where their crack didn't work)

Post

Short recap from my side:

Yes, a simple serial (no c/r) can be leaked, and a crack can be distributed. That becomes free advertisement a few years later, after you release a few updates which blacklist that serial or that particular attack on your copy protection. Update often, make the current version look more yummy than the cracked/leaked one. I actually believe that the combination of patience and good design lead to more revenue when a crack was possible at some point. (Can you afford not to be cracked and leave the exposure to your competition?)

Yes, it's cats and mice. They crack, we improve. They crack again, we improve again, ad nauseam. The point is, how many hours do you want to spend on that shit? I spend maybe a day or two every year or two. Try to find a crack of a recent release which does not "expire" for anyone. Team VR haven't even bothered to look into these reports, they just put them up with a crack that's long been vaporized.

Yes, one idea to defeat keygens is to use cryptographic methods. If the payload results in 64 bytes of random shit, test against 10 bytes to unlock the full version. If a keygen pops up after all, test against another 10 bytes in the next update. In delayed checks, test another 10 bytes. Also in delayed checks, test that the public key has not been swapped out. Always do more than 1 check. Never cluster this code in a library. Make these checks inline.

Post

I dont want to sound harsh, but those techniques are pretty basic.
You are underestimating how much good cracker teams are(I'm amazed!!! Really! Often they have also a very good math knowledge and skills way better than the medium skilled developer), and how much difficult is publishing a fake "crack" and their organization, reasons, competition.
In a word, dunningkruger

Post

Zaphod (giancarlo) wrote: Sat Sep 21, 2019 8:26 am I dont want to sound harsh, but those techniques are pretty basic.
You are underestimating how much good cracker teams are(I'm amazed!!! Really! Often they have also a very good math knowledge and skills way better than the medium skilled developer), and how much difficult is publishing a fake "crack" and their organization, reasons, competition.
In a word, dunningkruger
Oh please. The "Crackers are Coding Gods" narrative. Like, they do it because they're bored with their actual business that makes them a million a day, and that's how good they are. And because they have been so utterly successful since the age of 3 they never developed any personal taste, hence garnishing their cracks with mediocre ascii art. And hundreds of comic sans "Thank You!" gifs are the only thing that still tickles their ego.

I don't think so.

Post

Urs wrote: Sat Sep 21, 2019 11:09 am
Zaphod (giancarlo) wrote: Sat Sep 21, 2019 8:26 am I dont want to sound harsh, but those techniques are pretty basic.
You are underestimating how much good cracker teams are(I'm amazed!!! Really! Often they have also a very good math knowledge and skills way better than the medium skilled developer), and how much difficult is publishing a fake "crack" and their organization, reasons, competition.
In a word, dunningkruger
Oh please. The "Crackers are Coding Gods" narrative. Like, they do it because they're bored with their actual business that makes them a million a day, and that's how good they are. And because they have been so utterly successful since the age of 3 they never developed any personal taste, hence garnishing their cracks with mediocre ascii art. And hundreds of comic sans "Thank You!" gifs are the only thing that still tickles their ego.

I don't think so.
No no, you are getting me wrong here
I'm not speaking about ethics, but about their "game": less code, less hassles, less bombs, less memory footprint and so on.
They don't care if an other team released a crack or not, their scope is about winning the race. So if someone release a crack which is not even working like it was proposed in this thread, or released by a "new" team (new to the scene) they literally don't give a f-uck. They don't care if the software is expensive, or if the developer is poor or rich. It doesn't matter
About how good they are, they ARE good in doing it. Let's be straight, much of the solutions proposed in this thread are not taking in account they are good. Seriously good
I don't know if people here realize they are often very small teams (like 3-4 guys) releasing literally thousands of releases in few years
My 2 cents

Post

As it's 2019 and piracy is still a thing there is no doubt how good or bad crackers are in what they're doing.

Post Reply

Return to “DSP and Plugin Development”