Asp Forum - Ruby for closed source projects

Michael Gebhart

2/5/2005 1:51:00 AM

Hi,

well, open source is pretty nice. But in some cases I don't want to show
the sourcecode to other users. Maybe because of an encryption, or an
special algorithm. Is there any chance to hide the code? Compiling the
application with the interpreter directly?

Greetings

Mike

15 Answers

Florian Gross

2/5/2005 3:00:00 AM

Michael Gebhart wrote:

> well, open source is pretty nice. But in some cases I don't want to show
> the sourcecode to other users. Maybe because of an encryption, or an
> special algorithm. Is there any chance to hide the code? Compiling the
> application with the interpreter directly?

Not that I want to sound academical or religious or anything, but if
your encryption algorithms need to operate in the dark to be secure they
probably aren't working very well. Also note that copying source code is
not legal so you might not even need to obfuscate it to get protection
against naive copy attempts.

That aside it's quite hard to hide code well -- just have a look at Java
where there's disassemblers that can produce pretty readable code from
byte code and there's lots of people reconstructing algorithms directly
from machine code -- if the machine can read it, it is quite likely that
an human will also be able to do so -- it's just a matter of how hard it
will be for him to do so. You're really only safe if you have the code
logic residing on an external server which will just take input and give
back output without disclosing how it processed the information.

There's tools available that will make reconstructing of the source code
non-trivial for inexperienced users -- RubyScript2Exe[1] and Exerb[2]
come to mind. But note that these just encode the unfiltered source code
directly and if somebody knows how that is done he can reconstruct the
original source code.

Other approaches include taking the code itself and making it harder to
read for humans (via variable/method/class name substitution or removing
meaningless whitespace) and dumping Ruby's syntax tree directly. The
latter is quite similar to how Java does this and can for example be
accomplished via NodeWrap[3]. I think I also heard about somebody
modifying Ruby itself (you are allowed to do so even without releasing
the source code of your modified Ruby) so that it would use a different
mechanism for loading code.

I hope you can understand the trouble associated with all this and will
still find a solution that works for you.

[1]
http://www.google.com/url?sa=U&start=1&q=http://www.erikveen.dds.nl/rubyscript2exe/&...
[2] http://exerb.sourceforge.jp/ind...
[3] http://rubyforge.org/projects...

Michael Gebhart

2/5/2005 10:49:00 AM

Hi,

first thanks for your answer.

> Not that I want to sound academical or religious or anything, but if
> your encryption algorithms need to operate in the dark to be secure they
> probably aren't working very well. Also note that copying source code is
> not legal so you might not even need to obfuscate it to get protection
> against naive copy attempts.

Yes, sure you are right. But one example: I wanna have a registration code
in my application. The user gets a code to activate some more features. In
the code, there only is a flag reg=true/false. When the code is entered,
the application checks it and sets the variable to true, or false. The
user can now take a look at my code and simply change this part. After the
check he sets: reg=true.

So my mechanism to check the code is not useful. Also if I try to do the
check of the code on a external server and give back a true or false, the
user can change this part in the code directly.

Ok, now you can say: registration codes are ugly and everything has to be
opened :) Sure, but if it is a commercial project, there is no other way.

I only could appeal to the users forthrightness.

And yes: With Java I had the same problem. And with C# I will have it too.
But: I thought Microsoft would develop their applications in C# too. But
then the users also can see the code. Maybe Microsoft will keep on using
C++ for the huge projects? And only use C# for not important parts?

Greetings

Mike

Greetings

Mike

> That aside it's quite hard to hide code well -- just have a look at Java
> where there's disassemblers that can produce pretty readable code from
> byte code and there's lots of people reconstructing algorithms directly
> from machine code -- if the machine can read it, it is quite likely that
> an human will also be able to do so -- it's just a matter of how hard it
> will be for him to do so. You're really only safe if you have the code
> logic residing on an external server which will just take input and give
> back output without disclosing how it processed the information.
>
> There's tools available that will make reconstructing of the source code
> non-trivial for inexperienced users -- RubyScript2Exe[1] and Exerb[2]
> come to mind. But note that these just encode the unfiltered source code
> directly and if somebody knows how that is done he can reconstruct the
> original source code.
>
> Other approaches include taking the code itself and making it harder to
> read for humans (via variable/method/class name substitution or removing
> meaningless whitespace) and dumping Ruby's syntax tree directly. The
> latter is quite similar to how Java does this and can for example be
> accomplished via NodeWrap[3]. I think I also heard about somebody
> modifying Ruby itself (you are allowed to do so even without releasing
> the source code of your modified Ruby) so that it would use a different
> mechanism for loading code.
>
> I hope you can understand the trouble associated with all this and will
> still find a solution that works for you.
>
> [1]
> http://www.google.com/url?sa=U&start=1&q=http://www.erikveen.dds.nl/rubyscript2exe/&...
> [2] http://exerb.sourceforge.jp/ind...
> [3] http://rubyforge.org/projects...

