Forum: Ruby Writing a interpreter extension

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Kris (Guest)
on 2006-05-19 17:27
When writing a interpreter extension are there any hooks in to the
different stages of interpretation?

In particular I would like to pre-process the ruby file/class being
interpreted. Is a ruby class block loaded from a file or read line by
line?

Many thanks, K.
Eric H. (Guest)
on 2006-05-19 21:13
(Received via mailing list)
On May 19, 2006, at 6:28 AM, Kris wrote:

> When writing a interpreter extension are there any hooks in to the
> different stages of interpretation?
>
> In particular I would like to pre-process the ruby file/class being
> interpreted. Is a ruby class block loaded from a file or read line by
> line?

Override require.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Kris (Guest)
on 2006-05-19 21:50
Many thanks Eric, do you have a code example by any chance to get me
started, I'm not so familiar with C!


Eric H. wrote:
> On May 19, 2006, at 6:28 AM, Kris wrote:
>
>> When writing a interpreter extension are there any hooks in to the
>> different stages of interpretation?
>>
>> In particular I would like to pre-process the ruby file/class being
>> interpreted. Is a ruby class block loaded from a file or read line by
>> line?
>
> Override require.
>
> --
> Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com
Eric H. (Guest)
on 2006-05-19 23:02
(Received via mailing list)
On May 19, 2006, at 10:50 AM, Kris wrote:
>>> line?
>>
>> Override require.
>
> Many thanks Eric, do you have a code example by any chance to get me
> started, I'm not so familiar with C!

You don't need to write any C at all.  Write it in Ruby.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Logan C. (Guest)
on 2006-05-20 00:12
(Received via mailing list)
On May 19, 2006, at 2:59 PM, Eric H. wrote:

>>>> line by
> Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com
>
>
>

For example:


module Kernel
   alias old_require require

   def require(file)
     # first check if it's already been required by searching
$LOADED_FEATURES
     # Search $LOAD_PATH for the file
     if it's an .rb file then
       File.open(full_path_and_filename) do |f|
          # Preprocess f and  if neccessary do any changes and eval them
       end
       # add the file to $LOADED_FEATURES
     else
       old_require(file)
     end
   end
end
Kris (Guest)
on 2006-05-21 19:29
Thanks for the reply.

The problem with doing it in Ruby is that there is no where to hide the
decryption key... It would be in plain text, unless I'm am missing
something?

Logan C. wrote:
> On May 19, 2006, at 2:59 PM, Eric H. wrote:
>
>>>>> line by
>> Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
>> This implementation is HODEL-HASH-9600 compliant
>>
>> http://trackmap.robotcoop.com
>>
>>
>>
>
> For example:
>
>
> module Kernel
>    alias old_require require
>
>    def require(file)
>      # first check if it's already been required by searching
> $LOADED_FEATURES
>      # Search $LOAD_PATH for the file
>      if it's an .rb file then
>        File.open(full_path_and_filename) do |f|
>           # Preprocess f and  if neccessary do any changes and eval them
>        end
>        # add the file to $LOADED_FEATURES
>      else
>        old_require(file)
>      end
>    end
> end
Sam R. (Guest)
on 2006-05-21 20:41
(Received via mailing list)
Quoting removed_email_address@domain.invalid, on Mon, May 22, 2006 at 12:29:24AM
+0900:
> Thanks for the reply.
>
> The problem with doing it in Ruby is that there is no where to hide the
> decryption key... It would be in plain text, unless I'm am missing
> something?

Doing it in compiled C would leave it in plain text, too, just mildly
more obfuscated.

Sam
Kris (Guest)
on 2006-05-22 12:04
It would take a higher skill set to extract it though.
And you can write code that helps hide a key in a binary file.

So is it possible to write a C extension that overrides the ruby require
in the same way as the previous ruby example?

Many thanks, K.

Sam R. wrote:
> Quoting removed_email_address@domain.invalid, on Mon, May 22, 2006 at 12:29:24AM
> +0900:
>> Thanks for the reply.
>>
>> The problem with doing it in Ruby is that there is no where to hide the
>> decryption key... It would be in plain text, unless I'm am missing
>> something?
>
> Doing it in compiled C would leave it in plain text, too, just mildly
> more obfuscated.
>
> Sam
Leslie V. (Guest)
on 2006-05-22 14:50
(Received via mailing list)
On 5/22/06, Kris <removed_email_address@domain.invalid> wrote:
> It would take a higher skill set to extract it though.
> And you can write code that helps hide a key in a binary file.
>
> So is it possible to write a C extension that overrides the ruby require
> in the same way as the previous ruby example?

