对于使用方法有些疑惑，可能导致代码轻易被破解。。

[treemonster]

我在查看您的代码时发现解密之行是通过劫持 zend_compile_file 方法，在其执行之前用明文代码替换了原本的密文字符串。为了验证这个猜测，我在compile_file（compile_file位于zend_language_scanner.c，是zend_compile_file的实体方法）这个方法中加了几行代码用于输出测试文件：

ZEND_API zend_op_array *compile_file(zend_file_handle *file_handle, int type TSRMLS_DC)
{
  。。省略无关内容。。
    if (open_file_for_scanning(file_handle TSRMLS_CC)==FAILURE) {
  。。省略无关内容。。
        compilation_successful=0;
    } else {

// 此处为增加的代码 FILE *fh = fopen("/tmp/mytest.log", "ab+"); fprintf(fh, "filename: %s\n\n%s\n\n",file_handle->filename,file_handle->handle.stream.mmap.buf); fclose(fh); // 增加的代码结束

init_op_array(op_array, ZEND_USER_FUNCTION, INITIAL_OP_ARRAY_SIZE TSRMLS_CC);
。。省略无关内容。。
return retval;
}

然后我重新编译php，使用以下命令生成加密文件： /php56/bin/php /php-beast-master/tools/encode_file.php --oldfile test.php --newfile test2.php --encrypt DES --expire "2017-10-10 10:10:10"

查看test2.php已是加密的乱码了。

启动php-fpm，并访问一次test2.php。

然后 cat /tmp/mytest.log

得到结果为

filename: /website/userdata/site/xf.php56/public/test2.php

<?php
echo "test code"; 

确实是一开始的明文代码。

因此这个破解的方式并不需要得到加密插件的源代码或者key。

太轻易的破解让我感觉这个加密太水了。。又或者是我使用的方式不对？

[liexusong]

是的，这个加密原理的确是劫持compile_file的，所以可以通过这种方法来解密。但是我们这个扩展的意图是提供一个加密的框架，具体还需要自己去定制一下，因为开源的问题，所以加密是不会完全安全的。我建议是使用者可以自己定制compile_file函数，这样就可以避免把明文被抠出来。最好的方案是连execute钩子也定制一下。

[treemonster]

直接定制compile_file用插件岂不是多余了？完全可以在zend内部做加密解密，虽然那样也可以反编译找解密口破解。。

[l396]

学习了

[cts2021]

marker

[safly]

个人认为所述解密方法是基于动态加载so模块，虽然不需要得到加密插件的源代码或者key，但必须在获得so后才能成功。 如果静态重编译PHP而不暴露beast扩展，应该就无法解密了。 @liexusong @treemonster

[treemonster]

@safly 真的要破解办法还是比较多的。就算静态编译我一样可以直接打开二进制文件找到密钥字符串。假如加壳的话，那就运行之后再读取内存中的数据。。反正这套么也就糊弄一下啥都不懂的人，会破解的人根本都懒得去破解这个东西，破了也没钱拿。。

[AngusLkc]

IDA直接能暴漏出16位的key和8位的key_1。使用这个扩展要想安全就得定制，定制就得写C代码。相比这个扩展而言。php-screw倒是提供了一个简洁的框架。就扩展二次开发而言。php-screw比这个项目简单很多。