Forum: Ruby on Rails Protecting the Ruby on Rails source code (encrypting and making the code compilable and not to view)

35a1aa1878be0e90b65821fdb36423db?d=identicon&s=25 Sheyam Selvaraj (Guest)
on 2014-06-28 05:10
(Received via mailing list)
I am trying to implement my application in my client place and the
application is developed in Ruby on Rails.

Since I am going to deploy on their premise I wish to make the code as
encrypted can be compiled but not be able to view, use or copy.


How can I do that using open-source tools.
Cf5880598f9ed484de58d5f388d5c1e2?d=identicon&s=25 Loganathan S. (loganathan_s)
on 2014-06-28 18:05
(Received via mailing list)
You can use ruby encoder (http://rubyencoder.com)

Regards,
Logan

Sent from mobile device
6883e5ef03484d4fcef507d7b4f1d243?d=identicon&s=25 Matt Jones (Guest)
on 2014-06-28 19:41
(Received via mailing list)
On Friday, 27 June 2014 22:09:09 UTC-5, Sheyam Selvaraj wrote:
>
> I am trying to implement my application in my client place and the
> application is developed in Ruby on Rails.
>
> Since I am going to deploy on their premise I wish to make the code as
> encrypted can be compiled but not be able to view, use or copy.
>
>
> How can I do that using open-source tools.
>

You can't do that with ANY tools. Even "Ruby Encoder" can be reversed to
regenerate source code, as can alternative approaches (using Jruby and
compiling to .class files, etc). Even compiled *machine code* can be
reversed back into C:

http://www.backerstreet.com/decompiler/decompilers.htm

If they can execute the code, they can reassemble it. You're trying to
protect code by putting a lock on it and then GIVING THEM THE KEY.

Ultimately, it's a question of effort: you can make extracting source
more
difficult, but never impossible.

Also, this is an enormous red flag (from Ruby Encoder's FAQ):

"Some of our techniques, for obvious reasons, are not documented outside
of
our core team and this is to provide a hightened level of protection for
the Ruby or Ruby on Rails scripts."

A basic rule of security: if somebody's promising that their SUPER
SEKRIT
ALGORITHMS can do something impossible, watch out.

Take the $199 and spend it on getting a good lawyer to write up a
contract
that specifies strong penalties for stealing source - but realize that
*enforcing* such a contract will cost even more money.

--Matt Jones
D3c7095ae5aa0706a36d8d4a3b1a4957?d=identicon&s=25 Danny O'Kelley (Guest)
on 2014-06-30 08:03
(Received via mailing list)
Will the application be living on your hardware or your client's? If
it's
your hardware, I suppose there isn't much to it. Set up the server and
retain root/admin access.

If you're in a situation where you must deploy on the client's hardware,
I
think your best bet is to establish a VM guest with your application.
Set
it up as if it were your own hardware (retain root/admin access) and
configure the VM guest to talk to your client's network.

Your client will still have access to the machine, so if they wanted to
invest the time they could probably get at your application (in both
cases
I would use FDE). In this case at least they have to put some effort
into
it.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.