Make a password protected bash script resist/refuse “bash -x” when the password is given

Shell Programming and Scripting
1

I want to give my long scripts to customer. The customer must not be able to read the scripts even if he has the password. The following command locks and unlocks the script but the set +x is simply ignored.

The code:

read -p 'Script: ' S && C=$S.crypt H='eval "$((dd if=$0 bs=1 skip=//|gpg -d)2>/dev/null)"; exit;' && gpg -c<$S|cat >$C <(echo $H|sed s://:$(echo "$H"|wc -c):) - <(chmod +x $C)

I want to give to customer a script that he can run by entering a password. The customer must not be able to see the code via cat/vim/bash -x. To counter the "bash -x" we can use set +x in the beginning of the script but it does not work for the password protected script. we run bash -x script.secure, put the password and we see the commands even if the script starts with set +x

2

There is a utility shc (shc.c) that turns a script into a compiled executable, with any text encrypted.

http://www.datsi.fi.upm.es/~frosal/ - download the tar ball.

IMO - what you are doing does not seem secure.

3

yes I know about shc. I hear that rc4 can be "broken".

4

It's worse than that -- the program runs the code through sh ultimately, so substituting a false sh can get the code directly.

Many people have been down this road before. Rube goldberg machines are not and cannot be the solution.

In short, if you don't want the customer to see the code, you can try either
1) Don't give it to them -- make it a service they access over the network

or

2) Put it on a machine you control, where they do not have root, and deny them access via file access permissions and isolate it further with sudo.

You cannot expect to protect a program by encryption when, by definition, the program contains the necessary code to decrypt itself in unencrypted form.

You cannot expect to protect anything run in plaintext from root.

If you rewrote your application in a language like C, decoding it would be a lot harder since quite a lot of information is thrown away in the compiling/linking process.

5

How safe is shc? Can redundant code make the shc.x safer? ref:http://tipstrickshack.blogspot.ch/2013/08/how-to-get-plain-text-source-from-shc.html

6

The question is not "how much safer can I make it". The question is, "how many more hoops can I put in the way of the unobscured code".

That is always the problem with rube goldberg solutions. The code will always still be there, and has to contain all the necessary steps for decrypting itself in plain, or it won't work.

Your real options remain as I gave them.

1 Like
7

I have to use wget, gnuplot etc. If I use c++ and call the external program, can I hide the syntax?

I have experience with the following bash embedding technique:

#define test1 "\
#!/bin/sh --posix \n\
echo \"2222222222222222222222222222222222222222222222222222\"  \n\
"


int main()
{

system(test1);     
return 0;

}

When we cut the executable we can see the bash code

8

You cannot because, no matter how you hide it, when you run it, it will feed the complete unencrypted text into the shell. It has to, or else system() couldn't run it!

That is always the problem with rube goldberg solutions. The code will always still be there, and has to contain all the necessary steps for decrypting itself in plain, or it won't work.

Adding more hoops will not help, since they can ignore everything but the last "hoop" -- the shell.

We have been down this road many, many, many times before. There is no magic solution to keeping running code protected on a system you do not trust. Your real options remain as I gave them.

1 Like