shell脚本加密经验分享

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_35603331/article/details/83793475

为啥要加密shell脚本

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

最终解法

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

加密方法介绍和实战

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

l.sh内容如下

#!/bin/bash
echo test

第一种,gzexe

特点是不用安装,加解密极其简单,我个人的操作环境是macOS,直接就可以用,命令简单粗暴
加密

gzexe l.sh

来操作一下
在这里插入图片描述
正常执行没问题,速度也很快,原始代码确实看不到了

解密

gzexe -d l.sh

操作试试
在这里插入图片描述
轻松恢复原样了…

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

第二种,shc

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

shc -T -f l.sh

-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]"秒"

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

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

第三种,upx

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

# 最快压缩
upx -1 l.sh
# 最强压缩
upx -9 l.sh

执行结果
在这里插入图片描述

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

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

总结

对我来说,仅仅是保护远程密码的话,直接使用gzexe即可,避免无意间泄露,执行速度快,如果能保证软件安全(牛逼的杀毒软件)和硬件安全(电脑别被偷了)的话,安全性还是可以接受的。大家可以自行斟酌,如果脚本本身执行时间就很长,那么shc执行慢的特点或许也是可以忽略不计的。

展开阅读全文

没有更多推荐了,返回首页