But I highly recommend not to use premade CMS' in combination with such sensitive tools like license generators. You never know what you get.
Can't tell, if your lib has been cracked or your site has been compromised. You should check your logs.
Also, download the cracked version and do some reverse engineering if possible.

Have been putting quite some effort into making the plugin for one of my clients (who's reselling it)
harder to crack. Was still posted on CGPersia 2 days after release. Kinda sucks, but that's how it is.

Cracking C++ plugins is easy for these people. That's certainly true if you rely on Cinema's doddering old serial number scheme, it's been around since Methuselah was a lad and they all know how to crack it. Using that, you can expect a crack to appear within 48 hours if someone wants it.

You have two choices: either suck it up and accept that your plugin will be cracked, or put a lot of time, effort and resources into protecting it. If you do that you may achieve some measure of success. There are some plugs around which are not yet cracked AFAIK, Octane is one, I believe. But no protection is guaranteed and it really comes down to how much resource you want to allocate for this (pointless for an inexpensive plugin IMO) and how much they want to crack it.

What about checking the license online with a database of sold licenses?
Is that acceptable?

I do not think the plugin itself is cracked, only the license part.
The crack includes a script to generate your own license file.

I agree that it is all about how much effort you want to put into protecting/securing the plugin.
But also the user friendliness is important.
Is it for example acceptable, that a user has to wait a day before receiving the license file.
This is because we are considering doing the license generation off line and not automatic?

What ever you do it will end up being cracked. You just have to hope that legitimate businesses that wish to use your plugins will pay for it. By paying they will then know that they can get some kind of support for your plugins.

The thing is that in your code you are most likely checking against some true/false value to check if the plugin can be used. All the hacker has to do is find where this occurs and change it so that it always returns true.

Using an online activation won't really change much since this also just returns some value to some part of the code that uses that to enable/disable the plugin.

Checking multiple different ways, at many different locations in your code could be one way to make it harder. But not fool proof.

Be the best developer you can be. Provide support to paid users. Provide additional information and material via a website only to those who have paid. This would make it more worthwhile for users to pay vs get a cracked version.

I have a more complex (not much more) method to register my plugins online.
And it has been pretty solid, so far.
But if the hacker bypasses the part of the code that performs the online check, everything gets ruined, of course.
However, since it is a much more lengthy piece of code, it is much harder to crack or bypass.
But most of my plugins are in python and, in python is much easier to access an online password protected folder (I use a password protected folder inside my own server space to protect my plugins).
In C++ it is much harder because I can't easily access the internet without resorting to some external library that I must buy.
I wish I could get easy access to internet password protected folder through C++, in a way that it was compatible with Xcode and Visual Studio.

I already tried cURL.
It is easy for OS X.
But, for Windows, I have to have it pre-compiled, and the user mush install the precompiled library in the Cinema 4D application folder.
At least, it was like this when I tried.
I wanted to have a "just compile and have it ready to just place the plugin folder in the plugins folder of Cinema 4D" kind of solution.
And I just couldn't do it in Windows.

OSX comes with libcurl built in already so you can just use that on OSX. The calls should be compatible as far as development goes. But if you use cURLpp then you will need to compile that against libcurl on OSX as well. I haven't tried this so am unsure of the exact steps with Xcode. But if you just stick to libcurl you should be fine.

From the coding side of things, there is no crack-safe variant as mentioned before.

If a hacker knows his stuff and he WANTS to crack something (means: he is willing to take the time) then he will be able to crack it.

What we can do as developers is giving him a hard time finding the code sections (via reverse-engineering etc.) so he cannot simply skip the serial section (that's why the serial number system used in its default state is easy to hack. The point where this is checked is always the same and he can simply modify the binary so that this point is skipped and returns true so C4D things it was successfull).

Of course, the harder it is for the cracker to find the serial number check section, then the chances that he will give up earlier are higher. Online checks are useful but the same applies of course (think of it: even websites of multi-billion dollar companies that have a team of guys handling safety 24/7 are hacked from time to time. There'll always be a gap somewhere)

But let's face it, the people that use cracked versions, have a much lower (or no) potential for buying in the first place anyway. Then if they have the crack, the potential is lowered even further.

You can never be fully safe, but it's worthwhile to put some time and effort into this to make life harder for the crackers out there.

But honestly, the C4D serial number system could definetly help here being more generic and hidden. A renewal of the serial system implementation is highly required because it is definetly useful to have the same system for all plugins (simply from the user's perspective). My wish for R19 ^^

There'll always be a gap somewhere)But let's face it, the people that use cracked versions, have a much lower (or no) potential for buying in the first place anyway. Then if they have the crack, the potential is lowered even further.

Although this is true to an extent, the fact remains that there are people who simply do not believe in paying for downloaded software of any kind. There are people using cracked plugins for commercial work, so they are making money from the plugin but not paying the developer. There are even studios doing the same; we know of more than one studio using cracked copies of Cinema itself. Such people are beneath contempt.

Originally posted by xxxxxxxx

You can never be fully safe, but it's worthwhile to put some time and effort into this to make life harder for the crackers out there.But honestly, the C4D serial number system could definetly help here being more generic and hidden. A renewal of the serial system implementation is highly required because it is definetly useful to have the same system for all plugins (simply from the user's perspective). My wish for R19 ^^

The problem is that any single routine encapsulated in the API is vulnerable. The hacker knows the code to look for and can bypass it even if it's hidden or obfuscated with protection software. MAXON don't seem to care - R18 will almost certainly be hacked within hours of release and that's been the case for years.

For an inexpensive plugin, devs might as well use the API routine anyway as it isn't worth expending the resources trying to prevent a crack. For top-end expensive plugins the only way to get any real protection (though not guaranteed to work of course!) is to ignore the useless API serial routine and construct a bespoke one. At the very least it may make it difficult enough that the hacker decides to go and crack someone else's plugin rather than yours.

Usually, they crack software with a dissasembler, so their modifications would most likely be done in assembly.

The trick is to release a buggy/crashy plugin, wait for them to crack it, and then do a silent update release of a stable plugin. Once the plugin has been cracked, they're bored with it and they move on to the next challenge.