Sorry to be a whiner, but can't you put the key in a file only readable
by the person who should be able to read it? Ie. manage your key
security using your OS's security. Then you can also encrypt your
key file with a password the user has to enter if you like. This is how
SSH handles private keys.

Or are you trying to obfuscate a Ruby program?

It sounds like you are prepared to go to a lot of effort to create a
weak encryption system, which would be a shame.

Les
Kris L. (Guest)
on 2006-05-22 18:02
Well there are several aspects to this, I want to protect the code from
being read, from being modified and from internal attacks.

I could use the file system permissions but its always vunrable to at
least one person. This normally would not be a problem but we are
dealing with sensative data.

We can make the encrypt key in the interpreter hard to find, not
impossible, but much more secure than having open source code.


Leslie V. wrote:
> On 5/22/06, Kris <removed_email_address@domain.invalid> wrote:
>> It would take a higher skill set to extract it though.
>> And you can write code that helps hide a key in a binary file.
>>
>> So is it possible to write a C extension that overrides the ruby require
>> in the same way as the previous ruby example?
>
> Sorry to be a whiner, but can't you put the key in a file only readable
> by the person who should be able to read it? Ie. manage your key
> security using your OS's security. Then you can also encrypt your
> key file with a password the user has to enter if you like. This is how
> SSH handles private keys.
>
> Or are you trying to obfuscate a Ruby program?
>
> It sounds like you are prepared to go to a lot of effort to create a
> weak encryption system, which would be a shame.
>
> Les
Ryan L. (Guest)
on 2006-05-22 19:22
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> Well there are several aspects to this, I want to protect the code from
> being read, from being modified and from internal attacks.
>
> I could use the file system permissions but its always vunrable to at
> least one person. This normally would not be a problem but we are
> dealing with sensative data.
>
> We can make the encrypt key in the interpreter hard to find, not
> impossible, but much more secure than having open source code.

Try to do this. I bet I could break it in 10 minutes.

But against the average person it might work. But the average person
is not your problem...

Ryan
Kris L. (Guest)
on 2006-05-22 19:26
By reading the key from the binary or reading the un-encrypted code from
memory?

Ryan L. wrote:
> On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>> Well there are several aspects to this, I want to protect the code from
>> being read, from being modified and from internal attacks.
>>
>> I could use the file system permissions but its always vunrable to at
>> least one person. This normally would not be a problem but we are
>> dealing with sensative data.
>>
>> We can make the encrypt key in the interpreter hard to find, not
>> impossible, but much more secure than having open source code.
>
> Try to do this. I bet I could break it in 10 minutes.
>
> But against the average person it might work. But the average person
> is not your problem...
>
> Ryan
Kris L. (Guest)
on 2006-05-22 19:27
In any case how would you go about securing ruby code or do you think it
is not possible? Is no code secure?
Jeff R. (Guest)
on 2006-05-22 19:40
(Received via mailing list)
Kris L. wrote:
>>> dealing with sensative data.
>>>
>>> We can make the encrypt key in the interpreter hard to find, not
>>> impossible, but much more secure than having open source code.
>> Try to do this. I bet I could break it in 10 minutes.
>>
>> But against the average person it might work. But the average person
>> is not your problem...
>>
>> Ryan

Haha, you really don't want to go down this road.  If you can't
accomplish what you are trying to do with proven cryptographic security
primitives, then you should probably change the use case.  Security
through obscurity is really a waste of everyones time.  Even if you make
it quite difficult for people to figure out, it only takes one person to
do the work and then everyone can take advantage of the crack.

-Jeff
Kris L. (Guest)
on 2006-05-22 19:46
The use case can't be changed, it would need to be secure code... At the
moment I dont see any language that offers this, Java and .NET make
bytecode which is easily reversed. There are obsfucator's but I dont
think they provide much protection just a layer against casual file
browsing. PHP's obsfucator's are easily reversed with online services.

