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.
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris (Guest)
on 2006-05-19 15: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.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-19 19: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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris (Guest)
on 2006-05-19 19: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 Hodel 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-19 21: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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-19 22:12
(Received via mailing list)
On May 19, 2006, at 2:59 PM, Eric Hodel wrote:

>>>> line by
> Eric Hodel - drbrain@segment7.net - 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris (Guest)
on 2006-05-21 17: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 Capaldo wrote:
> On May 19, 2006, at 2:59 PM, Eric Hodel wrote:
>
>>>>> line by
>> Eric Hodel - drbrain@segment7.net - 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
0ca6e5c33d7e7ff901d75ff0b13d9e1c?d=identicon&s=25 Sam Roberts (Guest)
on 2006-05-21 18:41
(Received via mailing list)
Quoting krisleech@interkonect.com, 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris (Guest)
on 2006-05-22 10: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 Roberts wrote:
> Quoting krisleech@interkonect.com, 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
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-22 12:50
(Received via mailing list)
On 5/22/06, Kris <krisleech@interkonect.com> 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 16: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 Viljoen wrote:
> On 5/22/06, Kris <krisleech@interkonect.com> 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
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-22 17:22
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 17:26
By reading the key from the binary or reading the un-encrypted code from
memory?

Ryan Leavengood wrote:
> On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 17:27
In any case how would you go about securing ruby code or do you think it
is not possible? Is no code secure?
567898c496278341be69087507d5ed24?d=identicon&s=25 Jeff Rose (Guest)
on 2006-05-22 17:40
(Received via mailing list)
Kris Leech 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 17: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.
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-22 17:53
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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 Davis and
Eric Hodel:

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

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

Ryan
62002cee15efcf4628cd7efc19425a07?d=identicon&s=25 Tim Becker (Guest)
on 2006-05-22 17: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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 18: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. :(
62002cee15efcf4628cd7efc19425a07?d=identicon&s=25 Tim Becker (Guest)
on 2006-05-22 20:15
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (krisleech)
on 2006-05-22 20: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 Becker wrote:
> On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-22 22:18
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-22 23:03
(Received via mailing list)
On May 22, 2006, at 9:44 AM, Kris Leech 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (Guest)
on 2006-05-22 23: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 Viljoen wrote:
> On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2006-05-23 01:08
(Received via mailing list)
On May 22, 2006, at 9:44 AM, Kris Leech 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
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2006-05-23 01:29
(Received via mailing list)
On May 22, 2006, at 1:17 PM, Leslie Viljoen 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
C914fa463a2b1b067586c6432b12a824?d=identicon&s=25 Juergen Strobel (Guest)
on 2006-05-23 04:52
(Received via mailing list)
On Tue, May 23, 2006 at 06:26:42AM +0900, Kris Leech 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
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-23 07:16
(Received via mailing list)
Kris Leech 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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-23 09:38
(Received via mailing list)
Hal Fulton 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.
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Kris Leech (Guest)
on 2006-05-23 09: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.
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-23 10:00
(Received via mailing list)
Kris Leech 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
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-23 10:03
(Received via mailing list)
On 5/23/06, Ryan Davis <ryand-ruby@zenspider.com> 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
62002cee15efcf4628cd7efc19425a07?d=identicon&s=25 Tim Becker (Guest)
on 2006-05-23 10: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 Hodel <drbrain@segment7.net> 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
167a3b5582230623eb94e638133122ec?d=identicon&s=25 Kris (Guest)
on 2006-05-23 12:34
Hal Fulton wrote:
> Kris Leech 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
167a3b5582230623eb94e638133122ec?d=identicon&s=25 Kris (Guest)
on 2006-05-23 12:37
Leslie Viljoen wrote:
> On 5/23/06, Ryan Davis <ryand-ruby@zenspider.com> 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
167a3b5582230623eb94e638133122ec?d=identicon&s=25 Kris (Guest)
on 2006-05-23 12:40
Tim Becker 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 Hodel <drbrain@segment7.net> 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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-23 13:44
(Received via mailing list)
Kris wrote:
> Tim Becker 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.
62002cee15efcf4628cd7efc19425a07?d=identicon&s=25 Tim Becker (Guest)
on 2006-05-23 14: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
439c401f95ee2fac0be4c1727dd74dea?d=identicon&s=25 Bira (Guest)
on 2006-05-23 14:52
(Received via mailing list)
On 5/23/06, Kris <kris@alternativefocusmedia.com> 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.
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Guest (Guest)
on 2006-05-23 15:01
Tim Becker 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?
3d333b0012928f3dd5a6861cb09ad683?d=identicon&s=25 Guest (Guest)
on 2006-05-23 15:04
Bira wrote:
> On 5/23/06, Kris <kris@alternativefocusmedia.com> 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.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-23 15:25
(Received via mailing list)
On 5/23/06, Guest <krisleech@interkonect.com> 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
439c401f95ee2fac0be4c1727dd74dea?d=identicon&s=25 Bira (Guest)
on 2006-05-23 16:03
(Received via mailing list)
On 5/23/06, Guest <krisleech@interkonect.com> 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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-23 16: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
:-)
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-23 20:48
(Received via mailing list)
On May 23, 2006, at 3:34 AM, Kris wrote:
> Hal Fulton wrote:
>> Kris Leech 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 21:14
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 21:14
(Received via mailing list)
On 5/22/06, Kris Leech <krisleech@interkonect.com> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 21:23
(Received via mailing list)
On 5/23/06, Kris <kris@alternativefocusmedia.com> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 21:23
(Received via mailing list)
On 5/23/06, Guest <krisleech@interkonect.com> 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
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-24 02:00
(Received via mailing list)
Kris wrote:
> Hal Fulton 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
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-24 02:06
(Received via mailing list)
Alex Young 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.