PHP代碼加密和擴展解密實戰
這種方案是通過對代碼進行加密,然後利用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代碼還需要一定的時間。隻是增大瞭破解的難度,但是對於有耐心的人,依然是可以破解,隻是時間問題。
以上就是PHP代碼加密和擴展解密實戰的詳細內容,更多關於PHP代碼加密和擴展解密的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- None Found