Secure .gh file

Hi all,

Please clarify once and for all how I can secure a .gh file so no one except the once I trust can reach it.
I have tried to find a way but I’m only a novice programmer.

Today it’s not put under any form of license. Is it possible to put it into zoo?

Any help is much appreciated

Zip it? (with a password) :wink:

// Rolf

Afaik if it isn’t a plugin with a license file the the only way to protect your gh script is clustering + password protection but cluster password protection is easily breakable. To make it harder you could align all components in a cluster to one point but there are ways to auto space the components again to make it readable. So no, there is no way of secure protection.

Wouldn’t it be nice if you could connect a .gh file to for example zoo and from there control using licenskeys?
I’m quite sure it’s not that simple, but I think there are more companies that have made complex grasshopper definitions which they want to protect from the “outside”.

@danielbent By saying that passwords are easily broken, how do you mean? Is it still easy to brake if I add a password with lets say 500 letters/digits? (Excuse me if this sounds as a stupid question, but I don’t know anything on how to brake passwords =) )

@DavidRutten, is there any ongoing process in this matter?

Thanks in advance!

@socken, I understand why people would want to protect their “ideas”, but it’s virtually impossible when you start distributing them! There’s always someone who’s gonna figure out how to circumvent the measures you put into place.

Password protected clusters are rather easy to break into, no matter the password length. It’s not even a matter of brute-forcing you way into it. You can find a couple of guides by doing a simple web search. It’s even been recently deemed unsecure and dated by some folks at McNeel (I believe).

Although more difficult, there are even ways to break into “compiled” Grasshopper components by decompiling .Net, using an assembly browser, etc.

Wow, you must have quite the definition. :wink:

OK, so even with this people can easily corrupt the process. It’s not like Abobe Creative Cloud and other popular, home-phoning or cloud-connected softwares haven’t been pirated all over (which is not to say that you should part take in this). You could for instance spoof a fake, cracked local server that fails to connect home, and thus lets the fraudster in. On one hand you don’t want to force users to always be online, when using your program, but on the other that represents a loop hole.

Let’s for a second image that your definition was a cloud app that could only be used online. Even with this I’d imagine that multiple users could use the account only paying for a single license. Or somebody could manage to social engineer or steal the login from a paying user… There are endless scenarios.

I’d say that copy-protection is a lie! Just look at the music industry.
If your definition is that great, you have to come up with other ways to monetize it. Instead of collecting pennies by distributing it, you have to tour, play before the masses, sell merch, and win over more people that listen to your music, to use that analogy.
It’s as simple or hard as that. There are many ways to make money nowadays with the interwebs, but it’s not exactly easy.


Usually you bypass password checks by replacing the password with a known hash or you always return true if you enter a password by replacing/patching the validation routine. Decryption of password is only useful if you want to know the actual codeword,e.g. if you expect it to be used in other places as well. But since you can decompile Grasshopper, you reconstruct the hash creation, since you see the “salt and pepper” string added to it. the rest is just running a simple bruteforce routine to match with existing passwords and/or to create human alike combinations. Therefore I would always advise to use a password, created by a password manager. This at least prevents attackers not to guess your usual way of creating passwords.
Anyway, there is no security on datafiles. And to be honest with you. What do you need that for? As a Grasshopper user, you develop 1 % of anything in the chain, where most of the definitions are nothing worth to protect. Password protection is rather useful to prevent team members to accidentally change a definition.


My approach would be to make the script only work when online and then “phone-home” and make sure it gets the right answer before computing.
But I would still like to make it a bit harder than just “cluster/password”. Is it possible to compile the script to a binary somehow?

Even though it is not bullet proof it would be okay for my use case.

I think there is a thread in this forum where some forum members, including myself, introduced some other concepts going more in the direction of obfuscation and creating honeypots. E.g. I proposed to replace common components with custom components working exactly the same. But once the windows username does not match it computes slightly differently, assuming it works correctly. Silently adding bugs is much greater form of disturbance and waste of time for people, then obvious protection mechanism. Giving silent notifications might a bit problematic (legally), but could also be an effective mechanism in fighting theft of intellectual property (in case its worth to fight it).

It is not possible to protect a working file. It can always be extracted from memory using Reflection if it had already been loaded. The only possible protection is to encrypt the file as a whole and require a password to decrypt it prior to use (basically what @RIL suggested). This will prevent people from copying your algorithm. It will also prevent people from using your algorithm.

Since the protection people want is not possible, I haven’t thought much about it for gh2 yet. The only real solution here is to host the file on a server and perform all calculation remotely, sending only the results back to the end-user. This is where Rhino Compute comes in, which is not something I am involved in.


No. Components provide functionality, not the code required to run them. To try and reverse engineer them into another binary would violate the license agreement on various plugins.

1 Like

Thank you all for all the information collected in just 2 days.
I see that there are no possible way to secure this from falling into the wrong hands.
Hopefully something may come up in the future.

Thanks all!

1 Like

Yes it’s coming from people way above my pay graid that I need to protect it somehow now that it’s suppose to be launched within the company.

Perhaps one could protect a GH definition with a “suicide” option in the GH definition, which is activated when closing the definition (self-delete, that is).

Such a GH definition, if stored in a password protected zip format, can be used only once after being unzipped, and on close it’ll be gone.

To reopen the GH file one must again use the password to extract the GH file from the zip. And so on.

// Rolf

Nope, as soon as it exists anywhere at all (which it must if you want to run that file) it’s vulnerable to being extracted.

this might sound very stupid, I have little knowledge about this topic

I was wondering if could be possible to have a PC running only Rhino + Grasshopper, in particular that GH definition that I really want to protect

that particular definition would have “special” input components, that instead of containing geometries or data are “listening” for a remote connection that will transmit geometries / data / values from number sliders, and after computing everything is sending back the final result remotely?

edit: wow, ok, I could have said "something like the plugin Telepathy, but that works via IP address / internet ? "

Sure, but setting up a server with Rhino and Grasshopper running is an absolut overkill. Its super impractical. Furthermore if there is a risk that data leaves the company, then this is the initial problem. A CAD model of the latest development is probally even of higher value, as any script could. And nobody modifies CAD models on remote machines. If people believe their work is so super important, then only give access to a small group of people. Usually if data leaves the company, its most likely somebody of that company. Contractual penalties and the thread of legal steps are a much better way to stop this. If you care…

You cannot protect a GH definition absolutely & indefinitely. But you can secure it from most ordinary users.

As an additional security layer, you can obfuscate the canvas with a script that makes user interaction impractical, such as painting the entire canvas blank, overwriting the mouse, etc., whose only way for 99.99% of the people is to put a password that restores the original state or restart Rhino (because the rest of the documents get corrupted too).


I’m interested in this matter.
I have some more raw ideas and questions:

  • python is an interpreted language. After confirmed licensing, could it be possible to download and run on-the-fly some python code? Would this make any sense? More “secure”?

  • Is making a custom plugin any useful? Any components of the plugin will do an online check for licensing, if licence fails any component of the plugin won’t work. Reverse-engineering a gh plugin is sufficiently hard… or not?

  • Do the methods to crack password protected clusters needs to gh solver to be active? If yes, some custom c# inside the cluster could defend it from cracking…

@Dani_Abalde i like your style.
Sadly one can open a .gh file with solver locked…