C++ plugin cracked
-
On 06/06/2016 at 08:39, xxxxxxxx wrote:
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?-Pim
-
On 06/06/2016 at 19:15, xxxxxxxx wrote:
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.
-
On 15/07/2016 at 09:26, xxxxxxxx wrote:
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. -
On 15/07/2016 at 13:33, xxxxxxxx wrote:
Why buy? Use cURL (https://curl.haxx.se/libcurl/ | http://www.curlpp.org/)
I hope that password is not encoded in your Plugins though
-
On 15/07/2016 at 15:08, xxxxxxxx wrote:
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.
-
On 15/07/2016 at 17:09, xxxxxxxx wrote:
You need to compile curl as a static library and link that into your plugin project. This way the user doesn't need to include anything other than your plugin.
I documented up how to do this a few years ago, along with OpenSSL so that you can access https servers.
http://tools4polygons.blogspot.co.nz/2015/12/a-c-library-for-communicating-with.html
Scroll down to the section "Compiling libcURL".
-
On 15/07/2016 at 20:04, xxxxxxxx wrote:
Thank you so much. I will look into it.
Will this be the same for Mac OS and Windows? -
On 15/07/2016 at 20:22, xxxxxxxx wrote:
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.
-
On 27/07/2016 at 02:18, xxxxxxxx wrote:
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 ^^
-
On 27/07/2016 at 08:58, xxxxxxxx wrote:
Originally posted by xxxxxxxx
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.
Steve
-
On 07/08/2016 at 11:36, xxxxxxxx wrote:
Howdy,
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.
Adios,
Cactus Dan -
On 08/08/2016 at 18:14, xxxxxxxx wrote:
A coworker and I used to joke about ways to mess with people who use cracked versions of our software. Kinda similar to your idea, Dan, just more evil.
The bottom line is: it's probably not a good idea. When someone downloads a cracked version of your software and it's buggy, it doesn't give a very good impression.
Sure, he didn't buy it, but he also won't recommend it to any potential buyers. Maybe he will even tell people not to use it because it's so bad.
Of course that is assuming people who used cracked software have friends