Script Editor - Compiled Project Security - Exposing Module Source Code?

Rhino Rhino for Windows
, , ,
1

Hi @eirannejad,

Is this the intended behavior of modules that are compiled with the Script Editor to expose the actual code files to the end user in the AppData/Roaming folder?

If so, isn’t that a huge problem as anyone could have easy access to that source code contained within a module of a plugin?

image
image1095×248 16.4 KB

When I look at other plugins in the packages/8.0 folder they have .dlls, some .json settings stuff here and there, but never do I see any exposed C# or Python files anywhere.

Code that gets compiled as a command with the Script Editor Package Project does not produce a “cmds” folder with the exposed code so I wouldn’t expect the modules to either but it is creating this “libs” folder with subfolders and then the actual source code of the modules.

I would think the compiler would create something like

“myplugin.yak”
“myplugin.gha”
“myplugin.rhp”
“myplugin.rui”
“mainfiest.yml”

and then:

“mypluginlibs.dll” for the module code or something along these lines.

I understand shared/ folder being created (although would be nice to have that in a .dll as well)

but nowhere in the documentation did I see mention of “libs” being a folder with source code exposed to the end users.

Please advise me on if I am doing something wrong as I definitely don’t want to share my plugin in this state.

Thank you!

2

Always assume that when you are sharing scripts in published plugins, the source is either embedded or deployed on the target machine. Not all supported languages allow ‘compiling’ scripts into machine code so published plugins carry the source (and package requirements embedded within the source).

In case of CPython, I need to put the python module on the local disk so I can add the path to python runtime. Same with dotnet libs. They get compiled as a .dll and placed on disk which means that it is trivial to look at the source or grab and use that in other places

I’ll put a notice for this in the documentation.

4

I see, thanks for the explanation and clarifying that.

While I am aware that there’s always a level of exposure and potential for reverse engineering I was shocked to see the actual .py files up for grabs that easily in the module libs/ folder but it does make sense when you explain it.

Sounds like I have more options for containment when using C# or in general if I keep code in my main scripts/commands those will at least live inside the .rhp files and such?

Though I imagine the .rhp and .gha files can be reverse engineered as well… but at least it is not as easy as actually just directly opening a .py file on disk I hope? haha

5

Please meet GitHub - icsharpcode/ILSpy: .NET Decompiler with support for PDB generation, ReadyToRun, Metadata (&more) - cross-platform! and other .NET decompilers. Obfuscation tools are sometimes used to make it harder for users of decompilers to follow the code. But also that is only a minor issue.

For native DLLs it takes a bit more effort, but it is not impossible.

Python is an interpreted language, not a compiled one.

edit/addendum:

Often in EULAs you’ll find clauses that tell you reverse-engineering is not allowed. Legal protection is pretty much the only protection you have. Enforcing all that is hard, and I can’t imagine that taking actual action is going to be less hard.

The best protection is to not release your code to users. I suppose that is one reason internet services exist. The IP stays on vendor-controlled equipment, does not ever end up on user equipment.

If only people played nice.

2 Likes