Christian Neukirchen

2/5/2005 11:15:00 AM

Eric Schwartz

2/7/2005 10:25:00 PM

Michael Gebhart <mail@miketech.net> writes:
> Yes, sure you are right. But one example: I wanna have a registration code
> in my application. The user gets a code to activate some more features. In
> the code, there only is a flag reg=true/false. When the code is entered,
> the application checks it and sets the variable to true, or false. The
> user can now take a look at my code and simply change this part. After the
> check he sets: reg=true.

If your customers are thieves, then you should sue them. Or get
better customers. Or both, possibly.

> Ok, now you can say: registration codes are ugly and everything has to be
> opened :) Sure, but if it is a commercial project, there is no other way.

If it is a commercial project, then you should get yourself some good
lawyers (you should have them anyway), and have them scare the holy
bejeezus out of anyone tempted to steal from you. The fact is, this
is the only recourse you truly have, in the end.

> I only could appeal to the users forthrightness.

And their lack of desire to be sued. Consider: most customers don't
want to steal from you-- if they get $X of value from your software,
and you charge them $X-$epsilon, as long as epsilon is sufficiently
large, everybody's happy.

> And yes: With Java I had the same problem. And with C# I will have it too.
> But: I thought Microsoft would develop their applications in C# too. But
> then the users also can see the code. Maybe Microsoft will keep on using
> C++ for the huge projects? And only use C# for not important parts?

It doesn't matter; people can decompile C++ as well. In the end, the
lawyers are the only ones who can do anything about it.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

Robert McGovern

2/7/2005 11:33:00 PM

> Yes, sure you are right. But one example: I wanna have a registration code
> in my application. The user gets a code to activate some more features. In
> the code, there only is a flag reg=true/false. When the code is entered,
> the application checks it and sets the variable to true, or false. The
> user can now take a look at my code and simply change this part. After the
> check he sets: reg=true.

Could you export some of these parts to a c module?

Bill Kelly

2/8/2005 1:11:00 AM

From: "Eric Schwartz" <emschwar@pobox.com>
> Michael Gebhart <mail@miketech.net> writes:
> > Yes, sure you are right. But one example: I wanna have a registration code
> > in my application. The user gets a code to activate some more features. In
> > the code, there only is a flag reg=true/false. When the code is entered,
> > the application checks it and sets the variable to true, or false. The
> > user can now take a look at my code and simply change this part. After the
> > check he sets: reg=true.
>
> If your customers are thieves, then you should sue them. Or get
> better customers. Or both, possibly.

It just doesn't work that way. At least not in the realm
of video games and other relatively low-cost "shrink wrap"
software.

> > Ok, now you can say: registration codes are ugly and everything has to be
> > opened :) Sure, but if it is a commercial project, there is no other way.
>
> If it is a commercial project, then you should get yourself some good
> lawyers (you should have them anyway), and have them scare the holy
> bejeezus out of anyone tempted to steal from you. The fact is, this
> is the only recourse you truly have, in the end.

Many of us have exactly 1 employee in our companies.
But just look at the big boys, like Adobe, Electronic
Arts, Microsoft... Plenty of lawyers. Plenty of problems
with piracy??? You bet.

> > I only could appeal to the users forthrightness.
>
> And their lack of desire to be sued. Consider: most customers don't
> want to steal from you-- if they get $X of value from your software,
> and you charge them $X-$epsilon, as long as epsilon is sufficiently
> large, everybody's happy.

