大神入 请叫shell 脚本加密的问题

teaklee

通过 shc 可以将shell脚本转为二进制执行,以保护源碼.
但是如果这个shell脚本是 以 source xx.sh 方式被其他脚本调用 . 如下两个脚本
a.sh
tt=TEST


b.sh
source ./a.sh
echo $tt

a.sh加密后 , b.sh执行就出错了.
请问这种情况如何处理.我希望保护 a.sh 中的内容.

bikkuri

a.sh加密后 , b.sh执行就出错了.
这个其实好理解。
假如a.sh经过shc加密后生成的文件是c.sh，那么b.sh实际上调用的是c.sh，而c.sh要有一个解密的过程还原出原来的a.sh，然后开启一个shell去执行a.sh。
虽然你的b.sh用的是source来调用c.sh，也就是说b.sh和c.sh是在同一个shell里面。
但是c.sh和a.sh并不是在同一个shell里面，所以shc加密事实上造成了b.sh和a.sh处于不同在shell里面，尽管b.sh里用了source命令。
那么当a.sh执行结束后，c.sh开启的那个shell中的环境变量也会随着shell的消亡而丢失。
所以b.sh是没办法得到a.sh传递的环境变量的。
可以通过临时文件传递变量。
a.sh
echo "TEST" > /tmp/tt


b.sh
source ./a.sh
tt=$(cat /tmp/tt)
echo $tt
但是临时文件如果是明文的话，又和你用shc加密a.sh的初衷相矛盾。
所以要不在a.sh中对临时文件也进行加密，然后在b.sh中对临时文件进行解密，
要不就不用shc来加密a.sh而是自己写一段加密程序来加密a.sh，在这段加密程序中用source来调用解密后的a.sh，以确保解密后的a.sh和b.sh也在同一个shell里。
当然除了用source还有很多其他办法，比如eval "$(cat a.sh)"。
后者应该比前者更安全一些。
但是shell脚本归根结底要解密成文本来执行，注定了其安全性不会太高，蒙一蒙门外汉还行，想糊弄稍微懂一点shell脚本的人都不能够。