@tangknox1 PHP 加密还是以下四种:

1. 玩障眼法的.

就是不改变源代码,对源代码做各种封装,运行时解密出来.这种最容易破解.

2. 在 PHP 源代码层面做混淆的.

Z5 加密就属于这一类.没有调研过,应该没有成熟的解密工具.

3. 基于 opcode 加密混淆的

本文的 AAA 和 BBB 就是. BBB 充分证明了 opcode 加密混淆根本就不顶用.

4. 第三方实现的转译器/编译器

前 3 种都是基于 PHP 解释器.加密和解密双方比的是斗智斗勇.

而第三方实现的转译器/编译器可以 100%保护源码,无需斗智斗勇.如果想省心,推荐这种,当然会有各种限制.

实现原理: PHP ---> 转译成另一种语言 ---> 编译成机器码.

当然机器码,比如汇编,也是可以反汇编的,但反汇编得到的源码和 PHP 源码就差的太远了.

目前有 3 个选择:

1) PeachPie (开源)

将 PHP 编译到.NET, 是.NET Foundation 支持的项目,如果有.NET 相关技术背景可考虑. 除加密外,还可提升性能,但和 PHP 兼容性待验证,看 issue 列表就知道了.

2) KPHP (开源)

将 PHP 转译成 C++.俄罗斯 vk.com 的项目.同样除加密外,可提升性能.但它只实现了**a limited subset of PHP**,可能需要大幅调整 PHP 源代码才能编译通过.

3) BPC (闭源,本人作品)

将 PHP 转译成 scheme,再转译成 C. 源码保护没问题,还有授权机制,但性能不高.与 PHP7.2 高度兼容,跑通了 PHP7.2 的 phpt 测试用例.通常 PHP 代码稍做调整就能编译成功.

@tangknox1 我并不是为了寻找加密工具而做的调研,只是为了了解下现状.Z5 的早在几年前就是一篇长文详述了逆向过程,你可以搜索下"PHP 解密：反汇编某虚拟机加密（不进行反编译）".当然 Z5 的加密强度也还是不错的.

@BeforeTooLate 一般来说,应该能提高性能.因为 php 代码已经预先编译成 opcode 了,省了一个步骤.

不过 php 的 opcache 扩展就是干这个的. 这类加密扩展比 opcache 多做了一些步骤,比不上 opcache.

@prodcd 试用了下 SG 16 Pro, 可以比较容易拿到 opcodes,并且没做太多混淆.几乎可以理解成把 php opcodes 用 sg_load() 封装了一下. 看官网的 Features 介绍确实也没说有混淆 opcodes 的特性.

@prodcd 这确实是没办法.如果是一次性部署的软件,组件又简单,那确实防不住.考虑一下商务手段吧.

@prodcd BBB 不是 SG,但我印象里 SG 还不如 BBB,所以就没看 SG.稍后我再看下.

@prodcd 到 dezender.xyz 上试一下看看?毕竟我用的是试用版,也许正式版本更强一些?

将 pst 转成 mbox 或者提取出一个个的 eml,然后用[gmime]( https://github.com/jstedfast/gmime)处理.

@ywisax license 已更新,可以用了.多谢!

@sunchuo 这个也不好说,3 年前还不支持 namespace,closure,generators,traits 呢,现在都支持了.需求来了的时候,就跟上了.

@sunchuo 目前 bpc 对 PHP 的支持足够我们自己用,所以没有跟进最新版 PHP 的计划.

另外 PHP 新版本的一些改进我并不觉得很好,所以不打算在 bpc 中支持.

ioncube 的话,从 easytoyou 上可以看到 ioncube11.x 是可以在线 decode 的,我自己并没有项目使用过,不确定其加密强度.

不需要 zendvm.

转译后的 scm 代码和 C 代码你都可以看到, [How_BPC_works]( https://github.com/bob-php-compiler/bpc-release/wiki/03_How_BPC_works).

扩展可以自己加的,简单地对 C lib 的封装是很容易的.

1. 扩展模板 [bpc-ext-skeleton]( https://github.com/heguangyu5/bpc-ext-skeleton)
2. 扩展示例 [bpc-ext-raylib]( https://github.com/heguangyu5/bpc-ext-raylib) [bpc-ext-raygui]( https://github.com/heguangyu5/bpc-ext-raygui)

但像 swow 这种要想集成进 BPC,得重写了.

还有一点就是,BPC 目标在于源码保护和软件授权,性能不是第一位的,所以一般谈高性能的东西,就和 BPC 无缘了,现阶段应该是这样.

@ModiKa2022 BPC 主要解决源码保护和软件授权这两个问题.

"PHP 代码加密已经比较成熟" 这个认知不清楚从哪儿来的.
我了解到的几乎所有的加密方案都有现成的或者可能的还原方法.

@hubaq 笑死,你想想 UDP 机制,封了 IP,IDC 的攻击就没了吗?

上周我们的一台放在 IDC 机房的服务器遭到了 UDP Flood 攻击,机房的处理方式一模一样,不管是不是你的问题,先把你的 IP 给封了.

感觉这些人就是自己能力不足,不能解决问题,只能解决遇到问题的机器.

遇到攻击,不是和客户一起防护,而是先杀掉客户,然后自己再承受攻击,害人不利己.

@a33291 非常感谢!

@skyworker 另外 php 和 BPC 不是二选一的问题,我们自己日常还是用 php 环境开发,只是在本地部署的项目上用 BPC 编译后发布出去.

@janus77 BPC 的测试就是随 PHP 源码发布的 phpt 测试, @see https://github.com/bob-php-compiler/bpc-release/wiki/04_phpt_tests

@skyworker

一段 php 程序,给定一个输入,得到一个或一些输出.
用 BPC 编译替换掉这段 php 程序,给定同样的输入,如果能得到同样的输出,那就够了.
此时外部已经无法分辨处理这处事情的程序是 php 还后 BPC 编译后的程序.

"底层可能有 bug"这种担心怎么说呢?我在开发 BPC 的过程中还发现了 php 的两个 bug,但是这并不影响我每天都用 php.

1. https://bugs.php.net/bug.php?id=81312
2. https://github.com/php/php-src/issues/12715

测试覆盖到你觉得你的程序没问题就够了.

比如 BPC 跑过了 php 的 phpt 测试后,我觉得 BPC 做到这里就够了.
BPC 跑通了云招 OurATS 的测试用例后,我觉得云招 OurATS 就够了.

如果你觉得无论多少测试都不能让你放心,那这就无解了,总要有个信任基础的.