这种方案是通过对代码进行加密，然后利用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代码还需要一定的时间。只是增大了破解的难度，但是对于有耐心的人，依然是可以破解，只是时间问题。
