@lisxour

1. bpc.dev 用的是 Let's Encrypt 证书,我这边 Chromium/Firefox 都 OK,是哪个报 NET::ERR_CERT_COMMON_NAME_INVALID?
2. 如果你亲自动手试一下的话,就会看到每次编译都会有一个.bpc-build-PID 的目录,里边有 bpc 生成的 scheme 代码,编译时加上相应参数也能看到 scheme 进一步生成的 c 代码,何来魔改 php-src?
3. 关于兼容性,BPC 直接跑的是 php 的 phpt 测试,并且对 phpt 的更改必须在一个白名单中,参看 https://github.com/bob-php-compiler/bpc-php-7.2.19-tests

@AngryPanda 开源了会有另外一堆人说别的.

其实你可以知道里面干了啥的,第一步转译出的 scheme 代码是可读的.

@xiaotianhu 可能是你本地网络的问题,服务器不在国内.

@ywisax
@haha512

由于 PHP opcode 可反编译的问题,要想真正保护源码就必须脱离 Zend 引擎.
静态编译一个 PHP 并不是什么麻烦事,使用 PHP embed 都可以把 PHP 嵌入 C 程序,我们自己的项目也把 PHP 静态编译成.a 嵌入 vala 来做一些事情.

不管是国际化还是国内化,还都没有展开做,我们有自己的项目,先把自己的项目做好,再说别的.

rabbitvcs

https://github.com/rabbitvcs/rabbitvcs

@sadfQED2 商业化还没启动,公司目前也没有明确要求,所以当前感兴趣就让试用.tar 包里是有一个 license 的,只有几天的有效期,过期后只要发邮件给我们,在明确商业化策略前,都会给短期的试用 license.

如果你有好的想法,可以找我们公司 CEO 或者 CTO 聊聊.

@ly841000 也可以用 kphp 把 php 转成 c++ https://github.com/VKCOM/kphp

@sadfQED2

1. 开不开源不是问题,闭源编译器有很多,另外做源码保护的 ionCube,Swoole Compiler 都是闭源的.
2. 后续版本是否跟进不好说,目前 target 在 php7.2 是我们自己的需求,由于 bpc 完全脱离 zend,如果愿意搞,我们可以弄出一个新语言来.就像 hacklang.
3. 本地部署不给客户服务器密码对我们来说不行,再说硬件都在客户那里,想看机器里的东西办法多了去了.

@sunny1688 php 官方明确不做 aot https://github.com/php/php-src/issues/8203

@leo108

这个项目目前不打算开源,只能 release 二进制了.

看来我 wiki 写的还不错?

不要看到编译器就想着牛逼,就是很朴素的转译,不是一步到二进制的,php 到 scheme 到 c 的代码都是可见的.

目前由于还缺少一些关键特性比如 namespace 没实现,所以很多项目即使想用也用不起来.

@sadfQED2 1 个人两年时间

@rekulas 发邮件到 YnBjQG91cmF0cy5jb20=

来分享一下我们最近在做的事,这事要是没有测试保障,很难做成.

我们是做 SASS 招聘管理系统的,开发语言是 PHP,2010 年开始开发,2012 年开始引入 PHPUnit 写单元测试,2020 年做过一次统计,当时代码库有代码约 900 万行. https://zhuanlan.zhihu.com/p/150548910

然后这两年我们想做本地部署,大家知道,PHP 项目做本地部署基本就等于交出了源码.
这是我们不期望的,我们自认为自己产品做的不错,一个几十万元的本地部署项目就把源码给出去太亏了.

那怎么办呢?经过一番调研,我们打算将 PHP 转译成 C,然后编译成二进制,这就好了.
于是就有了我们的 PHP 编译器 BPC. https://github.com/bob-php-compiler/bpc-release
但是 BPC 最终转译出来的 C 代码是否等价于 PHP 呢?
单元测试此时帮了大忙.

1. php 自身及扩展是都有相对完整的测试的,就在 php 源码的 tests 目录里.所以 bpc 如果能够顶替掉 php 解释器,然后还能通过测试的话,那就是最强有力的保障了.然后在 tests 的帮助下,我们实现了 runtime 及需要的扩展. https://github.com/bob-php-compiler/bpc-php-7.2.19-tests
2. 接下来要用 bpc 把 phpunit 编译出来,有了 phpunit,就能确保编译过后的二进制的运行结果和 php 解释器的运行结果一致了. https://github.com/bob-php-compiler/bpc-phpunit.phar-4.8.36
3. 我们的项目是基于 zend framework 1 的,zf1 的单元测试也是用 phpunit 写的,编译 zf1 library,编译 zf1 tests,运行结果一致,zend 就没问题了. https://github.com/bob-php-compiler/zf1
4. 接下来就是我们自己的招聘管理系统了.同样有 phpunit 写的测试保障,只要编译出来运行测试没问题,那就是 99.99%没问题了.

在测试的保障下,现在我们虽然开发的时候用的是 php 解释器,但将来部署出去的话,整个服务器上就几个二进制文件,是没有 php 环境的,测试已经保证了转译后的 C 代码运行结果和 php 一样,这就放心交出去了.

试想如果没有单元测试保障,每一步心里都是忐忑的,还怎么做事呀.

同样的事情亲身遇到过,2 年前 Moka 就这样蹭 OurATS 的广告,只能说这些人太坏了!

看下这个 https://0xnobody.github.io/devirtualization-intro/
不要和搞逆向的斗智斗勇.

要转换思路:
1. 任何授权到最终都是一个 if 判断,搞掉这个判断授权就绕过了.
2. 不能假设别人定位不到这个 if.
3. 虽然能定位和绕过授权判断,但这需要时间,比如 10 分钟?
4. 添加足够多的授权判断.

我这边也是做 toB 的,并且是用 PHP 开发的.
为了保护源代码和搞定授权,开发了一个名为 bpc 的编译器.
bpc 在编译 php 代码的过程中,在合适的位置插入授权判断,插入数量由参数控制.
思路供参考.
https://bpc.dev

@equationl 我没有实际做过破解,多问一句,如果在代码里加上几十万处 if 后,if 代码不完全一致,是有办法批量处理的吗?

分享一下我的思路,关键有两点:

1. 定位到 if 判断需要一定时间
2. 要有办法在代码中加入足够多的 if 判断

@ywisax 看起来 workerman 就是一个很正常的 php 程序,也许到了明年就可以了.

@v23x php 官方近期不会做 aot 的

https://github.com/php/php-src/issues/8203