Seeking suggestions on encryption algorithm
Thai-Nghia Dinh
I have script/batch files that I am giving to a client for his use. I want
the scripts/batch files to be executable but not readable. So I am thinking
of encrypting it and decrypting it before execution.
The problem is this: by decrypting it, I have to store it in a temp file.
Anybody familiar with a computer would be able to find that temp file and
read it (especially on UNIX systems).
Is there a way to decrypt it into MEMORY and execute it from there (or
something like that)? Or can I somehow encrypt the scripts while keeping
them executable? I am aware that 4dos' batchcom (or something to that effect)
is able to encrypt batch files but I don't know how it procedes to decrypt
and execute it (or is it executable in the encrypted form).
I don't care whether I can execute the file directly or have to call another
program to decrypt and then execute it.
I.e "my_file" or "decrypt_and_execute my_file" would both be acceptable.
Any SPECIFIC informations/pointers would be greatly appreciated.
P.S I'm am working on UNIX platform right now but might port it onto DOS
eventually so info on both platforms are welcome.
Thanx for your help!
--
Ciao!!
jax!
?
''~``
( o o )
+-------------------------------.oooO--(_)--Oooo.---------------------------+
My mail is so slow, the Elvis stamp gained ten pounds.
.oooO
( ) Oooo.
+----------------------------------\ (----( )-----------------------------+
\_) ) / lmc...@lmc.ericsson.se
DISCLAIMER:The views expressed herein are (_/ j...@info.polymtl.ca
totally personnal and are not necessarily shared
by my employer, nor any other organization or individual!
MICHAEL ALEXANDER BORDYNUIK
essentially do the same thing and could easily be decrypted/encryped. I
believe their is a shareware program somewhere out there which automatically
converts a batch to an .EXE .
Mike
Thai-Nghia Dinh (lmc...@lmc.ericsson.se) wrote:
: Hello,
Wendell Gee
(lmc...@lmc.ericsson.se) typed:
RB>I have script/batch files that I am giving to a client for his use. I want
RB>the scripts/batch files to be executable but not readable. So I am thinking
RB>of encrypting it and decrypting it before execution.
RB>I don't care whether I can execute the file directly or have to call
RB>another program to decrypt and then execute it.
RB>I.e "my_file" or "decrypt_and_execute my_file" would both be acceptable.
RB>P.S I'm am working on UNIX platform right now but might port it onto DOS
RB> eventually so info on both platforms are welcome.
On Unix [at least in the US] crypt() should be standard. If you don't have
access to crypt(), there should be something out there which can read from
a file or stdin and send output to stdout [like all good Unix filters should
do...]. You can encrypt your files with crypt() and send them out, then
write a program which will decrypt the file (using crypt()) and pipe the
output to the shell you're using to run the script(s) [the most obvious way
I can think of is to write a C program which contains a line like:
system ("crypt passwd < batchfile | sh");
If you compile this to an executable it will be harder (by no means
impossible) to find the passwd being used to encrypt your files. Since a
pipe is used, no temporary files are created.
To bring this to DOS you're pretty much on your own. I used to use DOS,
but even the Unix-looking features (pipes, for instance) are implemented in
a very sloppy fashion and are impossible for me to stomach. (sorry)
Hope this helps in some non-self-destructive fashion.
--r
--------------------------------------------------------------------------
| "The density of the information | Rick Bradley |
| presented is near the theoretical | Starving Graduate Student |
| minimum." --FreeBSD manual: comsat(8) | CS Dept. -- SUNY Stony Brook |
--------------------------------------------------------------------------
K.Yu. Boyandin
>T> I have script/batch files that I am giving to a client for his use. I want
>T> the scripts/batch files to be executable but not readable. So I am
>thinking
>T> of encrypting it and decrypting it before execution.
>T> The problem is this: by decrypting it, I have to store it in a temp file.
>Store them on RAMDISK in DOS, and in pipe in UNIX environment.
>But: if client gets a program using them he can use the program
> (or code extracted from it) to decrypt them. Poor protection.
One can decrypt the script on command-by-command basis (as powerful
copy-protection systems like Cerberus do). Notice: it's extremely difficult
to supply reliable encryption/decryption scheme for such algorithm (unless
you mean to write another Cerberus), so probably there's better approach...
Best wishes,
Konstantin.
Konstantin Boyandin, aka Master Bo (383-2)-39-73-69 (room 301 mb NSU)
m...@ccphys.nsu.nsk.su use Finger to learn my schedule
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6
mQBNAi/DOxQAAAECAK610xLl+QjojutsuMU/yuhtGqrHzuXTskoSUaFSfgmgjXM7
qek9TP7Xf5IIUw6ldvXnRDs1NjDgVSrPXkbq03kABRG0IU1hc3RlciBCbyA8bWJv
QGNjcGh5cy5uc3UubnNrLnN1Pg==
=5MsJ
-----END PGP PUBLIC KEY BLOCK-----
Adam Back
bra...@cs.sunysb.edu (Wendell Gee) writes:
> an infinite number of monkeys calling themselves Thai-Nghia Dinh
> (lmc...@lmc.ericsson.se) typed:
> RB>I want the scripts/batch files to be executable but not readable. So
> RB>I am thinking of encrypting it and decrypting it before execution.
> RB>I don't care whether I can execute the file directly or have to call
> RB>another program to decrypt and then execute it.
> RB>I.e "my_file" or "decrypt_and_execute my_file" would both be acceptable.
> RB>P.S I'm am working on UNIX platform right now but might port it onto DOS
> RB> eventually so info on both platforms are welcome.
This perl code works for MSDOS, and unix, and includes the encryption
algorithm in the script, all you need to do is ship the perl
interpreter, which is available for a wide range of platforms. Most
unix systems have it as standard.
The file encrypt/decrypt version (it's RC4 as used by Netscape SSL
layer, various Microsoft apps, currently believed secure with
appropriate length keys -- say 128 bit):
#!/usr/local/bin/perl -- -export-a-crypto-system-sig -RC4-in-3-lines-of-PERL
@k=unpack('C*',pack('H*',shift));sub S{@s[$x,$y]=@s[$y,$x];}for(@t=@s=0..255)
{$y=($k[$i++]+$s[$_]+$y)%256;$x=$_;&S;$i%=@k;}$/=$x=$y=0;for(unpack('C*',<>))
{$x++;$y=($s[$x%=256]+$y)%256;&S;print pack(C,$_^=$s[($s[$x]+$s[$y])%256]);}
You just do:
% rc4 key < plain.txt > cipher.txt
to encrypt, and the reverse to decrypt:
% rc4 key < cipher.txt > plain.txt
The key is given in hex, and can be of any length (40 bits = 10 hex
digits, to 128 bits = 32 hex digits, or bigger 2048 bits is the limit,
but 128 bits should be plenty of security.)
A version which creates self decrypting executeables:
--rc4x----8<----------
#!/usr/local/bin/perl -s
!@ARGV&&die"$0 f\n";
$s='print STDERR "key:";`stty -echo`;$k=<STDIN>;`stty echo`;
@k=unpack("C*",$k);sub S{@s[$x,$y]=@s[$y,$x];}for(@t=@s=0..255){$y=($k[$i++
]+$s[$_]+$y)%256;$x=$_;&S;$i%=@k;}$/=$x=$y=0;for(unpack("C*",<DATA>)){$x++;
$y=($s[$x%=256]+$y)%256;&S;$c.=pack(C,$_^=$s[($s[$x]+$s[$y])%256]);}$/="\n";';
print "#!/usr/local/bin/perl\n$s\neval \$c;\n__END__\n";$s=~s/DATA//;eval $s;
print $c;
----------8<----------
So you get a sample script, that you want to encrypt:
--hello---8<----------
#!/usr/local/bin/perl
print "hello world\n";
----------8<----------
To create a self decrypting executable version of the hello script you
run:
% rc4x hello > hellox
It will prompt you for a key to encrypt hellox with, just type some
hex digits (recommend 10 to 32 hex digits depending on your security
requirements.) I typed "1234" so that is the key for the below
program.
Now you could post the script to USENET for instance, or deliver it to
your client with the key given later in exchange for payment.
hellox looks like this:
% cat hellox
#!/usr/local/bin/perl
print STDERR "key:";`stty -echo`;$k=<STDIN>;`stty echo`;
@k=unpack("C*",$k);sub S{@s[$x,$y]=@s[$y,$x];}for(@t=@s=0..255){$y=($k[$i++
]+$s[$_]+$y)%256;$x=$_;&S;$i%=@k;}$/=$x=$y=0;for(unpack("C*",<DATA>)){$x++;
$y=($s[$x%=256]+$y)%256;&S;$c.=pack(C,$_^=$s[($s[$x]+$s[$y])%256]);}$/="\n";
eval $c;
__END__
Rn邐襹菴[灑蛃sY挦m<C7琌搌幸脈I0亾y@挈坚婕
ie a self decryptor, followed by gibberish encrypted data.
When you run hellox, it prompts you for the key to allow it to run,
and then does whatever it used to do:
% hellox
key:
hello world
%
(The key is not echoed as you enter it).
However your original question was posed in such a way that indicates
that you were looking for an obfuscation method rather than a key
enabled software mechanism.
You could use the above for such a thing if you wished, but it is
fairly easy to decrypt if you know the key. Just alter the code to
print the program rather than run it:
----------8<----------
#!/usr/local/bin/perl
print STDERR "key:";`stty -echo`;$k=<STDIN>;`stty echo`;
@k=unpack("C*",$k);sub S{@s[$x,$y]=@s[$y,$x];}for(@t=@s=0..255){$y=($k[$i++
]+$s[$_]+$y)%256;$x=$_;&S;$i%=@k;}$/=$x=$y=0;for(unpack("C*",<DATA>)){$x++;
$y=($s[$x%=256]+$y)%256;&S;$c.=pack(C,$_^=$s[($s[$x]+$s[$y])%256]);}$/="\n";
print $c;
__END__
Rn邐襹菴[灑蛃sY挦m<C7琌搌幸脈I0亾y@挈坚婕
----------8<----------
or it is easy to write a general decryptor.
Basically you can only ever obfuscate, and never ultimately prevent
the person from seeing the script code. Even compiling, people can,
and have decompiled programs manually.
That part is a loosing battle, without hardware support.
Use the GPL and embrace availibility of source code, that's what I say!
Adam
--
#!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL
$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa
2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print
pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2)
Bill Vermillion
Thai-Nghia Dinh <lmc...@lmc.ericsson.se> wrote:
>Hello,
>I have script/batch files that I am giving to a client for his use. I want
>the scripts/batch files to be executable but not readable. So I am thinking
>of encrypting it and decrypting it before execution.
Well scripts are Unix and batch files are DOS - but
If DOS batch files there are PD programs that will convert
batch files to .exe or .com files.
In Unix there is at least one commercial program that I am
aware of that will convert shell scripts tt a compiled program.
(Or it may convert to C which you can compile).
If the code is on a clients machine there is really nothing you
can do to completely hide what you have done funtionally from
someone who wants to know what is going on.
You have not indicated why you don't want to take that
approach.
--
Bill Vermillion - bi...@bilver.oau.org | bill.ve...@oau.org
Matthew Johnson
>I would recommend making up a program instead of a batch file. It would
>essentially do the same thing and could easily be decrypted/encryped. I
>believe their is a shareware program somewhere out there which automatically
>converts a batch to an .EXE .
> Mike
To which I (mejo...@netcom.com) add:
I agree with Mr Bordynuik that you should use an program instead of a batch
file, but since anyone using adb or od would still be able ro read the password
I further suggest you _not_ use crypt directly, as suggested in a previous
post. True, crypt uses a pretty strong algorithm, which would be quite
difficult to match in your own home-made encryption, but all this benefit
would be poured down the drain if the password sits in the clear in the
program. If instead the program generates the password on the fly, as well
as the name "crypt" before doing the system call, you have a much more
useful level of security. Now only a programmer sophisticated enough to
run your program under adb, putting a breakpoint at the system call and
dumping out the string could break your security.
If this is not a high enough level of security, you could write your
own encryption/decryption program (but deliver only the decryption pgm
and that in binary). The algorithm will not be as strong as crypt, but
it will be harder to reverse engineer it with adb. You could do a
Vigenere cipher using a transcendental number such as e or gamma (pi is
too obvious) as the key, you could use matrix multiplication permuting
elements of the matrix according to some simple enumeration of the
permutations of n^2 symbols (nxn matrix). Neither of these algorithms
can be counted on to hide the cleartext from a professional cryptanalyst,
but they do make decompiling the decryption program rather unhelpful.
Which choise is best for you really depends on just whom you are hiding
the program from and how much effort he might be willing to spend on
defeating your cryptography.
You may also want to pick up the cryptology FAQ from rtfm.mit.edu before
you commit yourself to one choice or the other.
Matthew Johnson
Sabaki Engineering
mejo...@netcom.com
>Thai-Nghia Dinh (lmc...@lmc.ericsson.se) wrote:
>: Hello,
>: I have script/batch files that I am giving to a client for his use. I want
>: the scripts/batch files to be executable but not readable. So I am thinking
>: of encrypting it and decrypting it before execution.
>: The problem is this: by decrypting it, I have to store it in a temp file.
>: Anybody familiar with a computer would be able to find that temp file and
>: read it (especially on UNIX systems).
>: Is there a way to decrypt it into MEMORY and execute it from there (or
>: something like that)? Or can I somehow encrypt the scripts while keeping
>: them executable? I am aware that 4dos' batchcom (or something to that effect)
>: is able to encrypt batch files but I don't know how it procedes to decrypt
>: and execute it (or is it executable in the encrypted form).
>: I don't care whether I can execute the file directly or have to call another
>: program to decrypt and then execute it.
John Wigley
: According to my records, lmc...@lmc.ericsson.se (Thai-Nghia Dinh)
: said something to the effect of
: (>I have script/batch files that I am giving to a client for his use. I want
: (>the scripts/batch files to be executable but not readable. So I am thinking
: (>of encrypting it and decrypting it before execution.
: Grab a copy of Protect! EXE/COM (PROTEXCM.EXE) - it's a shareware
: program that does an excellent job of encrypting your program and
: keeping it executable. Contains a CRC check as well. Hard to trace
: the decrypt code too... grab a copy:
I wouldn't use it to secure COMMAND.COM let alone anything I really
wanted to keep secure. I don't know what the latest version is, but the last
one I looked at was V5.0. It was supposed to have a mutation engine that
was impossible to write a generic decryptor for, It took me 20 minutes to
write a generic decryptor that stripped the protection off of every COM
file that I tried it with.
John Wigley
Arnoud Galactus Engelfriet
In article <47pbkc$k...@news.worldlinx.com>,
mbab...@feldspar.com (Michael Babcock) wrote:
> According to my records, lmc...@lmc.ericsson.se (Thai-Nghia Dinh)
> said something to the effect of
>
> (>I have script/batch files that I am giving to a client for his use. I want
> (>the scripts/batch files to be executable but not readable. So I am thinking
> (>of encrypting it and decrypting it before execution.
>
> Grab a copy of Protect! EXE/COM (PROTEXCM.EXE) - it's a shareware
> program that does an excellent job of encrypting your program and
> keeping it executable. Contains a CRC check as well. Hard to trace
> the decrypt code too... grab a copy!
So, in other words, once some clever guy finds out the decryption scheme,
the product becomes worthless?
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: gala...@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger gala...@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy page: <http://www.stack.urc.tue.nl/~galactus/remailers/>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAgUBMKEF1DyeOyxBaho1AQG+0QQAh0nh9qev5vsQ8A9RqSMFKdA+uSBlPWZN
OAeG2Rq1Xz2BtoyQ7emCWsviyQWOmLb6ZQ49hHKJfoBt38SEreQgGRE4EW4nJ7Rv
6wfayuFdPWNKgGuRgisqLkmZwViVPeSncRxmrvezRqZKpOuv3EMu5eDPFoVk+qBc
nYsmHUp9A8M=
=Fz0E
-----END PGP SIGNATURE-----
face411
values of an input string to scramble the ascii values of any file. the only
way to decode it was to use the same program and the same input string. this
could always be incorporated into the text file somewhere (encrypted of
course). and found by the encryption program. this would allow random string
generation for the encryption key. (the only reason i used strings is because
you can create more complex scrambles quicker- you dont have to type in 10
numbers between 0 and 255)
face411
Paul Schlyter
face411 <rmw...@vms.cis.pitt.edu> wrote:
> i wrote a fairly decent encryptoin progam in basic once. it used the ascii
> values of an input string to scramble the ascii values of any file. the
> only way to decode it was to use the same program and the same input string.
> this could always be incorporated into the text file somewhere (encrypted
> of course). and found by the encryption program. this would allow random
> string generation for the encryption key. (the only reason i used strings
> is because you can create more complex scrambles quicker- you dont have to
> type in 10 numbers between 0 and 255)
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Nybrogatan 75 A, S-114 40 Stockholm, SWEDEN
e-mail: pau...@saaf.se p...@home.ausys.se