Encrypting executable or embedding in C

Discussion in 'Perl Misc' started by Tom, Dec 29, 2003.

  1. Tom

    Tom Guest

    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
     
    Tom, Dec 29, 2003
    #1
    1. Advertising

  2. Tom

    pkent Guest

    In article <>, "Tom" <> wrote:

    > 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

    --
    pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
    Remove the tea to reply
     
    pkent, Dec 29, 2003
    #2
    1. Advertising

  3. On Mon, 29 Dec 2003 13:37:57 -0800
    "Tom" <> wrote:

    > 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"
     
    James Willmore, Dec 29, 2003
    #3
  4. Tom

    Tom Guest

    "Tom" <> wrote in message news:...
    > 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
    >
     
    Tom, Dec 30, 2003
    #4
  5. On Mon, 29 Dec 2003 16:09:58 -0800
    "Tom" <> wrote:

    >
    > "Tom" <> wrote in message
    > news:...
    > > 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.
    > >

    >
    > 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, Dec 30, 2003
    #5
  6. On Mon, 29 Dec 2003 16:09:58 -0800
    "Tom" <> wrote:

    >
    > "Tom" <> wrote in message
    > news:...
    > > 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.
    > >

    >
    > 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, Dec 30, 2003
    #6
  7. On Tue, 30 Dec 2003 05:13:01 GMT
    James Willmore <> wrote:

    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"
     
    James Willmore, Dec 30, 2003
    #7
  8. Tom

    Tom Guest

    >
    > 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
     
    Tom, Dec 30, 2003
    #8
  9. Tom

    pkent Guest

    In article <3ff0cdf9$>, "Tom" <> wrote:

    > 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

    --
    pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
    Remove the tea to reply
     
    pkent, Dec 31, 2003
    #9
  10. Tom

    Tom Guest

    ..
    >
    > 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
     
    Tom, Dec 31, 2003
    #10
  11. Tom

    pkent Guest

    In article <3ff338c5$>, "Tom" <> wrote:

    > 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.

    --
    pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
    Remove the tea to reply
     
    pkent, Jan 1, 2004
    #11
  12. Tom

    Tom Guest

    > 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, Jan 2, 2004
    #12
  13. Tom

    Tom Guest

    > 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
     
    Tom, Jan 2, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nico
    Replies:
    1
    Views:
    319
    Dennis Reinhardt
    Jul 1, 2004
  2. Replies:
    15
    Views:
    498
    Dave Thompson
    Aug 21, 2006
  3. pratap
    Replies:
    20
    Views:
    774
    Flash Gordon
    Mar 7, 2007
  4. Jason Cavett
    Replies:
    8
    Views:
    635
    Sanjay
    May 16, 2007
  5. Replies:
    0
    Views:
    452
Loading...

Share This Page