PHP7中用opcache.file_cache导出脚本opcode实现源代码保护

停止php-fpm(apache同理):sudo /png/php/7.0.0/png_fpm stop创建opcode缓存目录:mkdir -m 777 /png/php/opcache_file_cache在php.ini中配置:zend_extension=/png/php

停止php-fpm(apache同理):
sudo /png/php/7.0.0/png_fpm stop

创建opcode缓存目录:
mkdir -m 777 /png/php/opcache_file_cache

在php.ini中配置:
zend_extension=/png/php/7.0.0/lib/php/extensions/no-debug-non-zts-20151012/opcache.so
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
;关闭PHP文件时间戳验证
opcache.validate_timestamps=Off
;每60秒验证php文件时间戳是否更新
;opcache.revalidate_freq=60
opcache.fast_shutdown=1
;注意,PHP7下命令行执行的脚本也会被 opcache.file_cache 缓存.
opcache.enable_cli=1
;设置不缓存的黑名单
;opcache.blacklist_filename=/png/php/opcache_blacklist
opcache.file_cache=/png/php/opcache_file_cache
opcache.enable=On






phpMyAdmin的PHP文件一一对应的opcode(后缀为.php.bin)生成在:
/png/php/opcache_file_cache/xxx/png/www/example.com/public_html/app/pma
其中xxx是一个32位的md5编码的字符串.
部署到目标服务器的时候,需要保留项目中内容被清空的PHP脚本.
而且路径一定要对应导出opcode时的路径,文中的就是:
/png/www/example.com/public_html/app/pma

后话:
opcache.file_cache是PHP7对hhvm.repo.central.path的反击,鸟哥威武!
opcache.file_cache对比PHP5时代APC的apc_bin_dumpfile和apc_bin_loadfile来说,
导出和导入操作都由opcache完成,显然ZendOpcache比APC更加自动化.
那个md5串由 PHP_VERSION / ZEND_EXTENSION_BUILD_ID / ZEND_BIN_ID 确定:


因为Ubuntu上编译的PHP7,打包依赖库后放到CentOS上运行,这个md5串是相同的.
可以肯定的是,Linux上导出的opcode不能放到Windows上运行,反之也是如此.

Beast加密过的PHP文件,也一样能看到PHP文件对应的opcode,


因为Beast解密后,还是一样需要调用zend_compile_file生成页面的opcode,
而opcode是可以用VLD(Vulcan Logic Disassembler)这类PECL扩展查看的.
php -dvld.active=1 -S 127.0.0.1:8080
curl http://127.0.0.1:8080/

也就是说,PHP脚本加密能够避免脚本被恶意篡改,但脚本里的数据仍然是可见的.
所以,文中的opcache.file_cache用来保护代码逻辑应该还是可以的,
但不能确保里面定义的量的安全,比如加密密钥.

存也可以,但防君子不防小人,门槛高点而已.

Zend Guard和ionCube加密的PHP脚本可以用DeZender/De-ionCube解密:
http://dezender.net/
Java字节码和Android APK可以用Java Decompiler反编译:
http://jd.benow.ca/

Python脚本可以编译成pyc文件,不过pyc文件也很容易被反编译.
所以包括opcache.file_cache这样的代码保护,也只能防君子不防小人.