這是一個很笨的加密器
我們可以經常在某些經過加密文件的php文件代碼格式大體如下:
xxx_loader_lable
<?php
if(!function_exists("xxx_loader")){
die('xxx_loader not install');
}
//encrypt part
xxxxxxxxxxx
我們就以swoole_loader為例子,它加密后的文件格式大體如下
SWOOLEC<?php extension_loaded('swoole_loader') or die(' Loader ext not installed');?>
//encrypt part
xxxxxxxxxxxxxxxxxxxxx
這個文件。正常情況下,php是無法解析的。但是呢,zend_vm的一些接口,允許我們載入某些文件的時候,對文件進行預處理。因此我的拓展需要做的事情就是,如果遇到這樣格式的文件,那么我把他解析為以下兩部分:
- 部分1
<?php if(!function_exists("xxx_loader")){ die('xxx_loader not install'); }
- 部分2
//encrypt part xxxxxxxxxxx
因此,code就是我經過加密后的目標字符串,顯然,我們需要完成的一個步驟就是、字符串到代碼的轉變。而這個時候,如果有敏感的同學,就會想到一個東西,那就是
eval()
。因此以上代碼等價于:
<?php
if(!function_exists("xxx_loader")){
die('xxx_loader not install');
}
eval(encrypt part);
但是實際上,并沒有這么簡單,如果我需要實現對機器授權的限制,那么應該是這樣的。
$info = xxx_loader->decode(encrypPart);
$license = $info->licenseCheck();
if($license){
eval($info->realyCode);
}
因此,如何保護我這個xxx_loader的實現邏輯,或者是加密秘鑰,成為了代碼加解密的關鍵。但是用php的話,容易出現,被逆向比如目前場景的php混淆,很容易破解。 因此就有人提出想法,如果我把這個加密的函數協程php拓展編譯成so動態庫文件,然后so在做加殼混淆,不就完美的解決了嗎。畢竟、so加殼混淆的方案,可是非常成熟的。