Do you not think a binary offers protection for code...? You can't
reverse to code anyway. It whole ruby code base was kept in the binary
and ran inline, like embedded ruby this might offer real protection...
It would need to be encrypted inside the binary.
Ryan L. (Guest)
on 2006-05-22 19:53
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> By reading the key from the binary or reading the un-encrypted code from
> memory?

Yep.

There is work being done to create a Ruby obfuscator by Ryan D. and
Eric H.:

http://blog.zenspider.com/archives/2006/03/obfusca...

It is part of the RubyToC project. That may be your best bet.

Ryan
Tim B. (Guest)
on 2006-05-22 19:56
(Received via mailing list)
> The use case can't be changed, it would need to be secure code...

Then the prerequisite would be secure hardware. It's not possible to
safely encrypt code purely in software.

You've not explained why you think that code hidden inside a compiled
binary is safe. It might be just a tad more difficult to extract than
from a script, but it doesn't make sense to distinguish between sorta
safe and a little bit more safe.

Maybe you need to describe the `use case ` in more detail.

   -tim
Kris L. (Guest)
on 2006-05-22 20:43
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...

The ruby obsufcator looks good but it may never work with Rails... it
doesn't at the moment. :(
Tim B. (Guest)
on 2006-05-22 22:15
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> Mainly I want to be able to sell ruby/rails applications without doing a
> hosted only solution (like basecamp), if I was 37signals I would want to
> sell the application as you would desktop software...

That doesn't really explain why you want to  encrypt code:

* if people copy your software illegally, they can do so whether the
source code is available or not.

* if the code you want to release is so incredibly ingenius that
people will want to illegally steal your IP to integrate into their
own software, you can a.) sue them b.) get a patent (US only) c.) a
little bit of obfuscating won't keep them out anyhow.

   -tim
Kris L. (Guest)
on 2006-05-22 22:21
Its an application that deals with highly sensitive data, I dont want
insiders to be able to write a bit of ruby and dump the data to
file/screen...

Tim B. wrote:
> On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>> Mainly I want to be able to sell ruby/rails applications without doing a
>> hosted only solution (like basecamp), if I was 37signals I would want to
>> sell the application as you would desktop software...
>
> That doesn't really explain why you want to  encrypt code:
>
> * if people copy your software illegally, they can do so whether the
> source code is available or not.
>
> * if the code you want to release is so incredibly ingenius that
> people will want to illegally steal your IP to integrate into their
> own software, you can a.) sue them b.) get a patent (US only) c.) a
> little bit of obfuscating won't keep them out anyhow.
>
>    -tim
Leslie V. (Guest)
on 2006-05-23 00:18
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> Its an application that deals with highly sensitive data, I dont want
> insiders to be able to write a bit of ruby and dump the data to
> file/screen...

You are talking about two different things: hiding code (algorithms)
and hiding data. Hiding code is useless because if it can be executed
by a computer it can be cracked by a person. The millions of patches
on the Internet prove that even little known programs are cracked as
soon
as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

You can hide data by encrypting it though, and then giving the key to
only those who may see the data. Even so, the key can be found by
fast computers but hopefully it is long enough that the search will
take too long to be feasable. This means that all encrypted data
has an expiry date, as faster computers come around.

So: must the sensitive data be given to only *some* of the insiders by
your
program? Or must only *some* of the data be revealed to the insiders?
If you are trying to give people encrypted data that is only readable
by your program, I think that's a lost cause.

Les
Eric H. (Guest)
on 2006-05-23 01:03
(Received via mailing list)
On May 22, 2006, at 9:44 AM, Kris L. wrote:

> Mainly I want to be able to sell ruby/rails applications without
> doing a
> hosted only solution (like basecamp), if I was 37signals I would
> want to
> sell the application as you would desktop software...
>
> The ruby obsufcator looks good but it may never work with Rails... it
> doesn't at the moment. :(

It might, but we've never tried it.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Kris L. (Guest)
on 2006-05-23 01:26
Yes two things I am concerned with, I have also looked at Java and .NET
and they also have the same problems.

> Hiding code is useless because if it can be executed
> by a computer it can be cracked by a person.

I would not say useless, if you offer open source then you are asking
for trouble. If you take measures to obsfucate/encrypt the code the
skill level to get/change it increases. There is no such thing as
absolute security but...




