代码的保护一直是软件公司所担心的问题，因为很多源码对于公司来说就是命脉，而有些公司则弱化了代码的保护，转而将更多的精力花在服务上。
最近研究了一两天 PHP 代码的加解密问题，因为 PHP 编写的程序是直接通过源码发布的，并没有编译生成二进制文件或者是字节码文件（虽然二进制和字节码一样可以通过其他方式得到，但至少不是源码那么直接）。
PHP 代码的保护大概分为三种吧，至少我是这么了解的。
第一种是三种里面最简单的一种，基本就是混淆变换之类的。混淆的方式就是将代码就是变量名、方法名进行粉碎，将代码进行变换（也可以称之为加密，我为什么称它为变换呢，因为它并不一定是只用加密，也可能只是进行了其他的编码），再加一些花指令（花指令就是让人眼花的指令，加一些无关紧要的代码进行），指令乱序（正常逻辑顺序的代码语句打乱后，用 goto 重新连接使之执行时依然正确）。上面的一些词不一定准确，基本能表达清楚就行。这种方式我认为兼容性比较好，因为都是在 PHP 代码层面进行；问题是，还原的代码也在 PHP 代码文件中，虽然还原代码也进行了混淆变换之类，但是毕竟还是有下手的地方。
关于上面这种加密的解密方式，这里有两篇以前的文章，可供参考：
- PHP 代码混淆处理思路
- PHP 恶意程序简单分析
第二种是使用 PHP 扩展进行代码的混淆变换等，这种方式对代码的处理和第一种的方式基本一样，只不过代码的加解密放在 PHP 扩展层面了。这种方式已经算是比较底层了。因为处理方式已经不在 PHP 代码的层面了，也就是在执行代码时对代码进行还原，也是 PHP 的扩展完成的。因为 PHP 扩展大部分是使用 C 语言来编写的（貌似有其他语言可以写，据说好像还有类似 PHP 的语言还是框架可以写 PHP 扩展，记不清楚了），而且发布使用的是二进制文件，比如是 .so 文件，或者是 .dll 文件。这样就已经有门槛了。毕竟二进制文件是无法直接通过文本文件能看懂的（还是有人能看懂的，只是少）。这种方法我认为是最好的，这种方法比较折中，安全这种东西本身没有绝对的，也只有在性价比方面最合适的吧。因为，它在代码层面无法直接查看（用文本编辑器打开没法看），再者对于 PHP 而言它只是一个扩展一个插件。但是缺点是，貌似需要版本兼容，也就是这个扩展需要跟指定的 PHP 版本或者一个版本范围要兼容，但是也不完全算是缺点，毕竟能满足主流的版本就可以了。
关于上面这种加密的解密方式，在网上也有相关的文章，这里就不给出了，自己搜索吧。解密的基本思路是，分析加密后代码的文件结构，确定加密体、加密体长度、加密算法、加密密钥，从而进行解密。
第三种是 PHP 引擎级别的，这种级别对于 PHP 而言应该是最底层的了。在底层实现一套自己的解释引擎，然后将 PHP 源码生成为自己实现的解释引擎可以识别的字节码从而到达加密的效果。这种加密效果较上面两种效果是最好的，但是实现难度也是最大的。对于版本的要求也是更严格的；对于技术要求也是最难的。
以上三种加密方式的破解难度是递增的，实现难度也是递增的。个人感觉上拿到加密后的文件和运行环境是应该可以破解的，毕竟最终都是要实际运行的。但是具体肯定视水平而定。毕竟加解密是加密者和解密者水平的一个较量。
最后再补充一下，据说有的程序员在写 PHP 程序员时，部分代码专门用 C 写，然后用 PHP 调用，精力足够，貌似也不错。
