这种方案是通过对代码进行加密,然后利用C语音写解密的PHP扩展。破解难度会有提升,但依然是会被破解的。
从网上找过各种代码加密的开源方案。
一旦开源,就不可能保证安全性。毕竟加密和解密的东西都是公开的。
目前我们没有能力自己去写扩展。还是需要采用开源的方案。
我找到的比较好用的是php-beast。
https://github.com/liexusong/php-beast
实战开始
1.下载源码
wget https://github.com/liexusong/php-beast/archive/master.zip
2.解压
unzip master.zip
3.进入源码目录
cd php-beast-master
4.修改自定义文件头header.c
char encrypt_file_header_sign[] = {
0xe8, 0x16, 0xa4, 0x0c,
0xf2, 0xb2, 0x60, 0xee
};
|
5.修改默认的加密key
这里选用的是AES加密。因此修改aes_algo_handler.c文件,可以随机生成字符串替换。建议不要使用我测试时随便写的key。部署人员记得修改该key并保存。
static uint8_t key[] = {
0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c,
};
|
6.为了安全机制,开启绑定网卡选项
修改networkcards.c文件,将MAC地址加进来。
char *allow_networkcards[] = { "替换成网卡的MAC地址", NULL,};
|
开启绑定网卡以后,beast默认的网卡名字是eth0,如果你的网卡名字不是这个,后边需要将你的网卡名字加入到php.ini里。如:beast.networkcard = “eth0,eth1,eth2”。
使用phpize添加扩展
phpize
./configure
make install
如果有一步报找不到php-config错误的话,手动加上php-config的路径编译。
安装完成后,修改php.ini
extension=beast.so
重启php-fpm
到此为止,扩展安装完成。
加密代码
安装完 php-beast 扩展后,可以使用 tools 目录下的 encode_files.php 来加密你的项目。使用 encode_files.php 之前先修改 tools 目录下的 configure.ini 文件,如下:
; source path
src_path = ""
; destination path
dst_path = ""
; expire time
expire = ""
; encrypt type (selection: DES, AES, BASE64)
encrypt_type = "AES"
|
src_path 是要加密项目的路径,dst_path 是保存加密后项目的路径,expire 是设置项目可使用的时间 (expire 的格式是:YYYY-mm-dd HH:ii:ss)。encrypt_type是加密的方式,选择项有:DES、AES、BASE64。 修改完 configure.ini 文件后就可以使用命令 php encode_files.php 开始加密项目。
注意事项
步骤很多,但都是命令行。敲完命令就行了。
4,5,6是为了安全要做的。
绑定MAC地址以后,如果非绑定的MAC地址,重启php-fpm会无法启动,报错信息为NOTICE: PHP message: PHP Fatal error: Unable to start beast module in Unknown on line 0
failed
必须在绑定的网卡里才能加载生成的beast.so扩展。
部署安装方式
-
在目标机上安装扩展。装完扩展以后把php-beast-master目录的东西全部删除。
-
在部署的机子上也就是jenkins服务器上安装的扩展的目录不用删除,删除也行,记得备份第5步自定义的key。
-
在构建阶段执行自动化脚本执行php encode_files.php 加密代码。
-
在部署阶段将加密后的代码发布到目标机上。
优缺点
安全性
-
客户直接从目标机down下来代码,因为客户机上不知道加密的key,所以是无法正常解密和阅读的。
-
客户从目标机上down下来代码+beast.so扩展,因为绑定MAC地址的缘故,也是无法正常启动php-fpm的。基本上可以保证基本的安全
缺点
-
代码执行过程需要解密,有略微的性能损失。
-
自定义加密逻辑,可能有难度。毕竟C语音忘得差不多了。
可破解的方案
这里我只提供思路,因为加密后的代码需要正常被zend引擎解析,所以在最后zend引擎编译代码在过词法分析器和语法分析器时,代码已经是解密以后的代码。也就是在目标机上的zend引擎编译函数zend_compile_file里是可以得到解密以后的代码,可以修改该函数,在函数里将解密后的代码写入文件,即可拿到源码。 而我们并不需要关注加密的逻辑和加密的key。
听起来是不是很扯。如果我有了目标机的权限,也就相当于我可以通过修改zend引擎的编译逻辑来拿到源码。这样安全么?
讲道理,没有绝对的安全。
php-beast确实也是劫持的zend_compile_file方法,在代码到达zend引擎编译函数之前,完成解密的。
对于该类写扩展加密的情况,在拥有服务器权限的情况下。破解的难度可能就在于是否熟悉C语音和zend引擎的工作原理。
想要绝对的安全(绝对的安全应该是不存在的),只能是修改zend_compile_file的编译逻辑,也就是改zend引擎的底层逻辑。也就是swoole complier的思路了。不过swoole complier是对编译以后的opcode作了手脚,也就是zend引擎在执行opcode之前需要完成解密的,或者是在执行过程中动态解密。具体的不太了解swoole complier的思路。不过可以知道的是swoole complier需要技术底蕴深厚的人才能破解。
这样做就看是否值得了。
更安全一点?
在这样的情况下我们可以开启两层加密,第一层用ascii码127到255中间的乱码混淆PHP代码。第二层对乱码混淆的代码做加密。就是说即使他们登录上服务器修改了zend引擎的解析函数,拿到的也是混淆以后的乱码。想要还原成PHP代码还需要一定的时间。只是增大了破解的难度,但是对于有耐心的人,依然是可以破解,只是时间问题。