Leslie V. wrote:
> On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>> Its an application that deals with highly sensitive data, I dont want
>> insiders to be able to write a bit of ruby and dump the data to
>> file/screen...
>
> You are talking about two different things: hiding code (algorithms)
> and hiding data. Hiding code is useless because if it can be executed
> by a computer it can be cracked by a person. The millions of patches
> on the Internet prove that even little known programs are cracked as
> soon
> as they appear. If your data is hidden by your code being hard to
> understand, it will be visible very soon - binaries or not.
>
> You can hide data by encrypting it though, and then giving the key to
> only those who may see the data. Even so, the key can be found by
> fast computers but hopefully it is long enough that the search will
> take too long to be feasable. This means that all encrypted data
> has an expiry date, as faster computers come around.
>
> So: must the sensitive data be given to only *some* of the insiders by
> your
> program? Or must only *some* of the data be revealed to the insiders?
> If you are trying to give people encrypted data that is only readable
> by your program, I think that's a lost cause.
>
> Les
Ryan D. (Guest)
on 2006-05-23 03:08
(Received via mailing list)
On May 22, 2006, at 9:44 AM, Kris L. wrote:

> Mainly I want to be able to sell ruby/rails applications without
> doing a
> hosted only solution (like basecamp), if I was 37signals I would
> want to
> sell the application as you would desktop software...
>
> The ruby obsufcator looks good but it may never work with Rails... it
> doesn't at the moment. :(

Which obfuscator are you referring to? We've never even tried
obfuscating rails apps with ours, and neither have you. :P

--
_why: zenspider's most intense moments of solice are immediately
following the slaughter [...]
_why: that topknot's the only thing keeping a lid on the righteous anger
bricolage: yeah, that and his flagrant obsession with dvorak
Ryan D. (Guest)
on 2006-05-23 03:29
(Received via mailing list)
On May 22, 2006, at 1:17 PM, Leslie V. wrote:

> as they appear. If your data is hidden by your code being hard to
> understand, it will be visible very soon - binaries or not.

How true is that? Bypassing a license key check is a LOT different
than reverse engineering a full binary (and being able to make sense
of it). I'm no black hat so I'm honestly asking here. I have no clue. :P
Juergen S. (Guest)
on 2006-05-23 06:52
(Received via mailing list)
On Tue, May 23, 2006 at 06:26:42AM +0900, Kris L. wrote:
> Yes two things I am concerned with, I have also looked at Java and .NET
> and they also have the same problems.

Because this is a general problem, not depending on language.

> > Hiding code is useless because if it can be executed
> > by a computer it can be cracked by a person.

True. You could store it in "safe" hardware, a smartcard for example.

> I would not say useless, if you offer open source then you are asking
> for trouble. If you take measures to obsfucate/encrypt the code the
> skill level to get/change it increases. There is no such thing as
> absolute security but...

Enryption is hard. You will implement a useless scheme privatly. Doing
this any other way than open source, under peer review, will lead to a
trivially breakable system. Sorry if this seems harsh.

> > So: must the sensitive data be given to only *some* of the insiders by
> > your
> > program? Or must only *some* of the data be revealed to the insiders?
> > If you are trying to give people encrypted data that is only readable
> > by your program, I think that's a lost cause.

Very true. Except you stuff that data *and* the processing program
into "safe" hardware, and only communicate unclassified results from
that to your rails app.

Lastly, if that data is really "highly sensitive", it is also highly
valuable, and obfuscation won't keep the bad boys away. If it ain't
valueable, don't bother with obfuscation, because your time is of
value too.

J├╝rgen
Hal F. (Guest)
on 2006-05-23 09:16
(Received via mailing list)
Kris L. wrote:
> Well there are several aspects to this, I want to protect the code from
> being read, from being modified and from internal attacks.
>
> I could use the file system permissions but its always vunrable to at
> least one person. This normally would not be a problem but we are
> dealing with sensative data.
>
> We can make the encrypt key in the interpreter hard to find, not
> impossible, but much more secure than having open source code.

Google for the phrase "security through obscurity" (STO).

Are you in the US? What is your native language?


Hal
Alex Y. (Guest)
on 2006-05-23 11:38
(Received via mailing list)
Hal F. wrote:
>
> Google for the phrase "security through obscurity" (STO).
There's a useful difference between full security and a picket fence.
Sure, a picket fence is easy to get over, but you know you're
trespassing (and legally have shown intent) when you do.
Kris L. (Guest)
on 2006-05-23 11:47
>Google for the phrase "security through obscurity" (STO).

