Protecting Ruby code

[Sasha Bee]

We are just starting a new project and it is going to be a commercial
application. So we have a reasonable question now - how can we protect
our code? I have searched the web but found nothing really useful. Can
anyone suggest any solutions or ideas about code protection for Ruby?

Thanks

 

[James Britt]

We are just starting a new project and it is going to be a commercial
application. So we have a reasonable question now - how can we protect
our code? I have searched the web but found nothing really useful. Can
anyone suggest any solutions or ideas about code protection for Ruby?

Make it a JRuby app (effectively making it a Java app) and compile the
rb files into .class files using jrubyc. Then jar it up as an
executable jar file.

The rawr tool will very soon (as it looks) make this snake-simple to do.

http://rubyforge.org/projects/rawr/

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[Ade Inovica]

We are just starting a new project and it is going to be a commercial
application. So we have a reasonable question now - how can we protect
our code? I have searched the web but found nothing really useful. Can
anyone suggest any solutions or ideas about code protection for Ruby?

Thanks

Sascha, I agree with James that its worth looking at making it a java
app. May I also suggest you try www.rubyencoder.com which is a project
I've been working on (disclaimer!). There are a few different ways of
doing what you want, however you need to look at whether you really need
to protect it. What kind of commercial application are you creating and
what is the market for it? We created ours as we needed to install a
legacy app on someones server and we were concerned about the code being
open, but I think most people don't have these needs. Let me know if
you need some help.

Ade

 

[Sasha Bee]

Sascha, I agree with James that its worth looking at making it a java
app. May I also suggest you try www.rubyencoder.com which is a project
I've been working on (disclaimer!). There are a few different ways of
doing what you want, however you need to look at whether you really need
to protect it. What kind of commercial application are you creating and
what is the market for it? We created ours as we needed to install a
legacy app on someones server and we were concerned about the code being
open, but I think most people don't have these needs. Let me know if
you need some help.

Ade

Ade, thank you for your suggestion. I have tried www.rubyencoder.com
quickly and it looks like it does what we need. Now I think I need to
spend some more time to check how it will work with our code. Not much
code though yet as we just started the project Making a java app is
good idea too although this rubyencoder is very easy to use.

Thanks

 

[Mike Gold]

rubyencoder.com:

"The RubyEncoder protects Ruby scripts by compiling Ruby source code
into a bytecode format and this is followed by encryption. This protects
your scripts from reverse engineering. Ruby scripts protected with
RubyEncoder can be executed but cannot be used to extract Ruby source
code as there is no source code remaining within the protected script in
any form."

I do not see how this is possible, even in principle.

Unless you have rewritten ruby in a *serious* way via redesigning the
AST. The AST is buck-naked exposed in memory, flapping its genitals for
all to see. And even if you did rewrite eval.c, (1) I would expect
serious compatibility problems, and (2) your new AST could be
reverse-engineered.

That leaves you with code obfuscation -- renaming constants, variables,
etc. Which is all fine and good. But that is all you have.

But don't get me wrong -- your product may be useful. Obfuscation may
suffice for the level of "protection" desired (not much, but perhaps
sufficient). However the other claims being made on the website are not
true, and could not be true even in principle.

To summarize, if you knew that someone could extract the full ruby
source from your rubyencoder'd application, minus nice variable and
constant names, would be sorry that you paid 300 USD? And would you
feel mislead by the advertising?

 

[Ryan Davis]

Unless you have rewritten ruby in a *serious* way via redesigning the
AST. The AST is buck-naked exposed in memory, flapping its genitals
for
all to see. And even if you did rewrite eval.c, (1) I would expect
serious compatibility problems, and (2) your new AST could be
reverse-engineered.

I was curious about that as well... zenobfuscate did its job without
ever exposing itself via ruby internals. I don't know of another way
to do this for ruby code. Unless their bytecode is bundled with an
entirely separate VM to execute them? I still don't see that as being
feasible.

 

[James Britt]

Call a good lawyer. Have the lawyer draft a contract that everyone
who buys your application must sign before receiving your code. The
contract should state that they must not reverse engineer your
application or look at the code. Hold them to it, and sue them if you
ever find any evidence of them breaching your contract.

You run the risk of having your customers feel that you consider them
criminals-in-the-making (See: MPAA and RIAA for classic examples).

Seriously, there is no real way to prevent people from trying to
reverse engineer your code if they are really determined to do so.
Everything you try to do to prevent this will only make it more
complicated, but anyone determined enough will eventually succeed. All
technological schemes are eventually doomed to failure, your only real
recourse is legal.

Or not. You *could* accept that a small number of people will do bad
things, but that most folks won't, and especially if there's even a
moderate barrier to pirating or reverse engineering. And if and when
someone does do something bad, weigh the cost of legal action (both in
terms of dollars and in PR) and maybe consider it a cost of doing business.

If you make it hard or onerous to buy or use a product, you may
inadvertently encourage people to use a pirated version (as seems to be
the case with Spore).

When looking to prevent pirating or reverse engineering, consider *why*
people might even bother to do that (e.g. pricing, annoying product
activation scheme, DRM, etc.), and consider that maybe legal action and
technology are not always the best solution.


--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[Martin DeMello]

Seriously, there is no real way to prevent people from trying to
reverse engineer your code if they are really determined to do so.
Everything you try to do to prevent this will only make it more
complicated, but anyone determined enough will eventually succeed. All
technological schemes are eventually doomed to failure, your only real
recourse is legal.

OTOH the more expensive you make it to do, the less people will do it.

martin

 

[Nedry]

I know some people who think that makes it more fun... and a more
likely to try...

OTOH the more expensive you make it to do, the less people will do it.

martin

--
This planet has - or rather had - a problem, which was this: most of
the people living on it were unhappy for pretty much of the time. Many
solutions were suggested for this problem, but most of these were
largely concerned with the movements of small green pieces of paper,
which is odd because on the whole it wasn't the small green pieces of
paper that were unhappy.

-Douglas Adams

 

[Todd Benson]

Call a good lawyer. Have the lawyer draft a contract that everyone
who buys your application must sign before receiving your code. The
contract should state that they must not reverse engineer your
application or look at the code. Hold them to it, and sue them if you
ever find any evidence of them breaching your contract.

Seriously, there is no real way to prevent people from trying to
reverse engineer your code if they are really determined to do so.
Everything you try to do to prevent this will only make it more
complicated, but anyone determined enough will eventually succeed. All
technological schemes are eventually doomed to failure, your only real
recourse is legal.

I new a police officer that would often say, "We don't lock our doors
to keep the bad guys out. We lock them to keep the honest people
honest."

Todd

 

[David Masover]

You run the risk of having your customers feel that you consider them
criminals-in-the-making (See: MPAA and RIAA for classic examples).

Not really. Almost every piece of commercial software in existence is subject
to an end-user license agreement. Users are used to simply clicking through.

What's more, it seems relatively unlikely that anyone would try to use said
code for anything serious. If they do, you're no longer suing a consumer,
you're suing a competitor who's stolen your code -- different animal
entirely.

If you're only talking about preventing piracy between consumers, that's a
different matter -- and it has little to do with source code. I see no reason
why existing DRM solutions would be any more or less effective with an
interpreted language than they are with, for example, movies.

 

[David Masover]

OTOH the more expensive you make it to do, the less people will do it.

It depends what you're trying to prevent.

Because remember... It only takes one person to crack it open and push it up
onto a torrent site. Unless you make it so expensive that no one person will
do it, you've failed.