Hello. I’m new to Ruby (and also to scripting languages).
I’d like to know if, since Ruby is a scripting language, there’s a way
to hide the code when deploying an application. I’d users to be unable
to see the source.
Is there a solution for that?
Thanks in advance
Hello. I’m new to Ruby (and also to scripting languages).
I’d like to know if, since Ruby is a scripting language, there’s a way
to hide the code when deploying an application. I’d users to be unable
to see the source.Is there a solution for that?
http://www.rubyinside.com/px-a-quick-and-silly-ruby-obfuscation-system-7.html
If you want to obfuscate code for business reasons, though, you might
want to use a different language (Perl is naturally obfuscated :P),
where obfuscators are available on a larger scale (Java and .NET
languages should offer that, with them being enterprise-y and all).
The question is: Why do you need that? If you license your software, you
could include a section on using the source in other applications a big,
big no-no (well, you’d reiterate copyright laws, basically), and that
your code is a trade secret. IANAL, though, nor do I play one on TV, so
take that with a grain of salt.
On Sep 1, 2007, at 5:41 AM, Phil wrote:
http://www.rubyinside.com/px-a-quick-and-silly-ruby-obfuscation-
applications a big, big no-no (well, you’d reiterate copyright
laws, basically), and that your code is a trade secret. IANAL,
though, nor do I play one on TV, so take that with a grain of salt.–
Phillip G.
If you really think you need to obfuscate your code, then you’re
doing something wrong. It is always possible to decompile stuff even
with compiled languages. PHP users often use obfuscation to try and
hide stuff.
Consider crafty use of file permissions settings, and simply burying
things in modules with hard to read names.
But ultimately, simply put pen to paper and make somebody sign a
contract if you have to. You could go to great lengths, but if it’s
really worth it, you’ll just use lawyers.
Well, then I guess that we can’t obfuscate the code with Ruby.
It’s not a necessity. It’s just that I’m used to compiled languages in
wich, if the project isn’t that complex, you basically give one file to
the user.
Thanks for your answers.
Michel C. wrote:
If I really need this kind of feature I guess I could develop a library in C that would encrypt all my '.rb' files into another file and decode them when launching the application... or something like that.
Why is that “trolling”? It’s actually “shrouding”. Not sure if that came
up
in this thread.
Could you use JRuby and ship .class files? That’s pretty shrouded. But,
as
usual, you are only raising the cost of hacking, not preventing it…
Michel C. wrote:
Thanks for your answers.
I actually worked on something like this but I finally decided that it
was hopeless. Since the encrypted Ruby code must be decrypted before
being handed off to the Ruby interpreter, there’s always going to be a
way for a sufficiently-motivated user to get their hands on the
unencrypted version of the program.
Michel C. wrote:
Do you have any usefull link that give some light on that matter?
No! Just dive into one of the Ruby Grammar attempts, and then change
each
intention-revealing symbol into an unreadable ugly one. Then scramble
the
blanks, and you are shrouded.
Though with some Ruby there’s not much shrouding left to go… 
Responding to the thread in general - just put your family jewels into
C++
behind a Ruby layer, and ship Ruby for the easy stuff that your clients
don’t need to steal…
Phlip wrote:
Why is that “trolling”? It’s actually “shrouding”. Not sure if that came
up
in this thread.Could you use JRuby and ship .class files? That’s pretty shrouded. But,
as
usual, you are only raising the cost of hacking, not preventing it…
Trolling because that came up just like that… Didn’t know if that kind
of technique was really used (I’m just a student).
But thanks.
Do you have any usefull link that give some light on that matter?
Phlip wrote:
Responding to the thread in general - just put your family jewels into
C++
behind a Ruby layer, and ship Ruby for the easy stuff that your clients
don’t need to steal…
That seems a fair solution. Although I’m not that deep into Ruby yet, I
saw some links concerning creating extensions for Ruby… but in C.
There must be something equivalent for C++…
That means that when I create for instance my extension (let’s say
“funky_extension”), the file concerning the extension will be compiled
therefore obfuscated? Is that what you’re talking about?
No! Just dive into one of the Ruby Grammar attempts, and then
your clients
don’t need to steal…–
Phlip
http://www.oreilly.com/catalog/9780596510657/
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax
Intellectual property theft is a social problem, not a technical one.
Social
problems should have social solutions, and not technical solutions. I
agree
with a former poster: I believe your answer consists of contracts,
licenses
and lawyers. It’s quite usually immensely cost and time intensive to
build a
technical solution that makes intellectual property theft unattractive
for a
large percentage of your target audience, there are very, very few cases
where it has arguably been made entirely unfeasible - and that took a
whole
lot of engineering.
Just my two cents,
Felix
On 9/1/07, Michel C. [email protected] wrote:
Well, then I guess that we can’t obfuscate the code with Ruby.
Sure you could. Just how effective obfuscation would be in any
language
depends on exactly what you’re trying to accomplish, but it will not
prevent
anyone with a fair bit of time and determination from figuring out what
your
code is doing. It might be enough to prevent the average person from
taking
your code and using it directly in their product/project, who knows…
Even
with a compiled language, it’s generally possible to decompile from the
bytecode or machine code.
It’s not a necessity. It’s just that I’m used to compiled languages in
wich, if the project isn’t that complex, you basically give one file to
the user.
Doesn’t seem related to obfuscation… Ruby has a pretty good package
management system called RubyGems, that might be what you’re looking
for?
Actually, you really couldn’t. You’d need to put the decryption key
somewhere where the client can get at it. Companies with much greater
resources than you and I try to do this all the time. The scheme is
generally broken in around 4 hours by some Nordic teenager (it’s cold
and
dark there, not much else to do.)
Good luck and have fun with Ruby!
On Sep 1, 2007, at 11:25 AM, Michel C. wrote:
saw some links concerning creating extensions for Ruby… but in C.
There must be something equivalent for C++…That means that when I create for instance my extension (let’s say
“funky_extension”), the file concerning the extension will be compiled
therefore obfuscated? Is that what you’re talking about?Posted via http://www.ruby-forum.com/.
You should use C for Ruby extensions.
Ruby is implemented in C.
JRuby might allow Java extensions…?
If you know C++ you can probably handle the C stuff.
Oh, one other idea for obfuscation, you could always also use Ruby
Inline for some things. (like a routine you run first to decrypt your
Ruby files or whatever.) Depending on the size of your app, you could
pretty easily make it at least confusing to look at with a simple
Rot13, or just replacing all newline characters in the Ruby files
with some unique identifier string. (other than the first one called,
which would include Inline C or whatever to decrypt)
You could make it even simpler. Consider Ruby’s predefined variables
(they’re globals that start with $) and command line flags and
arguments.
there might some simple to implement but not so obvious tricks you
could do there.
John J. wrote:
You should use C for Ruby extensions.
The best thing about these extensions is wrapping rVALUE (IIRC) in a C++
class that presents all its native methods as C++ methods. From there
the
rest is easy!
----- Original Message -----
From: “Michel C.” [email protected]
That seems a fair solution. Although I’m not that deep into Ruby yet, I
saw some links concerning creating extensions for Ruby… but in C.
There must be something equivalent for C++…That means that when I create for instance my extension (let’s say
“funky_extension”), the file concerning the extension will be compiled
therefore obfuscated? Is that what you’re talking about?
Yes. But…
In general, asking how to obfuscate code so others can’t steal it is
“solution probleming”. It’s just appeasing clue-impaired investors who
think
their investment will return nothing if someone “steals” the code,
re-skins
it, and publishes it as an alternate solution.
This is self-aggrandizing. The problem of people going crazy trying to
steal
your software is a problem most ISVs would dearly love to have. And
studies
have shown that competitors generally don’t want to use your code,
when
they can see it. The code is only useful to you.
An investor’s money goes to building a team and a system to create,
test,
deploy, and market that code. This system is what a competitor needs,
and
it’s very hard to steal it.
So, write lots of unit tests, and don’t publish them. The code’s source
will
be useless!
Intellectual property theft is a social problem, not a technical one.
Agreed.
Social problems should have social solutions, and not technical solutions.
I
agree with a former poster: I believe your answer consists of contracts,
licenses and lawyers. It’s quite usually immensely cost and time intensive
to
build a technical solution that makes intellectual property theft
unattractive
for a large percentage of your target audience, there are very, very few
cases where it has arguably been made entirely unfeasible - and that took
a
whole lot of engineering.
Disagree. There is, obviously, a market for code obfuscation with
affordable tools. The challenges are higher for a highly dynamic
Language
like Ruby, but less so for languages like Java or C#, which have the
additional benefit of creating bytecode/IL, which can be obfuscated
easier.
Code obfuscation is one step of many to “keep honest people honest”.
Fighting a war with crackers will not end well, since there are more
crackers out there than people writing an application.
And in regard to social solutions, so far the DMCA hasn’t stopped
copyright
infringement nor IP “theft”.
Besides, agreements can only help as long as both parties see themselves
bound by them. And if an agreement is sloppily worded, or seen through a
rose-colored lens (SCOX, anybody?), you end up with the same problem you
had
in the beginning…
From: “Michel C.” [email protected]
Hello. I’m new to Ruby (and also to scripting languages).
I’d like to know if, since Ruby is a scripting language, there’s a way
to hide the code when deploying an application. I’d users to be unable
to see the source.Is there a solution for that?
A commercial obfuscator was announced last year, ZenObfuscate:
http://blog.zenspider.com/archives/2006/07/zenobfuscate_no.html
This free project, Ruby2CExtension, works along similar principles:
http://ruby2cext.rubyforge.org/
Both have some limitations on certain kinds of ruby expressions
that can’t be handled.
(I’ve never used either one, just read about them.)
On the balance, I agree with what others are saying in this thread:
If you can find a way to avoid needing to obfuscate the code, so
much the better.
My current project is part C++, part Ruby. So I figure I’ll just
leave all the ruby code open source, and put the registration check
logic in the C++ components.
Regards,
Bill
Phil wrote:
Disagree. There is, obviously, a market for code obfuscation with
affordable tools. The challenges are higher for a highly dynamic
Language
like Ruby, but less so for languages like Java or C#, which have the
additional benefit of creating bytecode/IL, which can be obfuscated
easier.
There’s a market for lots of “bossware” - thinks like MS Project, that
nobody really needs…
Code obfuscation is one step of many to “keep honest people honest”.
Fighting a war with crackers will not end well, since there are more
crackers out there than people writing an application.
Right idea but wrong formula. For every week spent securing code, a
cracker
can spend an hour cracking it. That’s just entropy - it’s easier to
destroy
than create.
And in regard to social solutions, so far the DMCA hasn’t stopped
copyright
infringement nor IP “theft”.
09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0, holmes. See you in
GITMO!
Michel C. wrote:
That means that when I create for instance my extension (let’s say
“funky_extension”), the file concerning the extension will be compiled
therefore obfuscated? Is that what you’re talking about?Posted via http://www.ruby-forum.com/.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100255
http://www.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2006/10&file=w5tow.xml&xsl=article.xsl&
Are links that might be of interest if you want to work with C++ and
Ruby.
Generally speaking there is no such thing as a way to prevent people
from
finding stuff out about your software – You can make it harder but you
can’t
stop it completly.
I remember I once had to run a Program in order to get a link as part of
a
game I was playing with a friend (the link was hard coded in the exe).
When
you don’t use WINE, it’s a little hard to run Windows software under
Unix even
for a game. =/
So I took a dump of the .exe using some of the posix programs on the
unix box
and found the URL easy as pie, along with information about the VS
project
files and that it was done in classic Visual BASIC. I’ve never had to
use such
software before but I’d reckon it probably would return a fair bit of
stuff if
some one wanted to look deep enough into some ones programs. A
determined
enough individual will find it, the lazy won’t.
I doubt you have much to worry about though, unless you plan on making
millions with one program -> Lawyers and your countries laws are
better
protection !!!
Disagree. There is, obviously, a market for code obfuscation with
affordable tools. The challenges are higher for a highly dynamic
Language
like Ruby, but less so for languages like Java or C#, which have the
additional benefit of creating bytecode/IL, which can be obfuscated
easier.There’s a market for lots of “bossware” - thinks like MS Project,
that nobody really needs…
Gantt charts are not just unnecessary. They, and their brethren, are
risk
management. Risk management is vital, even, nay especially, in software
development (You do want to keep your job, don’t you? That can mean that
a
pet project is axed by the Powers That Be to keep the company in
business…).
Agile is nothing more but risk management taken to the development team.
From YAGNI, via DRY, to TTD, it’S risk management.
Sure, a programmer won’t need skills in risk management, business logic,
marketing, sales, or other social skills. A developer, though, does.
Code obfuscation is one step of many to “keep honest people honest”.
Fighting a war with crackers will not end well, since there are more
crackers out there than people writing an application.Right idea but wrong formula. For every week spent securing code, a
cracker can spend an hour cracking it. That’s just entropy - it’s easier
to
destroy than create.
Add a blank line, introduce a new feature, run the obfuscator after your
build before shipping. Crack won’t work anymore. Code obfuscation
doesn’t
(and shouldn’t!) mean “I better rename my PatentedBusinessLogic class
Xxfghdofhdzsdfgdsb”, but “Run a tool as part of my build7deplyoment
process
to make the resulting built harder to read”. Of course, less dynamic
languages like Ruby are better suited to this. And I don’t think it is a
dealbreaker for using Ruby, either.
Of course, if you spend months on that Really Clever Method To End
Software
Cracking, you are betting on the wrong horse.
And as I said: it is one step of keeping honest people honest. You
won’t
be able to best the crackers. Never will be. But you can raise the bar
one
bit more to sell probably a lot more units. microISVs are specialists in
doing that.
Patrick McKenzie said it better than me, where this all fits into the
bigger
picture:
http://microisvjournal.wordpress.com/2006/09/05/everything-you-need-to-know-
about-registration-systems/
09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0, holmes. See you in
GITMO!
Exactly. The DMCA is something that happens to “other people, never
me!”, or
can backfire nastily (the Science Fiction and Fantasy Writer Association
is
currently (ab)using the DMCA to hilarious effect), but it didn’t really
stop
file sharing, or copyright infringement, either.
It is a social problem. It is a) largely perceived as a victimless
crime,
and b) the MPAA/RIAA and equivalents aren’t really making it easy to
take
them serious in their efforts. (See McKenzie’s blog post for reasons
All in all, that doesn’t mean you shouldn’t protect your own IP,
especially
if it is what guarantees your livelihood. This is less, much less, acute
for
a bank’s REST-API developer for intranet communication, than for
somebody
who lives from the sales of his/her software.
This story is old as the universe.
Sombody like to make a something once and live happily ever after and
someone else has a different idea about it.
The amount of money that companies spend on securing their software is
in direct correlation with number of keygens and patches available on
the net.
You should think what is that you are selling.
I know it’s not a code. Perhaps its solution, service, idea, time,
creativity but is definitely not a code.
If you build something that gain some successes do not think that you
can live from the past glory. The current success is a history. You
should move to new challenges. Ones that try to mimic your solution
will always be one step behind.
The only solution is open source.
The clever people will help you make a bright idea of yours great.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs