ionCube 内部是如何工作的?

How does ionCube work internally?

ionCube 以加密格式存储 php 文件,它作为 php 扩展名安装,但我想知道的是当我从非加密 php 请求加密文件时 php 文件 php 编译器如何执行它。

是将加密文件发送到ionCube服务器并获取原始文件并编译还是有其他问题。

表示我们的服务器和ionCube之间的通信是如何进行的。我猜是通过 curl 但我想知道它是如何工作的。

你现在可能已经明白了,原始代码是永远得不到的,处理是基于字节码的。

以下是一些可能有帮助的高级信息。

PHP 扩展

PHP 有两种类型的扩展,模块 扩展,例如通常包装外部 APIs 并通过新的 [=53] 公开其功能的 CURL =] 函数和 PHP 引擎 扩展。虽然区别不是一成不变的,但引擎扩展倾向于与 PHP 的编译器和执行引擎交互,尽管它们也可能添加新的 PHP 函数。 ionCube 是一个引擎扩展,它还为其 API 添加了 PHP 功能,并且还支持 ionCube24,尽管也可以使用 dl() 作为模块扩展进行安装。两种模块都是共享库,在php.ini文件中一行用于添加PHP的扩展,PHP利用OS函数动态link库进入运行ning进程。

挂钩

PHP 具有内部挂钩,允许扩展拦截源文件处理的编译和执行阶段。扩展可能会使用这些简单地在常规处理之前或之后执行额外的步骤,或者完全替换通常的处理。 ionCube Loader 在 PHP 引擎编译文件之前使用编译钩子检查文件,如果是 ionCube 文件,则接管文件的处理任务。读取 ionCube 文件或正常编译的结果最终都是字节码,但是 ionCube 字节码是非标准的,并且在版本 9 中,它可能仍然被加密或在文件初始处理后由于其他原因不可用。由于标准执行引擎无法处理 ionCube 字节码,如果从 ionCube 编码文件中读取编译代码,Loader 还使用执行挂钩来接管编译代码的执行。 Loader 的另一项任务是允许为某些较旧版本的 PHP 生成的文件在较新版本上生成 运行,并且在必要时 Loader 对编译代码执行动态转换以使其可用于PHP 的任何版本都是 运行ning。 PHP 内部结构不时发生显着变化,最近一次发生在 PHP 5 和 7 之间,变化最大,这使得这对最终用户体验来说是一项具有挑战性但很重要的任务。

处理 ionCube 文件不需要与外部服务器通信,但是从版本 9 开始,可以使用加密密钥保护代码,这些密钥仅在 运行 时间由 PHP 应用程序本身创建时才存在,应用程序开发人员可以编写 PHP 代码,在需要时进行外部调用以获取用于构造解密密钥的数据。

编码文件

就文件本身而言,早期的PHP这种类型的编码工具本质上是编译成字节码,并直接将这种形式序列化为文件。一般而言,开发人员对 PHP 内部结构知之甚少,兴趣不大,这种方法提供了良好的保护和出色的性能。大约在 2006 年左右,当中国的一个名为 "Blue Wind" 的黑客组织首次对生产字节码反编译器产生兴趣时,简单地编译为字节码显然不再是可以接受的。在不同程度上,ionCube 等工具随后在字节码周围添加了更多保护,以阻碍成功进行逆向工程的任务。尽管即使字节码 恢复,也可以采取措施限制反编译的有效性,但代码保护的成功仍然从根本上取决于隐藏必要解码密钥的能力,并且这种类型的所有编码工具都将这样的密钥存储在编码文件本身中。

在 ionCube 版本 9 的代码保护发展过程中,一个挑战是解决存储密钥的限制,以及加密代码的能力 而无需 静态存储必要的解密密钥 anywhere 是显而易见且必要的下一步。这是作为称为 "Dynamic Keys" 的功能添加的。

希望这能让您深入了解 ionCube 以及在某些方面类似工具的工作原理。有关引擎扩展实现的更多详细信息,我建议查看 PHP OpCache 和 Derick Rethans Xdebug 的源代码。

披露:我与 ionCube 有关。