[Talk] Ruby Debugger for SketchUp 14+

Dan Rathbun · 13 May 2014, 02:24

Yea.. I agree I poked around in the NPP Plugin "How to" today. The C++ stuff is too complex to learn quickly.

I did not find any Ruby binding, so Python would be the next best thing. It is similar to ruby (without all the "end"s.)

I tried first to install PythonScript in my %AppData% path where all my other NPP plugins are installed, but got an error when trying to open the Python Console. (Something about Python being an ANSI version, and incompatible with the Unicode NPP.)

Installing it in the %ProgramFiles% path works (as the doc stated that is where to install it.) So it will require Admin privileges.

Dan Rathbun · 13 May 2014, 02:55

I opened the config dialog, hilited "sudb.py" and clicked on the "Add" button. It was added to the top-level "Python Script" menu.

I then made a (quick and dirty) BMP copy of the SU icon, and saved it into "Notepad++/plugins/images/Toolbar" and added the script to the Toolbar list, then hilited it (in the list,) and went thru the file picker after clicking the "Set Icon" button.

SketchUp.icon.zip

I also set the "Initization" to ATSTARTUP:

Restarted Notepad++ and the SketchUp icon appears on the toolbar.

Dan Rathbun · 13 May 2014, 03:16

And doing the above caused a textfile "PythonScriptStartup.cnf" to be created in "%AppData%\Roaming\Notepad++\plugins\config" (UTF-8 no BOM, Dos/Win EOLs)

containing:

ITEM/C;\Program Files (x86)\Notepad++\plugins\PythonScript\scripts\sudb.py
TOOLBAR/C;\Program Files (x86)\Notepad++\plugins\PythonScript\scripts\sudb.py/C;\Program Files (x86)\Notepad++\plugins\images\Toolbar\SketchUp.bmp
SETTING/PREFERINSTALLEDPYTHON/1
SETTING/STARTUP/ATSTARTUP

Jim · 13 May 2014, 08:01

@dan rathbun said:

And doing the above caused a textfile "PythonScriptStartup.cnf" to be created in "%AppData%\Roaming\Notepad++\plugins\config" (UTF-8 no BOM, Dos/Win EOLs)

Oh cool, this means a Toolbar with icons can be created from the plugin. Thanks.

Too bad Tooltips on the icons do not seem to be supported...

Jim · 13 May 2014, 21:20

I went ahead and made a github repo for this.

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

GitHub (github.com)

Dan, would you prefer a new topic for discussing issues specifically related to this project?

Dan Rathbun · 14 May 2014, 09:45

@jim said:

Dan, would you prefer a new topic for discussing issues specifically related to this project?

Yes that would be good ... and can also log issues on the repo site.

avariant · 30 May 2014, 01:23

I haven't had a chance to look at the debugger yet but the first thing I thought when I read about was, is this a backdoor that can be used to defeat the .rbs encrypted rubies? Does the debugger reveal anything about the current line of execution, or does it just deliver line numbers? When displaying data about a variable, does it volunteer variable names or does it just respond with a value?

I would be very disappointed to find out it did.

Jim · 30 May 2014, 01:31

The debugger shows the filename and line number of .rbs files. It will not show the contents of the file.

It can, however list variable names and values in .rbs files.

I have not tried to set a breakpoint on a .rbs, so I am not sure if it is allowed. But i found the debugger will follow observers into .rbs files.

slbaumgartner · 30 May 2014, 13:17

@avariant said:

I haven't had a chance to look at the debugger yet but the first thing I thought when I read about was, is this a backdoor that can be used to defeat the .rbs encrypted rubies? Does the debugger reveal anything about the current line of execution, or does it just deliver line numbers? When displaying data about a variable, does it volunteer variable names or does it just respond with a value?

I would be very disappointed to find out it did.

You raise some very interesting questions.

If, as I suspect, the rbs unscrambler is an SU facility that decodes the rbs before handing it to a standard Ruby interpreter, then the plaintext source and all other aspects of your plugin would indeed be visible to the debugger. Exploiting this hole isn't as easy as it might sound, since you have to somehow stop Ruby at a breakpoint before the ide commands will work - a bit like shooting in the dark - but I can see that some clever person may find a way.

I think this may come down to how SU implements the debugger ide library. That is, the ide could detect that the source file is rbs and refuse to debug it. This is possible because the SU debugger library implements the ide protocol itself, it does not use the standard debug interface or Gem.

Steve

jiminy-billy-bob · 30 May 2014, 13:39

rbs files aren't safe anyway. There are rbs unscramblers.
I tested one to see how safe rbs would be, and it works reeaaally well. It outputs a perfectly clean rb file.

So yeah, I would not protect sensitive stuff with that.

slbaumgartner · 31 May 2014, 15:19

@jiminy-billy-bob said:

rbs files aren't safe anyway. There are rbs unscramblers.
I tested one to see how safe rbs would be, and it works reeaaally well. It outputs a perfectly clean rb file.

So yeah, I would not protect sensitive stuff with that.

This falls into the realm of the old cliche "locks only keep honest people honest". The decryption key and code for rbs are necessarily embedded in the SketchUp application, and the same key is used for all rbs files. Any competent hacker can easily defeat the rbs scrambling. As JBB points out, several have already published code to do so.

So the question isn't whether rbs is secure (it clearly is not), it is whether you believe there are enough dishonest people in the world that you will lose significant intellectual property value when they unscramble your rbs. The same question applies to the potential backdoor via the debugger.

Steve

Trogluddite · 2 Jun 2014, 11:02

@avariant said:

When displaying data about a variable, does it volunteer variable names or does it just respond with a value?

I would be very disappointed to find out it did

The debugger is exposing nothing new here, the same thing could be done anyway through any of the SU consoles by any savvy Rubyist - using nothing but standard Kernel method calls. Setting trace functions and using the returned bindings to read local and instance variables, get the current method and its call signature, read the call stack etc... can all be done from even the most basic install of Ruby.

You can't actually read the code lines unless they are in a 'plain text' source file (the scrambler presumably 'evals' the unscrambled code, which precludes seeing the source) - but there's not much that can be done to secure the other information without losing the consoles - which would make life very difficult for the amateur developers that we all rely on for our toys!