這是一個很笨的加密器

我們可以經(jīng)常在某些經(jīng)過加密文件的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的一些接口，允許我們載入某些文件的時候，對文件進行預(yù)處理。因此我的拓展需要做的事情就是，如果遇到這樣格式的文件，那么我把他解析為以下兩部分：

• 部分1

  <?php
  if(!function_exists("xxx_loader")){
  die('xxx_loader not install');
  }

• 部分2

  //encrypt part
  xxxxxxxxxxx

因此，code就是我經(jīng)過加密后的目標字符串，顯然，我們需要完成的一個步驟就是、字符串到代碼的轉(zhuǎn)變。而這個時候，如果有敏感的同學(xué)，就會想到一個東西，那就是 eval()。因此以上代碼等價于：

<?php
if(!function_exists("xxx_loader")){
   die('xxx_loader not install');
}
eval(encrypt part);

但是實際上，并沒有這么簡單，如果我需要實現(xiàn)對機器授權(quán)的限制，那么應(yīng)該是這樣的。

$info = xxx_loader->decode(encrypPart);
$license = $info->licenseCheck();
if($license){
    eval($info->realyCode);
}

因此，如何保護我這個xxx_loader的實現(xiàn)邏輯，或者是加密秘鑰，成為了代碼加解密的關(guān)鍵。但是用php的話，容易出現(xiàn)，被逆向比如目前場景的php混淆，很容易破解。 因此就有人提出想法，如果我把這個加密的函數(shù)協(xié)程php拓展編譯成so動態(tài)庫文件，然后so在做加殼混淆，不就完美的解決了嗎。畢竟、so加殼混淆的方案，可是非常成熟的。