I know what this is. But I'm getting no helpful suggestions on this.
There seems to be a load of resistance to doing anything secure or
commerical in ruby. And yes its a general problem with all interpreted
languages except Coldfusion which I think allows you to encrypt source.
PHP goes part way with obsfucation.

The general feeling I get is it can't be done... Does anyone have any
suggestions how to secure ruby (or other) code.
Hal F. (Guest)
on 2006-05-23 12:00
(Received via mailing list)
Kris L. wrote:
> suggestions how to secure ruby (or other) code.
>

Oh, anything can be done... but is it worth it, and have you really
accomplished anything?

That's the source of the resistance you perceive. Most of us don't
want or need what you describe.

I venture to say there are numerous people here who might put in
some hours and achieve what you want. But the people who really
understand cryptography (and I am not one) will not spend their
time on an STO scheme.

As for coding... Most people are motivated only two ways to write code:
   1. They're paid
   2. The project seems cool to them

You're not paying (are you?) and people aren't convinced this is cool.

Actually I remember *someone* making an obfuscator of some kind 3-4
years ago... I played with it awhile and couldn't break it. Others
could, though. Or I could given a few hours.

The best suggestion yet was to keep the code off the client machine
and make a web service. That is relatively secure.


Hal
Leslie V. (Guest)
on 2006-05-23 12:03
(Received via mailing list)
On 5/23/06, Ryan D. <removed_email_address@domain.invalid> wrote:
> > by a computer it can be cracked by a person. The millions of patches
> > on the Internet prove that even little known programs are cracked
> > as soon
> > as they appear. If your data is hidden by your code being hard to
> > understand, it will be visible very soon - binaries or not.
>
> How true is that? Bypassing a license key check is a LOT different
> than reverse engineering a full binary (and being able to make sense
> of it). I'm no black hat so I'm honestly asking here. I have no clue. :P

What I'm saying is that bypassing a license key check in a binary and
bypassing a license key check in source are both very easy. Source is
obviously easier but a binary is usually also trivially easy - just
get a debugger and set some break-points, search for some strings,
some API calls... it rarely takes more than 30 minutes.

In the face of a bit of investigation entire file formats and
protocols are open for all to see - just look at the drop-in
replacements for Exchange, the many programs that can read and write
MS Word documents, the NTFS support on Linux. Protocols have been
decoded and servers hacked without having the source OR the binaries
but just by looking at the comms. With a binary, things are very easy.

Seriously: your program is visible, your strength needs to lie somewhere
else.

Les
Tim B. (Guest)
on 2006-05-23 12:28
(Received via mailing list)
> I know what this is. But I'm getting no helpful suggestions on this.

You're getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.

If you want to keep casual eyes away from your code, the very first
answer to your question:

>On 5/19/06, Eric H. <removed_email_address@domain.invalid> wrote:
> Override require.

was spot on. Implementing any sort of obfuscation in your own
`require` will keep 99% of the audience out of your code.

If, on the other hand, you want to securely keep the other 1% who are
determined in one way or the other to get at your code out, you can't
do it in software.

Keeping your sensitive *data* encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you're using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the `openssl` ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.

> The general feeling I get is it can't be done... Does anyone have any
> suggestions how to secure ruby (or other) code.

Nobody is denying that it can be done to some extent. You can keep out
casual attackers by implementing some trivial protection (rot13,
obfuscation, loading your code from a zip file ...) or even keep out
professionals with some resources to invest by executing in tamper
proof hardware. But you seem to want something `in between`, and are
convinced the only way to do it is to compile your encryption key in
C.
   -tim
Kris (Guest)
on 2006-05-23 14:34
Hal F. wrote:
> Kris L. wrote:
>> suggestions how to secure ruby (or other) code.
>>
>
> Oh, anything can be done... but is it worth it, and have you really
> accomplished anything?

It would be a layer of protection that would at least prevent casual
attacks.

>
> That's the source of the resistance you perceive. Most of us don't
> want or need what you describe.

Because you dont want it you resist its development..

>
> I venture to say there are numerous people here who might put in
> some hours and achieve what you want. But the people who really
> understand cryptography (and I am not one) will not spend their
> time on an STO scheme.
>
> As for coding... Most people are motivated only two ways to write code:
>    1. They're paid
>    2. The project seems cool to them
>
> You're not paying (are you?) and people aren't convinced this is cool.

