Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <416063C7-D802-4AD1-938C-035F0EBC373D@googlemail.com>
References: <CAOg_pRQxKsJPgFaZ6_y7Rf1i4Bfkbx+FhCxuBtE9PWu58uOfOQ@mail.gmail.com>
 <537DA268.1000801@tobin.nl> <416063C7-D802-4AD1-938C-035F0EBC373D@googlemail.com>
Date: Thu, 22 May 2014 17:01:04 +0300
Message-ID: <CAL0xaBG9th1b_PpT57zp+Mh3xKZrzp47=vxnKCONg0sJp84p7w@mail.gmail.com>
To: Kevin Ingwersen <ingwie2000@googlemail.com>
Cc: Bas van Beek <bas@tobin.nl>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e014948fa6186c404f9fd8c59
Subject: Re: [PHP-DEV] encode php scripts with opcache compatibility
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--089e014948fa6186c404f9fd8c59
Content-Type: text/plain; charset=UTF-8

Maybe the Zephyr http://zephir-lang.com/ could give you an alternative to
messing with OPCache and encoders and give you some performance boost at
the same time. But only if your client can configure PHP to load an
extension of yours that Zephyr makes.


2014-05-22 16:47 GMT+03:00 Kevin Ingwersen <ingwie2000@googlemail.com>:

>
> Am 22.05.2014 um 09:08 schrieb Bas van Beek <bas@tobin.nl>:
>
> >
> > op 21-05-14 12:20, Nicolai Scheer schreef:
> >> Hi all,
> >>
> >> I'm currently facing the situation, that I need to protect my php
> sources
> >> and retain opcache compatibility.
> >>
> >> 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.
> >>
> >> 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.
> >
> > 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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e014948fa6186c404f9fd8c59--