I was speaking with a co-worker today about the disappointment we feel
when we can't write commercial, distributable client-side code with Ruby
today...there's just no good way to protect your IP on the client side.
We came upon a simple(?) idea and I was hoping that the List might help us
expand it and fill in some gaps:
Could one not modify the source of the Ruby interpreter to load a public
key and then only accept code encrypted with the equivalent private
version? Would this provide adequate protection, or does it only mean
that the hacker would have to download the interpreter and make the same
modifications, loading my public key into it, and programmatically to spit
out the unencrypted code after it has passed through decryption? Is there
any way to make this sufficiently hard to do so to the point where any
reasonably complex application is protected? Similar to byte code
obfuscation?
Could one not modify the source of the Ruby interpreter to load a public
key and then only accept code encrypted with the equivalent private
version? Would this provide adequate protection, or does it only mean
that the hacker would have to download the interpreter and make the same
modifications, loading my public key into it, and programmatically to spit
out the unencrypted code after it has passed through decryption? Is there
any way to make this sufficiently hard to do so to the point where any
reasonably complex application is protected? Similar to byte code
obfuscation?
Things like this have been suggested before, but the basic problem is that
if the interpreter is dealing with plain text at some point to interpret
it, someone will be able to get to it if they really want. They could
either modify the interpreter to dump it as you say or even just dump
memory.
You would have to analyze how savvy your users are, and just how much they
would want the source code. If they are happy with how it works and don't
have intentions of replacing your product with something of their own, I'd
doubt they'd bother to try and figure out how to get readable source code.
I'm of the belief that any form of security can be broken by someone
determined enough (in both the real and digital world), so in my eyes it
is usually a matter of making things more difficult for normal people.
Another issue in regards to Ruby is that I believe the license makes it
difficult to make changes like this without having to release the source,
which of course makes it much easier to circumvent any encryption changes.
I recall reading Lothar Scholz talking about this before...care to chime
in Lothar?
Could one not modify the source of the Ruby interpreter to load a public
key and then only accept code encrypted with the equivalent private
version? Would this provide adequate protection, or does it only mean
that the hacker would have to download the interpreter and make the same
modifications, loading my public key into it, and programmatically to spit
out the unencrypted code after it has passed through decryption? Is there
any way to make this sufficiently hard to do so to the point where any
reasonably complex application is protected? Similar to byte code
obfuscation?
The only way of doing this securely is by running as much code as possible on your server and having thin clients.
Obfuscation may be a short term solution, but it still won't protect users from stealing, cracking or reverse engineering your code. (All those can also be done with the machine code traditionally produced by lower level languages like C.)
Note that software is still something falls under copyright. Using the law to go against people stealing your applications is one way.
The better way is to open your source up and change to a support business model or do something similar to MySQL.
Could one not modify the source of the Ruby interpreter to
load a public key and then only accept code encrypted with
the equivalent private version? Would this provide
adequate protection, or does it only mean
If the code is encrypted, how are you going to decrypt it?
I think you have your key types mixed up. It's the public
key that can encrypt and the private key that can decrypt.
There are two applications for public/private keys as far as
i can see here:
~ 1) Use the private key to SIGN the file (it is still a
~ cleartext ruby script) and you can verify where it came
~ from. This is not what you want. e.g. if you are
~ accepting code via a web interface and you want to
~ ensure it's from a trusted source before running it,
~ you can set up those trusted sources before hand and
~ verify the signature.
~ 2) Hack the ruby executable to contain the PRIVATE key and
~ the PASSPHRASE so that it can decrypt something
~ encrypted with the PUBLIC key. But
~ you don't want to do this.
Number 2 gives you the effect you want, but it certainly
isn't something you want to do. You may as well post your
private key and passphrase on your homepage.
And like everyone's already said, unless ruby doesn't have
to decrypt it, you're still screwed. Not only will they
have your private key and passphrase, they can also watch
ruby decrypt it and get the source anyways.
hell... truss would be the only "hacker tool" you need
If the code is encrypted, how are you going to decrypt it?
I think you have your key types mixed up. It's the public
key that can encrypt and the private key that can decrypt.
You're absolutely right...I did flub that in my description, didn't I? I
suppose the point here is question the viability of packaging a key (the
private key) in the ruby executable to allow decryption of code the
encrypted with the public key. Public/private is a little confusing in
this scenario, so I'd prefer a locking key and unlocking key. I would
still keep the public key private and secret, so it's truly not "public".
Now, how easy it would be to retrieve the unlocking key from the ruby
executable, I have no idea. I've been led to believe by Lothar's comments
that it's possible to conceal it or the actual decryption point well
enough that anyone would have a very difficult or impossible time getting
at it, but that's possibly (probably?) naive.
You can use Exerb (http://exerb.sourceforge.jp/index.en.html) fow
windows platfirm to distribute client side Ruby applications. The main
idea of Exerb, AFAIK, is to dump parsed syntax tree and store it inside
executable.
p.s. This will be wonderful if official Ruby interpreter can do same
thing by itself.
Python, BTW, can store compiled programs in *.pyc files, and load it
when original source file is not changed.
I was speaking with a co-worker today about the disappointment we feel
when we can't write commercial, distributable client-side code with Ruby
today...there's just no good way to protect your IP on the client side.
We came upon a simple(?) idea and I was hoping that the List might help us
expand it and fill in some gaps:
Could one not modify the source of the Ruby interpreter to load a public
key and then only accept code encrypted with the equivalent private
version? Would this provide adequate protection, or does it only mean
that the hacker would have to download the interpreter and make the same
modifications, loading my public key into it, and programmatically to spit
out the unencrypted code after it has passed through decryption? Is there
any way to make this sufficiently hard to do so to the point where any
reasonably complex application is protected? Similar to byte code
obfuscation?
Thanks for your insight.
John
I use zend encoder now and again when I have a good idea and I don't want to give up the recipe to just everyone.
Zend encoder works by doing a pre compile to byte code which makes it illegible. It also spices up the deal by locking the code with a key from the PC being used. Then when Zend optimizer sees the PHP code is already precompiled its job becomes easier. So things speed up accordingly.
So to do this with Ruby would mean that a precompiler or optimizer would have to be built first. Something that the server could run and interprete the byte code. As of yet there is nothing like this for Ruby. But it is being worked on I might guess.
Trying to do it otherwise is a pain in the butt. I have tried with PHP and helped with a few obsfucation projects in PHP ASP and VB.
···
--
Tesla - Alternating current, the first modern day opensource project?
Another issue in regards to Ruby is that I believe the license makes it
difficult to make changes like this without having to release the source,
which of course makes it much easier to circumvent any encryption changes.
I recall reading Lothar Scholz talking about this before...care to chime
in Lothar?
As a matter of fact, I just looked through an older thread that I had
initiated on compilation to native code in which Lothar reponsded
outlining a possible similar approach to what I've mentioned, except that
it involved changing some function names, etc.
Lothar, I'd love to hear more about your possible approach and if you did
indeed run into licensing issues.
This is just not an option sometimes. There still is a large place for
closed software in the industry, and Ruby needs a Zend-like solution that
PHP developers enjoy to protect if that's needed.
···
On 8/18/05, Florian Groß <florgro@gmail.com> wrote:
John Wells wrote:
The better way is to open your source up and change to a support
business model or do something similar to MySQL.
--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
The mono project allows you to create machine executable code by
embedding the runtime intrepreter together with your code. Perhaps
something like that can be done with Ruby as well. I don't know how
difficult it is, but the algorithms are probably transferable from the
mono project.
···
On 8/19/05, John Wells <lists@sourceillustrated.com> wrote:
Derek Wyatt said:
> If the code is encrypted, how are you going to decrypt it?
>
> I think you have your key types mixed up. It's the public
> key that can encrypt and the private key that can decrypt.
You're absolutely right...I did flub that in my description, didn't I? I
suppose the point here is question the viability of packaging a key (the
private key) in the ruby executable to allow decryption of code the
encrypted with the public key. Public/private is a little confusing in
this scenario, so I'd prefer a locking key and unlocking key. I would
still keep the public key private and secret, so it's truly not "public".
Now, how easy it would be to retrieve the unlocking key from the ruby
executable, I have no idea. I've been led to believe by Lothar's comments
that it's possible to conceal it or the actual decryption point well
enough that anyone would have a very difficult or impossible time getting
at it, but that's possibly (probably?) naive.
I'm not sure if you're talking about a specific type of encryption, but most
such codes can encrypt with either key and decrypt with either key.
If I want to send a (secret) message to you, I can encrypt it with your public
key and you will be able to decrypt it with your private key.
If I want to send a message to everyone and "guarantee my signature" (i.e.,
sign it), I can encrypt it with my private key. If it can be decrypted with
my public key, it is (almost) a guarantee that I did originate the message.
regards,
Randy Kramer
···
On Friday 19 August 2005 11:46 am, Derek Wyatt wrote:
I think you have your key types mixed up. It's the public
key that can encrypt and the private key that can decrypt.
(Unless it has changed recently) Please understand that if you open an
exerb generated exe file in a text editor you can scroll to a section
where your program is visible as plain text.
-Rich
···
On 8/20/05, dr <druid.bpg@gmail.com> wrote:
You can use Exerb (http://exerb.sourceforge.jp/index.en.html\) fow
windows platfirm to distribute client side Ruby applications. The main
idea of Exerb, AFAIK, is to dump parsed syntax tree and store it inside
executable.
p.s. This will be wonderful if official Ruby interpreter can do same
thing by itself.
Python, BTW, can store compiled programs in *.pyc files, and load it
when original source file is not changed.
Another issue in regards to Ruby is that I believe the license makes it
difficult to make changes like this without having to release the source,
which of course makes it much easier to circumvent any encryption changes.
I recall reading Lothar Scholz talking about this before...care to chime
in Lothar?
As a matter of fact, I just looked through an older thread that I had
initiated on compilation to native code in which Lothar reponsded
outlining a possible similar approach to what I've mentioned, except that
it involved changing some function names, etc.
Lothar, I'd love to hear more about your possible approach and if you did
indeed run into licensing issues.
If you ask matz for this it's no problem he can give you his
permission to create a personalized ruby interpreter version. I also
patched ruby.exe for Arachno but the patches are available if somebody
ask (only 2 persons did in the past), so i didn't ask him.
Thats no problem and with this you can make your program as protected
as possible (without hardware dongles). If the OP wants to know how to
do this in a very good way he should send me a personal mail. The
first rule of security is not to talk about security.
As other persons said without TPM it is not possible to protect a
program but it is almost possible - the few hackers that have the
skills to crack good protected code are normally only interested in a
few mainstream applications. And the average one has no chance if it
is done right (and in a non generic way).
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
This is just not an option sometimes. There still is a large place for closed software in the industry, and Ruby needs a Zend-like solution that PHP developers enjoy to protect if that's needed.
I don't see why we would need to obfuscate source code on the server side. Can you elaborate?
I'm not sure if you're talking about a specific type of encryption, but most such codes can encrypt with either key and decrypt with either key.
Correct.
If I want to send a (secret) message to you, I can encrypt it with your public key and you will be able to decrypt it with your private key.
Correct in principle. In practice, I encrypt the message using a symmetric cipher, encrypt that key using your public key, and send both ciphertexts. That way I can send a private message to multiple recipients without having to encrypt the entire message multiple times.
If I want to send a message to everyone and "guarantee my signature" (i.e., sign it), I can encrypt it with my private key. If it can be decrypted with my public key, it is (almost) a guarantee that I did originate the message.
Correct in principle. In practice, I encrypt a hash of the message in my private key. You hash the message and check that your result matches the one I sent. That way, a message can have multiple signers in any order.
With Zend, you can distribute your PHP scripts in an encoded fashion.
Modernbill and Kayako currently do this, as well as many other commercial
PHP scripts. They also include license limitations like IP restriction,
hostname restriction, etc.
···
On 8/18/05, Florian Groß <florgro@gmail.com> wrote:
Robert Oliver wrote:
> This is just not an option sometimes. There still is a large place for
> closed software in the industry, and Ruby needs a Zend-like solution
that
> PHP developers enjoy to protect if that's needed.
I don't see why we would need to obfuscate source code on the server
side. Can you elaborate?
--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
On Friday 19 August 2005 09:44 pm, Steven Jenkins wrote:
Correct in principle. In practice, I encrypt the message using a
symmetric cipher, encrypt that key using your public key, and send both
ciphertexts. That way I can send a private message to multiple
recipients without having to encrypt the entire message multiple times.
The first rule of security is not to talk about security.
Precisely the opposite:
For academics: yes.
For practical use: no.
Its simple a complete different topic if you want to know the quality
of an algorithm or how to embedd it into an application. As alread
mentionend it is impossible to have a save program executable if you
are not using TPM Point.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