I'm not asking anyone else to do it.

>
> Actually I remember *someone* making an obfuscator of some kind 3-4
> years ago... I played with it awhile and couldn't break it. Others
> could, though. Or I could given a few hours.
>
> The best suggestion yet was to keep the code off the client machine
> and make a web service. That is relatively secure.

But that makes huge limits on profit. My feeling is web software can't
be sold like desktop software is. Either boxed or a pre-installed
server.

>
>
> Hal
Kris (Guest)
on 2006-05-23 14:37
Leslie V. wrote:
> On 5/23/06, Ryan D. <removed_email_address@domain.invalid> wrote:
>> > by a computer it can be cracked by a person. The millions of patches
>> > on the Internet prove that even little known programs are cracked
>> > as soon
>> > as they appear. If your data is hidden by your code being hard to
>> > understand, it will be visible very soon - binaries or not.
>>
>> How true is that? Bypassing a license key check is a LOT different
>> than reverse engineering a full binary (and being able to make sense
>> of it). I'm no black hat so I'm honestly asking here. I have no clue. :P
>
> What I'm saying is that bypassing a license key check in a binary and
> bypassing a license key check in source are both very easy. Source is
> obviously easier but a binary is usually also trivially easy - just
> get a debugger and set some break-points, search for some strings,
> some API calls... it rarely takes more than 30 minutes.

Only for programmers. A key can be found, but it can't be reversed to
source.

>
> In the face of a bit of investigation entire file formats and
> protocols are open for all to see - just look at the drop-in
> replacements for Exchange, the many programs that can read and write
> MS Word documents, the NTFS support on Linux. Protocols have been
> decoded and servers hacked without having the source OR the binaries
> but just by looking at the comms. With a binary, things are very easy.
>
> Seriously: your program is visible, your strength needs to lie somewhere
> else.



>
> Les
Kris (Guest)
on 2006-05-23 14:40
Tim B. wrote:
>> I know what this is. But I'm getting no helpful suggestions on this.
>
> You're getting plenty of helpful suggestions: it makes no sense to go
> to great lengths to encrypt code and expect it to be secure.

But it is more secure than open source.

>
> If you want to keep casual eyes away from your code, the very first
> answer to your question:
>
>>On 5/19/06, Eric H. <removed_email_address@domain.invalid> wrote:
>> Override require.
>
> was spot on. Implementing any sort of obfuscation in your own
> `require` will keep 99% of the audience out of your code.

Agreed. It is something I am looking at.

>
> If, on the other hand, you want to securely keep the other 1% who are
> determined in one way or the other to get at your code out, you can't
> do it in software.
>
> Keeping your sensitive *data* encrypted on the other hand can be done
> in software and with proper encryption, there is no need to obscure
> the encryption routine, only the keys you're using (granted, you need
> to find a secure way of destributing encryption passwords to users).
> You could use the `openssl` ruby library to do the encryption, for
> example. Openssl, by the way, is open source, yet quiete a few banks
> trust it to protect their homebanking sites.

How do those banks prevent the keys being found by their own staff or
server admins?

>
>> The general feeling I get is it can't be done... Does anyone have any
>> suggestions how to secure ruby (or other) code.
>
> Nobody is denying that it can be done to some extent. You can keep out
> casual attackers by implementing some trivial protection (rot13,
> obfuscation, loading your code from a zip file ...) or even keep out
> professionals with some resources to invest by executing in tamper
> proof hardware. But you seem to want something `in between`, and are
> convinced the only way to do it is to compile your encryption key in
> C.
>    -tim
Alex Y. (Guest)
on 2006-05-23 15:44
(Received via mailing list)
Kris wrote:
> Tim B. wrote:
>
>>>I know what this is. But I'm getting no helpful suggestions on this.
>>
>>You're getting plenty of helpful suggestions: it makes no sense to go
>>to great lengths to encrypt code and expect it to be secure.
>
>
> But it is more secure than open source.
Careful with your terminology.  It's more obscure than unencrypted
source.  It's *not* more secure than open source.
Tim B. (Guest)
on 2006-05-23 16:09
(Received via mailing list)
> How do those banks prevent the keys being found by their own staff or
> server admins?

