Secure .gh file

You can. But it can be too overkill.

Depending on the protection software, it can be from very easy to mediocre

No.

1 Like

But you can run code when the component is added to the document, which happens when you open it, whether you have the canvas locked or not.

EDIT: Well, maybe, not sure after a second think :v

Yep, thats also my point. But aren’t you ordinary yourself if you leave it as an gh script? I mean hardcoding a definition and protecting a compiled plugin is the next natural step once you created a useful functionality. Protecting against the average joe with a compiled plugin is much more effective.

1 Like

Of course a compiled binary is safer but I’d say sometimes you’d prefer not to install anything on the user’s computer.

There’s no way to fully protect a gh file as David mentions, but we used to put scripts inside clusters and then assign a password back in the day when issuing things to consultants. Might be sufficient for your purposes, not sure.

You could load a library on runtime… Not the intentional way but doable.

1 Like

That’s a good idea

Personally I would move every component into one place and it’s quite obfuscated…

1 Like

yes quite practical. As I said, I would also integrate silent bugs if the definition detects unusual users

Yes you can. But since you are already writing a library, you can do whatever you want to do.

Here it is.
It is possible to launch an external task (on windows level, outside rhino) to check if grasshopper have solver active or not?
It could force-close rhino and grasshopper the instant the solver is disabled.

Protecting some code should be doable if the solver is active… no?


:rofl: :rofl: :rofl:

That’s what I meant with aligning all components in one place, so they overlay each other.

But since you are already writing a library, you can do whatever you want to do.

Yes, but few so annoying. :clown_face:

And when GH2 is released as open source it still needs to be secure from someone who has created their own version with all checks removed. This is in fact already possible since Grasshopper itself can be disassembled, modified, reassembled and even modified in its compiled state using libraries such as Mono.Cecil

If you’re trying to protect your files against non-programmers, clusters with passwords are enough, if you’re trying to protect your files against programmers, you’re in the wrong Universe.

9 Likes

You don’t need to create an own version actually. The thing is, any member of an object in memory has an address in memory. Even if you cannot decompile it, you can read (reflection) and replace any member on runtime. If this is still not possible, Disassembling and Debugging an app and patching the jump instructions of an if-statement is death simple if you can read assembler. That’s why it is very hard to protect software in general.

Thats it is very hard to protect .NET software in general.

1 Like

Disassembling is not Decompiling. Works for a C/C++ as well.

afais it’s a bit different. .NET’s code is jitted, which is very predictable and cannot be interferred with the software developer (unless you are using AOT, e.g., CoreRT). But C/C++ developer may protect the binary directly and creates nightmares of disassembling.

1 Like

True, but as soon as you manage to attach it to a debugger at some point you step through any statement until you reach the desired place. Take the cluster password. You can spend a lot of effort in obfuscating the assembler code, but at some point you need to compare two hashes. This comparison can be manipulated. A countermeasure would be to use this comparison functionality at multiple other places, making it harder to simply replace it. But it’s difficult and leads to horrible code. This also explains why almost any offline software gets cracked. It is a fight against windmills. But yes you are right, .Net code is easier to bypass and being able to decompile and recreated code makes it especially easy.