Encrypting executable or embedding in C

[Tom]

Hi

Can someone point me to information regarding either encrypting a perl file
so it can still execute (if this is possible), or embedding a 10,000+ line
script completely into a C/C++ program.

It also needs to encapsulate all included libraries, etc.

Thanks,
Tom

 

[pkent]

Can someone point me to information regarding either encrypting a perl file
so it can still execute (if this is possible),

You'll need to provide a little more information, especially: should the
perl program decrypt itself, or should the operator type in the
decryption key, for example?

If the former is the case, then you are offering very little protection
because the encrypted data carries along its own decryption key and
decryption code in the clear (it must be in the clear or else the system
couldn't execute it...) - it'll stop some people idly looking at the
source but nothing more.

If the latter then there are many ways of encrypting things, and I think
that you could easily write a self decrypting thing, like a 'shell
archive' that I've seen sometimes. The easiest thing might be to have a
simple perl script that asked for the decryption key, and then took its
__DATA__ section, decrypted that and ran it, somehow...

or embedding a 10,000+ line
script completely into a C/C++ program.

try 'perldoc perlembed' for that

It also needs to encapsulate all included libraries, etc.

This might be hard if there are .so or .dll objects involved, especially
if this program needs to run on different machines or architectures, but
if it's all pure perl then I think that you can just concatenate the
whole lot together _in the right order_ and load it as one stream of
text. OTOH you could simply encrypt a zip file or tar.gz of all the
files required and decrypt them onto the filesystem, but that has its
own vulnerabilities. [ Also, you probably don't need to encrypt all the
modules do you? ]

Note that there are other ways to investigate your program which do not
necessarily require a human to read and print out your source code, for
example using debuggers, a 'special' version of perl, tools such as
strace or truss, etc... if you can provide more info about your
requirements we might be able to focus on better suggestions.


I'm assuming that you are running this on a fairly normal computer - I
would guess that some specialist platforms have support for encrypted
binary image execution, etc, but they're probably military, and the
kinds of people who use those systems probably wouldn't be asking for
advice here

P

 

[James Willmore]

Can someone point me to information regarding either encrypting a
perl file so it can still execute (if this is possible), or
embedding a 10,000+ line script completely into a C/C++ program.

It also needs to encapsulate all included libraries, etc.

[Sigh]

This has been asked and answered in different ways before. Use Google
to get a feel for what answers are available.

However, to get you started, try the following resources (at the
command line):
perldoc perlembed
perldoc -q 'compile'

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
If little green men land in your back yard, hide any little green
women you've got in the house. -- Mike Harding, "The Armchair
Anarchist's Almanac"

 

[Tom]

Hi

Can someone point me to information regarding either encrypting a perl file
so it can still execute (if this is possible), or embedding a 10,000+ line
script completely into a C/C++ program.

It also needs to encapsulate all included libraries, etc.

Thanks,
Tom

The goal is for the program to still be executable, while protecting the
source.
The program is running on Linux, but I may need it ported to some other
flavor than Redhat.
I want to be able to run it remotely on a server, while keeping it safe from
being stolen and viewed or modified.

Thanks,
Tom

 

[James Willmore]

The goal is for the program to still be executable, while protecting
the source.
The program is running on Linux, but I may need it ported to some
other flavor than Redhat.
I want to be able to run it remotely on a server, while keeping it
safe from being stolen and viewed or modified.

Please, please, please ..... do a Goggle search for this topic (try
the keywords "comp.lang.perl.misc protect source code" to start).
There are *many* threads on this *exact* topic.

The *very* short answer is it can't be done. The long answer is in
the *many* threads on this topic.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
It's raisins that make Post Raisin Bran so raisiny ...

 

[James Willmore]

The goal is for the program to still be executable, while protecting
the source.
The program is running on Linux, but I may need it ported to some
other flavor than Redhat.
I want to be able to run it remotely on a server, while keeping it
safe from being stolen and viewed or modified.

Please, please, please ..... do a Goggle search for this topic (try
the keywords "comp.lang.perl.misc protect source code" to start).
There are *many* threads on this *exact* topic.

The *very* short answer is it can't be done. The long answer is in
the *many* threads on this topic.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
It's raisins that make Post Raisin Bran so raisiny ...

 

[James Willmore]

On Tue, 30 Dec 2003 05:13:01 GMT

My ISP, newsreader, and me had a disagreement - so, this one got
posted twice :-(

Sorry :-(

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Whether you can hear it or not The Universe is laughing behind
your back -- National Lampoon, "Deteriorata"

 

[Tom]

The *very* short answer is it can't be done. The long answer is in
the *many* threads on this topic.

I just wanted the short answer, thanks.
Tom

 

[pkent]

The goal is for the program to still be executable, while protecting the
source.
The program is running on Linux, but I may need it ported to some other
flavor than Redhat.
I want to be able to run it remotely on a server, while keeping it safe from
being stolen and viewed or modified.

That's 3 different aims there:

1) Run it remotely and cannot view source code - do you mean like a CGI,
an RPC thing or a SOAP thing (to name a few examples) ? In all those
cases the 'remote execution' interface does not expose the source code,
the object code, or anything, but it allows people to run the code
remotely.

2) Can't be modified - set the appropriate file permissions.

3) Can't be stolen - well if people can't view or modify the code they
will have a hard time stealing it electronically... but then they can
just steal the server on which the code resides, or its backups, can't
they? And that approach works for _any_ language, not just Perl.