That's a different problem, typically solved by using secure hardware.
The point is, only the key needs to be secret, not the implementation.

   -tim
Bira (Guest)
on 2006-05-23 16:52
(Received via mailing list)
On 5/23/06, Kris <removed_email_address@domain.invalid> wrote:
> > Keeping your sensitive *data* encrypted on the other hand can be done
> > in software and with proper encryption, there is no need to obscure
> > the encryption routine, only the keys you're using (granted, you need
> > to find a secure way of destributing encryption passwords to users).
> > You could use the `openssl` ruby library to do the encryption, for
> > example. Openssl, by the way, is open source, yet quiete a few banks
> > trust it to protect their homebanking sites.
>
> How do those banks prevent the keys being found by their own staff or
> server admins?

I'm no expert, but I know encryption keys aren't present in the source
code of the program. Wheter a given encryption program is secure or
not doesn't have anything to do with wheter it is open source or not.
A lot of encryption protocols involve keys generated on the spot from
other information, for example.
Guest (Guest)
on 2006-05-23 17:01
Tim B. wrote:
>> How do those banks prevent the keys being found by their own staff or
>> server admins?
>
> That's a different problem, typically solved by using secure hardware.
> The point is, only the key needs to be secret, not the implementation.
>
>    -tim

Agreed, but how do you hide the key from people with access to the
server?
Guest (Guest)
on 2006-05-23 17:04
Bira wrote:
> On 5/23/06, Kris <removed_email_address@domain.invalid> wrote:
>> > Keeping your sensitive *data* encrypted on the other hand can be done
>> > in software and with proper encryption, there is no need to obscure
>> > the encryption routine, only the keys you're using (granted, you need
>> > to find a secure way of destributing encryption passwords to users).
>> > You could use the `openssl` ruby library to do the encryption, for
>> > example. Openssl, by the way, is open source, yet quiete a few banks
>> > trust it to protect their homebanking sites.
>>
>> How do those banks prevent the keys being found by their own staff or
>> server admins?
>
> I'm no expert, but I know encryption keys aren't present in the source
> code of the program. Wheter a given encryption program is secure or
> not doesn't have anything to do with wheter it is open source or not.
> A lot of encryption protocols involve keys generated on the spot from
> other information, for example.

An open source project compiled (open at design time) and software that
has interpreted open source (open at run time) are different. And
interpreted is less secure than compiled. Not much more secure in
skilled hands, but even so. Its easier to write anti-tamper with
compiled. Or better still as suggested using hardware.
Leslie V. (Guest)
on 2006-05-23 17:25
(Received via mailing list)
On 5/23/06, Guest <removed_email_address@domain.invalid> wrote:
> server?
You should read up on how SSL works:
http://www.ourshop.com/resources/ssl.html

The keys are not embedded in the program but are secured using the
operating system. Private keys (certificates) are "signed" (encrypted)
by a third party known to be reliable by both bank and client. Each
private key is just a file on a harddrive, protected by the operating
system. Someone who had physical access to that harddrive can get the
key (if they can bypass the operating system) but we assume the bank
keeps it physically secure.

This is pretty similar to my SSH example at the beginning - keys are
held in files apart from the source code, secured by the OS. With SSH
you can also have a "key to a key" where the key file is itself
encrypted and the user has to type a password to decrypt it before it
can be used.

Les
Bira (Guest)
on 2006-05-23 18:03
(Received via mailing list)
On 5/23/06, Guest <removed_email_address@domain.invalid> wrote:

> An open source project compiled (open at design time) and software that
> has interpreted open source (open at run time) are different. And
> interpreted is less secure than compiled.

How so? I don't think I've ever read anything about this before. Sure,
it's easier to change interpreted code, but if the attacker already
has enough access to make those alterations in the first place, it
doesn't matter wheter the program is compiled or interpreted, and you
have a deeper problem in your hands.
Alex Y. (Guest)
on 2006-05-23 18:32
(Received via mailing list)
Bira wrote:
> doesn't matter wheter the program is compiled or interpreted, and you
> have a deeper problem in your hands.

