Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.43 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <537DA268.1000801@tobin.nl>
Date: Thu, 22 May 2014 15:47:37 +0200
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <416063C7-D802-4AD1-938C-035F0EBC373D@googlemail.com>
References: <CAOg_pRQxKsJPgFaZ6_y7Rf1i4Bfkbx+FhCxuBtE9PWu58uOfOQ@mail.gmail.com> <537DA268.1000801@tobin.nl>
To: Bas van Beek <bas@tobin.nl>
Subject: Re: [PHP-DEV] encode php scripts with opcache compatibility
From: ingwie2000@googlemail.com (Kevin Ingwersen)


Am 22.05.2014 um 09:08 schrieb Bas van Beek <bas@tobin.nl>:

>=20
> op 21-05-14 12:20, Nicolai Scheer schreef:
>> Hi all,
>>=20
>> I'm currently facing the situation, that I need to protect my php =
sources
>> and retain opcache compatibility.
>>=20
>> I know there are quite a few commercial tools for "encoding" and =
protecting
>> php sources, but none of them seems to work in conjunction with php's
>> opcache extension.
>>=20
>> Most products see this as part of their protection scheme.
> As said in the conversation spawned by your question it is possible to =
reverse engineer the opcodes to php script and as you noted you're ok =
with at least a first line of defense against customers altering =
scripts. I might have a workable solution to your problem.
>=20
> I faced a similar problem where I didn't want the PHP source code for =
a client application (win32 service/*nix daemon with embedded webserver, =
PHP API layer and AngularJS front-end) to be easily viewed and/or =
modified. So I built an embedded filesystem that is encrypted. For this =
embedded filesystem I wrote a PHP stream extension so I can access the =
files in that filesystem as if they reside on a regular disk. In the C++ =
code of the main app I open the embedded filesystem with the decryption =
key and I make a filesystem handle available to the PHP stream =
extension. The embedded webserver can access the embedded filesystem =
directly with its API and within PHP the stream extension takes care of =
that. This solution is compatible with PHP 5.5 and opcache and has the =
added bonus of only needing to ship a single file for all PHP, JS, Image =
and other web resource files). Hope this solution points you in the =
right direction.
This solution sounds very great! Creating a PHP extension to operate on =
an encrypted, virtual, filesystem mibht offer exactly what one is =
looking for. If the app is small, it could be loaded into memory, and be =
read by far faster from there.

Definitively an aproach I am going to test out myself, to learn more =
about this.
Kind regards, Ingwie.