Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!rex!ames!vsi1!altos!megadon!clp
From: dupey@hudson.cs.columbia.edu (Alexander Dupuy)
Newsgroups: comp.unix
Subject: Re: Shell Encoder
Message-ID: <2132@megadon.UUCP>
Date: 10 Oct 90 02:41:32 GMT
References: <40237@mcdchg.chg.mcd.mot.com>
Sender: clp@megadon.UUCP
Reply-To: dupuy@cs.columbia.edu
Lines: 32
Approved: clp@megadon.UUCP
In-Reply-To: tim@comcon.UU.NET's message of 29 Jun 90 18:51:25 GMT

In article <40237@mcdchg.chg.mcd.mot.com> in comp.newprod Tim Brown writes:

   Shell Encoder (TM) from Computer Connection

   Computer Connection would like to announce a new product called Shell
   Encoder.  Don't have to give away your bourne, korn, csh, perl, bash
   or any other shell program ideas any more!

   Computer Connection's Shell Encoder is designed to allow
   programers the ability to furnish their shell programs to the
   end-user in an encrypted format.  This allows programmers to
   supply their high-quality products without the dangers of
   allowing their trade secrets to be seen, therefore protecting
   their intellectual properties.

   Shell Encoder is composed of two modules, CODE and RUN.  CODE is
   used to encode and decode the shell programs with a password,
   while RUN is used to execute the encoded shells.  Because the
   shell program is actually executed by the shell of your choice,
   it runs just like it was never encoded at all.

   [prices, etc, deleted]

Besides being a rather annoying sort of idea (the great thing about shell
scripts is that you can see what they do, and change them easily, and if it's
so complex, you should probably be writing a C program anyhow) I don't see how
this would work.  Simply replace the interpreter in question with a simple
program that tees its input to a file and to the original interpreter (this is
a bit harder to do with /bin/sh, but can be finessed with the appropriate
invocation of chroot).

@alex