It depends on what metric you use for "secure".  If you use "minimum
amount of energy expended to retrieve protected data", then in an
otherwise like-for-like system, then assuming that the software is not
bypassed completely, the system with compiled code needs additional
energy for the decompilation, making it "more secure".  Simple as that
:-)
Eric H. (Guest)
on 2006-05-23 22:48
(Received via mailing list)
On May 23, 2006, at 3:34 AM, Kris wrote:
> Hal F. wrote:
>> Kris L. wrote:
>>> suggestions how to secure ruby (or other) code.
>>
>> That's the source of the resistance you perceive. Most of us don't
>> want or need what you describe.
>
> Because you dont want it you resist its development..

We resist the development of something that is known not to work.

zenobfuscator is what you really want, and it exists.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Austin Z. (Guest)
on 2006-05-23 23:14
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> In any case how would you go about securing ruby code or do you think it
> is not possible? Is no code secure?

No code is secure against determined attackers. Please remember that
when you post from Ruby Forum, you're actually posting to a mailing
list read by thousands of people. It would be useful if you kept
context (as I have done) to keep your posts meaningful.

-austin
Austin Z. (Guest)
on 2006-05-23 23:14
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> Yes two things I am concerned with, I have also looked at Java and .NET
> and they also have the same problems.
>
> > Hiding code is useless because if it can be executed
> > by a computer it can be cracked by a person.
>
> I would not say useless, if you offer open source then you are asking
> for trouble. If you take measures to obsfucate/encrypt the code the
> skill level to get/change it increases. There is no such thing as
> absolute security but...

No, hiding code is useless.

-austin
Austin Z. (Guest)
on 2006-05-23 23:23
(Received via mailing list)
On 5/23/06, Kris <removed_email_address@domain.invalid> wrote:
> It would be a layer of protection that would at least prevent casual
> attacks.

Casual attacks aren't your worry. Trust me on this. If you treat your
users like you trust them, you will usually be rewarded. If you don't,
you'll get exactly what you deserve because users don't like being
treated prima facie like probable criminals. This isn't 100% accurate,
but it's close enough.

> > That's the source of the resistance you perceive. Most of us don't
> > want or need what you describe.
> Because you dont want it you resist its development..

No. We don't resist, we don't need. There's a difference. You're
welcome to develop this sort of thing yourself. Just understand that
merely hiding code isn't going to help you at all.

> > Actually I remember *someone* making an obfuscator of some kind 3-4
> > years ago... I played with it awhile and couldn't break it. Others
> > could, though. Or I could given a few hours.
> >
> > The best suggestion yet was to keep the code off the client machine
> > and make a web service. That is relatively secure.
> But that makes huge limits on profit. My feeling is web software can't
> be sold like desktop software is. Either boxed or a pre-installed
> server.

No, web software can't be sold like desktop software. It can be sold
as a subscription service (which is what my company does). We also
sell our software to companies who want to implement their own version
of it, and we are usually required to place our souce code in escrow
in the event that we go under.

Think a little differently and you'll find different ways to profit.
Commercial software sales has bad margins anyway at this point.

-austin
Austin Z. (Guest)
on 2006-05-23 23:23
(Received via mailing list)
On 5/23/06, Guest <removed_email_address@domain.invalid> wrote:
> An open source project compiled (open at design time) and software that
> has interpreted open source (open at run time) are different. And
> interpreted is less secure than compiled. Not much more secure in
> skilled hands, but even so. Its easier to write anti-tamper with
> compiled. Or better still as suggested using hardware.

You're confusing your terms. Compiled software is harder to
reverse-engineer than interpreted software. Neither is impossible.

Compiled and interpreted, closed and open have nothing to do with
security; it may have something to do with source availability, but
not security. Don't pretend otherwise, please.

-austin
Hal F. (Guest)
on 2006-05-24 04:00
(Received via mailing list)
Kris wrote:
> Hal F. wrote:
>
>
> Because you dont want it you resist its development..
>

Are you crazy? What am I resisting?

Go ahead and code the damned thing if you want it.

>
> I'm not asking anyone else to do it.
>

Then what do you want?? Do you want us to tell you it's
a wonderful idea?


Hal
Hal F. (Guest)
on 2006-05-24 04:06
(Received via mailing list)
Alex Y. wrote:
>> How so? I don't think I've ever read anything about this before. Sure,
> energy for the decompilation, making it "more secure".  Simple as that :-)
>

Exactly. ;)  Just as a closed book is more secure than one lying open
on a table. If it's closed, you have to be smart enough to open it
before you can read it.


Hal
This topic is locked and can not be replied to.