shell脚本加密经验分享

为啥要加密shell脚本
以我个人的需求为例，我要做一个自动远程登录的脚本，每次手动输密码太慢，而且输的多了密码也容易泄露；直接把密码写在脚本里，快确实是快，但是安全性让人无法忍受，写脚本的时候都有可能被过路的不小心看到密码，这就太蛋疼了。

最终解法
就是，把密码写在脚本里，作为参数传给下一个脚本让其用来登录，而保存密码的脚本，使用某种手段加密，令其不可读但是可执行。

加密方法介绍和实战
经过一番搜索，shell脚本加密常用的有三种方法，gzexe,shc,upx，下面我们一一尝试。
首先我这里准备了两个脚本，一个是test.sh,主要用来计时的，它会调用另一个脚本----l.sh,这个l.sh就是我们要加密的脚本了。

l.sh内容如下

#!/bin/bash
echo test
1
2
第一种，gzexe
特点是不用安装，加解密极其简单，我个人的操作环境是macOS,直接就可以用，命令简单粗暴
加密

gzexe l.sh
1
来操作一下

正常执行没问题，速度也很快,原始代码确实看不到了

解密

gzexe -d l.sh
1
操作试试

轻松恢复原样了…

结论:gzexe其实就是个压缩工具，能起到隐藏文件内容的效果，执行速度几乎和脚本一样(在脚本不太大的情况下),但是如果加密文件本身被偷走，那就凉凉，轻松可以破解，当然高手也可以二段加密，比如手动修改加密后的文件什么的，但是这就是一个道高一尺魔高一丈的事了。

第二种,shc
安装方法略过，大家可以自行百度，这里直接实战。
shc加密以后，原文件不会变，会生成一个原文件名.x的加密后的文件，我这里就是l.sh.x了
加密命令

shc -T -f l.sh
1
-f后跟要加密的文件名，-T这个参数必须要加，如果不加的话，就是这种结果

加密前正常，加密后凉了
正常加密示范

正常执行没问题，看看加密后的文件内容

变成一堆数字了

但是shc有个问题，对于我来说是很严重的，就是加密后的脚本执行非常慢，似乎有一个两秒左右的解压缩时间，具体慢到什么程度，我们执行test.sh看一下
test.sh

#!/bin/bash
# 加密前
start=$(date "+%s")
for i in {1..100}
{
./l.sh
}
end=$(date "+%s")
echo 加密前执行用时:$[$end-$start]"秒"
# 加密后
start=$(date "+%s")
./l.sh.x
end=$(date "+%s")
echo 加密后执行用时:$[$end-$start]"秒"
1
2
3
4
5
6
7
8
9
10
11
12
13
14

原始脚本执行100遍，用时不到1秒，shc加密后执行一次用时3秒，这tm慢如狗哇，如果每次执行脚本都是这个速度,完全不能忍!

总结:shc安全性稍好，至少解密起来不太容易，但是加密后执行速度太慢，无法忍受。

第三种,upx
upx是一个加壳工具，主要用来给可执行文件加密用的，但是网上也有文章说可以给shell脚本加密，所以我们就来试试。
upx安装不废话了，大家可以自行百度，这里直接操练。
upx加密命令

# 最快压缩
upx -1 l.sh
# 最强压缩
upx -9 l.sh
1
2
3
4
执行结果

出师不利，upx不能压缩太小文件，而脚本众所周知一般都不大，upx对shell脚本价值减少90%。

我后来又给脚本加了一堆注释，强行增大了脚本，upx加密是能加密了，但是执行不了有毛用啊！怀疑是脚本不算可执行文件，用gzexe把脚本搞成了可执行文件，又压缩了一遍，这回确定了，upx加密后的脚本就是没法执行，upx对shell脚本价值减小为0。
有不信邪的朋友可以自己试试，我在macOS上尝试的结果是这样的，或许其他平台会有不一样的表现呢。

总结
对我来说，仅仅是保护远程密码的话，直接使用gzexe即可，避免无意间泄露，执行速度快，如果能保证软件安全(牛逼的杀毒软件)和硬件安全(电脑别被偷了)的话，安全性还是可以接受的。大家可以自行斟酌，如果脚本本身执行时间就很长，那么shc执行慢的特点或许也是可以忽略不计的。
————————————————
版权声明：本文为CSDN博主「群星坠」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_35603331/article/details/83793475