My current employer (my paying job :) makes software that
is very highly rated by its users. Nevertheless, people
distribute cracked registration passwords--and it's not
to "demo" the software, because this software has a very
liberal trial period. Every day we see torrents of people
who allow our software to check our website for updates
(we aren't sneaky about the checks, btw) and who we can
tell are using cracked passwords.

If you have actually worked in this field, producing low
cost "shrink wrap" software products, and you don't have
a problem with piracy, I would love to know more about
your approach.

Regards,

Bill

Eric Schwartz

2/8/2005 1:44:00 AM

"Bill Kelly" <billk@cts.com> writes:
> Many of us have exactly 1 employee in our companies.
> But just look at the big boys, like Adobe, Electronic
> Arts, Microsoft... Plenty of lawyers. Plenty of problems
> with piracy??? You bet.

This is my point. If they, with all their resources and lawyerage,
can't stop it, how can you possibly hope to? I guarantee they have
many more, and smarter, people than you or I working on it, and they
still can't stop pirates. To me, this suggests it's a mug's game, but
YMMV. :)

> If you have actually worked in this field, producing low
> cost "shrink wrap" software products, and you don't have
> a problem with piracy, I would love to know more about
> your approach.

It's not a matter of not having a problem with piracy, it's keeping
that problem down to a manageable level. Take iTunes, for instance:
you can't tell me that even with the RIAA suing dead people for
copyright infringement, that I couldn't find a download of nearly any
pop tune I cared to if I tried hard enough. So how do they make
money? By pricing product at a level that even though people could
pirate it, they look at it and say, "Yeah, I could steal that song,
but hey, it's only a buck, why not?"

In any event, the problem is that, at least with ruby, you can't get
there from here. There simply is no way to run ruby code without
giving the OS, and thus the user, permission to read it. You can't
get there with C# or Java either, but you can pretend a little while
longer, if you like.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

Brian McCallister

2/8/2005 3:03:00 AM

On Feb 5, 2005, at 5:55 AM, Michael Gebhart wrote:

> The user gets a code to activate some more features. In
> the code, there only is a flag reg=true/false. When the code is
> entered,
> the application checks it and sets the variable to true, or false. The
> user can now take a look at my code and simply change this part. After
> the
> check he sets: reg=true.

Bundle public keys for each unlockable feature and require a "key" to
unlock it which is actually the signed name of the user (signed using
the private key for the feature.

Cryptographically secure feature unlocking, with the side effect of
letting you know the initial source (though possibly not purposeful) of
any pirated versions.

-Brian

Assaph Mehr

2/8/2005 3:18:00 AM

> Bundle public keys for each unlockable feature and require a "key" to

> unlock it which is actually the signed name of the user (signed using

> the private key for the feature.
>
> Cryptographically secure feature unlocking, with the side effect of
> letting you know the initial source (though possibly not purposeful)
of
> any pirated versions.

Doesn't help. At some point in the program there is the (conceptual) if
statement:
if user_has_rights
do_this
else
yell_at_user_to_buy
end

For any piece of software it is possible for a human to find this if
statement and change 'user_has_rights' to true. No matter how you
complicate it with public keys, the routine that checks the keys can
always be altered to return true.

What you should be aiming to achieve is protection from casual piracy:
it should not be obvious to the user how to break your software. The
user must always think 'I can pay $x for this, or spend y amount of
time intentionally breaking it. Is it worth it?'. There will always be
people for whom cracking the software is the prefered option (and
indeed, the higher the protection the greater the itch to break it). In
the long run you cannot stop them. It's just a matter of making the
others agree to pay rather than crack the software.

This is not security by obscurity, rather a simpler model of
cost-effective security: both for you to develop and for the user to
crack. Make evreyone happy by supplying cost effective solutions.

Cheers,
Assaph

John Wilger

2/8/2005 1:21:00 PM

On Tue, 8 Feb 2005 12:20:12 +0900, Assaph Mehr <assaph@gmail.com> wrote:
> Doesn't help. At some point in the program there is the (conceptual) if
> statement:
> if user_has_rights
> do_this
> else
> yell_at_user_to_buy
> end

Actually, this method _could_ work with Ruby. You _don't_ need to have
that conditional, because Ruby has open class/module definitions. You
could separate the extra functionality into a separate set of files.
Then create an encrypted package of the files. When the files are
pulled out of the package and placed in the correct directory, the
extra functionality would be enabled.

Sure, someone could distribute the files illegally after gaining
access, but that's a slightly different issue.

--
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

comp.lang.ruby

Ruby for closed source projects

Michael Gebhart

Florian Gross

Michael Gebhart

Christian Neukirchen

Eric Schwartz

Robert McGovern

Bill Kelly

Eric Schwartz

Brian McCallister

Assaph Mehr

John Wilger

x Login to ForumsZone