Have not seen this topic discussed here, so would like to have an exchange of opinions.
Currently I observe the following situation: within commercial side products developed to work in Rhino (plugins, GHA components and maybe others) plugin is the most common product being offered commercially and only few GHA components are distributed on the commercial basis.
At the beginning I was also thinking about Plugin as consolidated product development but some time ago I decided to switch to custom GH components.
For me I see the following benefits:
still possible to use all Custom classes
components are independent and are very flexible to use in combination with standard Gh components as well as other components
no routine in writing many of event handling functions
Definitely there are also disadvantages.
What I am worried about is the security, as I guess GHA component is rather easy to “crack”.
Are there any ways to protect it properly?
I encourage everybody to give an opinion/comments. Maybe also persons already distributing GHA components commercially can comment here.
That depends on the sort of push-back you’re expecting. There’s almost no protection against a savvy programmer who will be able to disassemble your plug-in and swap out or inject instructions.
Some people prefer to obfuscate their assemblies, which typically makes disassembly a bit harder in the near future, but can lead to massive problems in the long term. Obfuscation works by changing assemblies in ways that almost or genuinely violate the rules for valid assemblies. Some violations aren’t tested in the current frameworks so you can get away with them. But then when there’s a framework update suddenly those mangled assemblies no longer work and bring down the entire Rhino app when we try to load them. I can’t imagine this is good for either your or our respective brands.
The only real way to protect your code is to not give it to anyone. That means either run a consultancy service where clients hire you to solve their problems for them, or run your code on a webserver and only send the results back to the user.
I hardly imagine this to work in GH.
Moreover, users are used to work in Rhino Offline, so this would be difficult, I believe.
Even if this would work - transfer of data to Cloud and back would delay performance substantially.
Yes, not only will there be a significant lag, which may be okay if the calculations take a long time anyway. But many people will -for good reason- not be comfortable uploading their data to some server on the web.
In order to answer your original question, I think it needs to be made more specific. For example; “ignoring genuine crackers* and hackers**, what can be done to prevent a plug-in from running without a valid license?”
This will at least allow us to state potential ways forward, but you still need to narrow it down. Is a license perpetual, or time-limited? Time-based licensing is tricky because it’s very difficult to get a reliable date. The system date/time can be modified by the user, you’d almost certainly have to go online.
I’m not an expert in this field, but I know enough to tell you it’s very difficult, very time-consuming, probably annoying to paying customers, and you may even run into legal issues if you ever do get successful enough for patent trolls to start squeezing you.
* Cracker = someone who will modify an assembly by removing or injecting additional instructions.
** Hacker = someone who will inspect an assembly in order to generate bogus license data that will nevertheless pass muster.
Thanks @DavidRutten for such a detailed explanation.
Well, actually I was thinking about time-limited license but I think not to go this way exactly for the reason you mentioned. In such case perpetual license would probably be a choice, but extended support and updates to be treated separately. Actually I also think about flexibility to select components, however this is initial thinking only.
Would be nice also to hear from current projects, where components are distributed on the commercial basis.
Maybe @karamba3d can comment here to share experience.
@menno, I know MARIN was doing smth on the plugin distribution side but not sure about GH components.
@DavidRutten is it possible to incorporate lmtools (FlexLM) inside a grasshopper component?
As far as I know lmtools come with another tool that generates a string a mix of MAC address and hardware IDs with some additional encryption and then the client uses a file with lmtools.exe.
You can also specify a time-trial period inside that file. And any attempt from the user to edit this file results in license failure.
Or perhaps this can go inside the wishlist for Rhino7 using McNeel online licensing with Rhino Account (for a fee in the pocket of McNeel of course ;))
We used to have the FlexNET licensing system, but due to the fact that we need to use that in various Linux distributions that were not supported by FlexNET, we moved away and are now using another system.
As far as Grasshopper is concerned, when a GHA is loaded, we check the license using a class derived from GH_AssemblyPriority that is present in the GHA assembly, as is explained here http://www.grasshopper3d.com/forum/topics/addcategoryicon
If such a class is present, the PriorityLoad method is executed prior to loading the GHA. The return value instructs the loader to continue or abort loading.
Protecting a dotnet plugin is even more difficult than a dotnet program. Though various obfuscators are available on the market, as far as I know, the highest level of protection is to decrypt IL code on the fly and write them to current EIP location, which is still too easy to dump if you get the correct tool.
For an offline installation, I would recommend to wrap your core function in a native DLL and protect it with some heavy-duty solutions such as VMProtect.
In my case, I distribute my plugin for free and charge commercial users for customized private versions.
I did some commercial solution for a client, doing it like Keyu. Usually I only protect with obfuscation, just to get protection from reverse engineering (at least from the majority, those who can bypass obfuscation can probably write a custom solution by themselves), but in this case I was writing the critical code in C.
However isn’t it a greater problem to actually find people paying for a commercial gh plugin? And those who do, probably won’t have a problem paying for a license. I mean, at least in those countries, where intellectual property is protected and violation has legal consequences, professional clients rather pay little money instead of risking trouble. Cracking is way to easy nowadays. So why doing all the effort?
(Off topic) @gankeyu, following your message I had a look at your Pancake Plugin, this is absolutely awesome! I didn’t hear about it but some functions are exactely what we need (like version tracking, internalize all at once and portability check) It should be more advertised
