這種方案是通過對代碼進行加密，然后利用C語音寫解密的PHP擴展。破解難度會有提升，但依然是會被破解的。
從網上找過各種代碼加密的開源方案。
一旦開源，就不可能保證安全性。畢竟加密和解密的東西都是公開的。
目前我們沒有能力自己去寫擴展。還是需要采用開源的方案。
我找到的比較好用的是php-beast。
https://github.com/liexusong/php-beast

實戰(zhàn)開始

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擴展。

部署安裝方式

1. 在目標機上安裝擴展。裝完擴展以后把php-beast-master目錄的東西全部刪除。
2. 在部署的機子上也就是jenkins服務器上安裝的擴展的目錄不用刪除，刪除也行，記得備份第5步自定義的key。
3. 在構建階段執(zhí)行自動化腳本執(zhí)行php encode_files.php 加密代碼。
4. 在部署階段將加密后的代碼發(fā)布到目標機上。

優(yōu)缺點

安全性

1. 客戶直接從目標機down下來代碼，因為客戶機上不知道加密的key，所以是無法正常解密和閱讀的。
2. 客戶從目標機上down下來代碼+beast.so擴展，因為綁定MAC地址的緣故，也是無法正常啟動php-fpm的。基本上可以保證基本的安全

缺點

1. 代碼執(zhí)行過程需要解密，有略微的性能損失。
2. 自定義加密邏輯，可能有難度。畢竟C語音忘得差不多了。

可破解的方案

這里我只提供思路，因為加密后的代碼需要正常被zend引擎解析，所以在最后zend引擎編譯代碼在過詞法分析器和語法分析器時，代碼已經是解密以后的代碼。也就是在目標機上的zend引擎編譯函數(shù)zend_compile_file里是可以得到解密以后的代碼，可以修改該函數(shù)，在函數(shù)里將解密后的代碼寫入文件，即可拿到源碼。 而我們并不需要關注加密的邏輯和加密的key。
聽起來是不是很扯。如果我有了目標機的權限，也就相當于我可以通過修改zend引擎的編譯邏輯來拿到源碼。這樣安全么？
講道理，沒有絕對的安全。
php-beast確實也是劫持的zend_compile_file方法，在代碼到達zend引擎編譯函數(shù)之前，完成解密的。
對于該類寫擴展加密的情況，在擁有服務器權限的情況下。破解的難度可能就在于是否熟悉C語音和zend引擎的工作原理。
想要絕對的安全（絕對的安全應該是不存在的），只能是修改zend_compile_file的編譯邏輯，也就是改zend引擎的底層邏輯。也就是swoole complier的思路了。不過swoole complier是對編譯以后的opcode作了手腳，也就是zend引擎在執(zhí)行opcode之前需要完成解密的，或者是在執(zhí)行過程中動態(tài)解密。具體的不太了解swoole complier的思路。不過可以知道的是swoole complier需要技術底蘊深厚的人才能破解。
這樣做就看是否值得了。

更安全一點？

在這樣的情況下我們可以開啟兩層加密，第一層用ascii碼127到255中間的亂碼混淆PHP代碼。第二層對亂碼混淆的代碼做加密。就是說即使他們登錄上服務器修改了zend引擎的解析函數(shù)，拿到的也是混淆以后的亂碼。想要還原成PHP代碼還需要一定的時間。只是增大了破解的難度，但是對于有耐心的人，依然是可以破解，只是時間問題。

以上就是PHP代碼加密和擴展解密實戰(zhàn)的詳細內容，更多關于PHP代碼加密和擴展解密的資料請關注腳本之家其它相關文章！