Maybe a good appropach would be to run your "sensitive" code on a secure
server, present a SOAP/RPC/CGI/whatever interface to it and distribute
the stub code to let people interact with your server. Or maybe it
wouldn't, I don't know.

If you care about your code being stolen you need to think "Security"
all over the place. Here's an example: what's the point of 'encrypting'
source code if programmer(s) print off program listings to work on and
throw them in the rubbish bin, which gets emptied into black sacks that
sit out on the pavement waiting for the bin men to collect them? Or what
if your development server has a publically-routable IP address and runs
a vulnerable copy of ssh/apache/whatever which allows a root exploit?

P

 

[Tom]

..

That's 3 different aims there:

1) Run it remotely and cannot view source code - do you mean like a CGI,
an RPC thing or a SOAP thing (to name a few examples) ? In all those
cases the 'remote execution' interface does not expose the source code,
the object code, or anything, but it allows people to run the code
remotely.

2) Can't be modified - set the appropriate file permissions.

3) Can't be stolen - well if people can't view or modify the code they
will have a hard time stealing it electronically... but then they can
just steal the server on which the code resides, or its backups, can't
they? And that approach works for _any_ language, not just Perl.

Maybe a good appropach would be to run your "sensitive" code on a secure
server, present a SOAP/RPC/CGI/whatever interface to it and distribute
the stub code to let people interact with your server. Or maybe it
wouldn't, I don't know.

If you care about your code being stolen you need to think "Security"
all over the place. Here's an example: what's the point of 'encrypting'
source code if programmer(s) print off program listings to work on and
throw them in the rubbish bin, which gets emptied into black sacks that
sit out on the pavement waiting for the bin men to collect them? Or what
if your development server has a publically-routable IP address and runs
a vulnerable copy of ssh/apache/whatever which allows a root exploit?

O.K., to further clarify, I just want to be able to install a binary on a
server somewhere that "I" have remote access to, as opposed to running from
my home.
This would allow me to start, run and stop my script from anywhere in the
world.
At the same time, I don't want prying eyes/curiosities accessing my source.
They could take the binary, but they wouldn't know what to do with it and
couldn't modify it.

I don't even need interactive access, just the ability to make sure it's
always running and worst case, upload and compile a bug fix.

By the way, I shred everything, though I don't print source anyway.
I also have 5 levels of security where all of this stuff exists (sparing
details for obvious reasons).
Thanks,
Tom

 

[pkent]

O.K., to further clarify, I just want to be able to install a binary on a
server somewhere that "I" have remote access to, as opposed to running from
my home.
This would allow me to start, run and stop my script from anywhere in the
world.

Fair enough, you've obviously sussed that no matter how secure your
'application server' is, there is still a possibility of Bad People
compromising it somehow and you want to minimize any possible losses. It
would be interesting to know what kind of application you'll be
running[1] though.

If this is important, though, how does your program know that it's _you_
telling it to start? E.g. is your concept vulnerable to a replay attack
of some kind, or might there be, for the sake of argument, a kind of
challenge-response public-key authentication step?

OTOH that might not be an important issue, in which case, carry on as
you were...

P

[1] Obviously without any details that might be sensitive. E.g. "I need
to start the payroll run for a company" is nice and bland - supplying
the employee names would be Bad.

 

[Tom]

Well in case you havn't come across it yet, you can use the

"Generic Script Compiler".
http://www.datsi.fi.upm.es/~frosal

What it does is take the script, encrypts it with RC4, and puts
into a c executable. You still need all the perl libs installed,
because what the script does when run, is just decrypt the script,
and execs it.

It stops the "prying eyes" of the average person, but it is not secure.
It has been discussed before in this newsgroup, how to get the
perl source out, and also methods to protect youself from this.

Thanks!
Tom

 

[Tom]

Fair enough, you've obviously sussed that no matter how secure your

'application server' is, there is still a possibility of Bad People
compromising it somehow and you want to minimize any possible losses. It
would be interesting to know what kind of application you'll be
running[1] though.

If this is important, though, how does your program know that it's _you_
telling it to start? E.g. is your concept vulnerable to a replay attack
of some kind, or might there be, for the sake of argument, a kind of
challenge-response public-key authentication step?

OTOH that might not be an important issue, in which case, carry on as
you were...

P

[1] Obviously without any details that might be sensitive. E.g. "I need
to start the payroll run for a company" is nice and bland - supplying
the employee names would be Bad.

I'm not susceptable to liability if someone else runs it.
It datamines, databases and produces output.
Can't be anymore specific.
In any event, the problem will be in the required libraries.
I might eeventually convert it to C++.

Thanks,
Tom