[ANN] RubyScript2Exe 0.3.0

RubyScript2Exe 0.3.0 is out!

* Added compression: Some applications are less then half the
  size.

* Fixed the broken call to ResHacker.

* Fixed a bug concerning --eee-list in combination with rubyw:
  Programs with a * DOS box and programs without a DOS box are
  two totally different things, for Windows. You can't do a
  "writeln" to the console if there is no console. You would
  expected Windows to handle these things, but it simply
  dies...

gegroet,
Erik V.

http://www.erikveen.dds.nl/rubyscript2exe/index.html

Hi Erik,

Erik Veenstra wrote:

RubyScript2Exe 0.3.0 is out!

* Added compression: Some applications are less then half the
  size.

Absoultely smashing !

* Fixed the broken call to ResHacker.

Great !

* Fixed a bug concerning --eee-list in combination with rubyw:
  Programs with a * DOS box and programs without a DOS box are
  two totally different things, for Windows. You can't do a
  "writeln" to the console if there is no console. You would
  expected Windows to handle these things, but it simply
  dies...

Thanks a lot for fixing this ...

Add now a feature request: you know how we can "hack on location".
That is just terrific in the pre-release mode when I am
at my client site and do not have to carry around my sources for
minor fixes. But now that we are thinking of commercializing the
product, we do * NOT * want anybody to hack on location. Is it
possible to create a "release" version which cannot be hacked?

gegroet,

"Goodbye" :slight_smile:

Erik V.

http://www.erikveen.dds.nl/rubyscript2exe/index.html

-- shanko

"Cannot be hacked" is impossible: Everything can be hacked.
That's what hacking means...

I could optionally block --eee-list and --eee-justextract, but
the code of both EEE and RubyScript2Exe is on the 'Net, so
smart people can "decompile" it anyway.

And if they are not that smart: The running application is
temporarily unpacked to /tmp (or %TEMP%), so you can just copy
that directory before the application terminates.

gegroet,
Erik V.

···

On Mon, 27 Dec 2004 11:12:38 -0600, Shashank Date wrote:

Add now a feature request: you know how we can "hack on
location". That is just terrific in the pre-release mode when
I am at my client site and do not have to carry around my
sources for minor fixes. But now that we are thinking of
commercializing the product, we do * NOT * want anybody to
hack on location. Is it possible to create a "release"
version which cannot be hacked?

Hello Shashank,

Hi Erik,

Erik Veenstra wrote:

RubyScript2Exe 0.3.0 is out!

* Added compression: Some applications are less then half the
  size.

Absoultely smashing !

* Fixed the broken call to ResHacker.

Great !

* Fixed a bug concerning --eee-list in combination with rubyw:
  Programs with a * DOS box and programs without a DOS box are
  two totally different things, for Windows. You can't do a
  "writeln" to the console if there is no console. You would
  expected Windows to handle these things, but it simply
  dies...

Thanks a lot for fixing this ...

Add now a feature request: you know how we can "hack on location".
That is just terrific in the pre-release mode when I am
at my client site and do not have to carry around my sources for
minor fixes. But now that we are thinking of commercializing the
product, we do * NOT * want anybody to hack on location. Is it
possible to create a "release" version which cannot be hacked?

If you do a groups.google search in this newsgroup with my name and
"hacking" you should find an old topic (~6/9 month) where i presented
a 10 lines ruby.exe hack that i wrote in a few minutes that killed all
discussed ways to encrpyt and protect a ruby program.

At the moment it is simply not possible (in an easy way and with the
current ruby license).

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Hi Lothar,

Lothar Scholz wrote:

If you do a groups.google search in this newsgroup with my name and
"hacking" you should find an old topic (~6/9 month) where i presented
a 10 lines ruby.exe hack that i wrote in a few minutes that killed all
discussed ways to encrpyt and protect a ruby program.

Yes, I remember reading it a while back and was aware of the situation
from the very outset. However, I was not discouraged by it either since
we had not planned on commercializing it.

Admitedly, my requests to Eric appear naive but that is my (wierd) way
of showing my admiration to his work.

At the moment it is simply not possible (in an easy way and with the
current ruby license).

What has the license to do with it ?

-- shanko

Hi Lothar,

Lothar Scholz wrote:

If you do a groups.google search in this newsgroup with my name and
"hacking" you should find an old topic (~6/9 month) where i presented
a 10 lines ruby.exe hack that i wrote in a few minutes that killed all
discussed ways to encrpyt and protect a ruby program.

Yes, I remember reading it a while back and was aware of the situation
from the very outset. However, I was not discouraged by it either since
we had not planned on commercializing it.

Admitedly, my requests to Eric appear naive but that is my (wierd) way of showing my admiration to his work.

At the moment it is simply not possible (in an easy way and with the
current ruby license).

What has the license to do with it ?

-- shanko

Hello Shashank,

At the moment it is simply not possible (in an easy way and with the
current ruby license).

What has the license to do with it ?

I'm not very good in reading license texts so i might be wrong here.

It is possible to do a really good encrpytion (locking out 99,9% of all hackers)
of your program if you could modify the ruby.exe file without being forced to
publish your changes. But the current license does not allow this.

I don't want to discuss the way how to do the protection in a public
newsgroup.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Lothar Scholz <mailinglists@scriptolutions.com> writes:

Hello Shashank,

At the moment it is simply not possible (in an easy way and with the
current ruby license).

> What has the license to do with it ?

I'm not very good in reading license texts so i might be wrong here.

It is possible to do a really good encrpytion (locking out 99,9% of all hackers)
of your program if you could modify the ruby.exe file without being forced to
publish your changes. But the current license does not allow this.

IANAL, but I can't see why (citing LICENSE.txt):

  2. You may modify your copy of the software in any way, provided that
     you do at least ONE of the following:
     ...
       c) rename any non-standard executables so the names do not conflict
    with standard executables, which must also be provided.

  3. You may distribute the software in object code or executable
     form, provided that you do at least ONE of the following:
     ...
       c) give non-standard executables non-standard names, with
          instructions on where to get the original software distribution.

So, calling your "secure" Ruby `secruby' and including an ordinary
ruby too, this should not be an issue, AFAICT.

  4. You may modify and include the part of the software into any other
     software (possibly commercial). But some files in the distribution
     are not written by the author, so that they are not under this terms.

This can be worked around by not modifiying the addressed files or
opening the changes to them (the Regexp engine is not a security risk,
for example). You could possibly have to include their source, which
is not a problem in practice.

I don't want to discuss the way how to do the protection in a public
newsgroup.

The only proper way to make Ruby code currently runnable but not
readable is IMO dumping the eval tree and reloading it at startup.
This is technically possible, but I wont help any efforts to do this.

Christian Neukirchen
<chneukirchen@gmail.com>

Christian Neukirchen wrote:

The only proper way to make Ruby code currently runnable but not
readable is IMO dumping the eval tree and reloading it at startup.
This is technically possible, but I wont help any efforts to do this.

However it is usually easy to go back to source code from the eval tree.