The page: Homepage | SketchUp Developer
says
“You may want to check your license at a few critical locations in your code for added security.” I would change that “may” to “must”.
Unlike compiled languages, ruby files must be scrambled to protect their content.
.
But any extensions that follow the file/folder naming conventions advocated ( a separate simple main.rb, a separate simple LoaderandMenu.rb, and one or more other rbs for individual command methods) would be fairly simple to reverse engineer. The tutorial doesn’t say to scramble the main.rb so that exposes the module name. If I put the licensing code in the scrambled loader, a little trial and error would allow me to recreate that also. Remember I would have access to a Youtube Video showing toolbar naming. If that doesn’t work I buy one copy (or get a limited time free trial). That exposes the module and method naming to the ruby console if it’s different from the file or menu names.
All I have to do is recreate the rb file making the license call; the rest can remain scrambled. So licensing MUST be checked and scrambled at the individual command method level.
`2. It is well known that the biggest threats to security are not external hackers: the biggest threat is from disgruntled employees. Someone within Trimble knows the unscramble algorithm and it will have a market price. He needs a pay raise.
We generally recommend people to use the C API for improved protection. Scrambled RBS files etc is a simple first front protection - not a complete solution.
if you want to make your plugin more save, create you own security. Don’t thrust on the scrambler and the license system! Just do a quick google on ‘sketchup unscrambler’ and you know why.
If you like to know more about creating a saver plugin you can contact me by email (guy@skalp4sketchup.com). We spend 2 months full time on the security of our plugin.
Well, the more of the extension is in C/C++ the harder it is to bypass the checks.
Personally, for an extension I’m working on, the core functionality is in C++ and I would sprinkle license test in there. So even if anyone unscramble the RBS files they won’t be able to override the license checks without breaking the extension.
But learning C is also much harder then learning ruby. Lots of plugin developers are designers who just start with a little programming to make there modeling life easier. Also the fact that you can’t use the SLAPI to interact with a live model so you need to create ruby and C together is harder then just plain ruby or plain C.
True, C/C++ is harder to learn. But Ruby, being a scripting language so dynamic that even private methods isn’t private - it let anyone modify pretty much anything is much easier to hack.
So if you are really concerned about security one need to invest in C/C++. The Ruby API license is there as a small precaution but will never be as secure as the C/C++ API. It’s one of them things where you need to pick what is most important and what is good enough for your needs.
It should also be noted that no license scheme, ever, is 100% secure. If there is a will there is a way. It’s a matter of how high the threshold is.
This might be a silly idea, but could the Ruby plugin be “embeded” in a c extension? For example, could I store my entire ruby plugin in a c/c++ string, then the c/c++ part would basically call ruby to eval the string?
Does this lead to the possibility of creating a c/c++ source code template where people could more-or-less drop-in their ruby code and compile it into an extension?
It is always possible to decompile a .so to assembly language. One can also readily view any text strings used (for example if it embeds Ruby source code to interpret at run time). The external function names are visible (so that Ruby can know how to call them) and if the library was not “stripped” other symbols are also visible. Despite all that, however, it is usually a very tedious and technical exercise to attempt to reconstruct the approximate source code or to understand what the assembly language code does. This is the land of advanced hackers, and unless there is high value they are not likely to take the effort.
Yes this is perfect possible. This is exactly what we do. We have a ruby script to prepare our normal ruby code, place it inside our C extension, compile it on mac and on windows and make an rbz file of it.
Yes, there are compilers, but as long as you don’t ship with debug symbols the function names and variables will not be read. You won’t be able to do a 1:1 restoration of the original source. It’d need a good amount of work to figure out what the code actually do.
The problem with that is to eval in Ruby you need to convert the source code to a Ruby String and pass it to the Ruby interpreter - meaning you are sending the unscrambled source code into the Ruby environment itself and it can be intercepted.
@thomthom you are right that the ruby code can be intercepted when eval from C, but the same problem happens when loading ruby the normal way. The advantage you have by eval it from C is that you can decide when exactly your code will be loaded. If you use the standard loading everything is loaded at once on startup and you can grab the complete source code at once. Create a smart loader from C gives you the opportunity to only load some parts at a time and even to monkey patch your own code by using the same method names for different blocks of code. This way you make it the hacker a lot harder because he has to understand your code and rewrite a big part of your code.