Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
Message-ID: <537D31E8.70401@gmail.com>
Date: Thu, 22 May 2014 00:08:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAOg_pRQxKsJPgFaZ6_y7Rf1i4Bfkbx+FhCxuBtE9PWu58uOfOQ@mail.gmail.com>	<6048BA05-CC13-46DD-8439-9CB4EE29078B@ajf.me>	<9EBA95A7-B9F7-41F0-AE2B-283260753E5A@googlemail.com>	<B58A4DF4-52FE-41D9-896C-5396DDC7CB8B@ajf.me>	<CAOg_pRSmVdw1Y9g-RrW8dBNSpBZVHavJQzSGUCjZu5wXhuUMCQ@mail.gmail.com>	<537CBD67.4000008@lerdorf.com> <CAOg_pRTvbaVmDdLhmEOi5g1BJ_KgQnJffrXcY_0b4XosLgBTWA@mail.gmail.com>
In-Reply-To: <CAOg_pRTvbaVmDdLhmEOi5g1BJ_KgQnJffrXcY_0b4XosLgBTWA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] encode php scripts with opcache compatibility
From: rowan.collins@gmail.com (Rowan Collins)

On 21/05/2014 21:12, Nicolai Scheer wrote:
> Do you have an example of a tool that can reverse opcodes to php code?
> Maybe I did not search for the right thing, I did not stumble upon any.
>
> I always thought the opcodes where kind of cryptic, at least a bit...

I don't know of any tools for "decompiling" PHP from opcodes, but that's 
probably because very few tools generate or distribute opcodes from 
anything other than PHP source, so there has been little desire for such 
a thing.

I have, however, seen the result of a Java decompiler, which can perform 
a similar job on JVM bytecode; the results are less obfuscated than a 
lot of "minified" JS scripts deployed to save bandwidth. I imagine the 
Zend Engine's opcodes are even more closely bound to PHP than the JVM's 
instructions are to Java, so I can well imagine an effective decompiler 
being possible if the motivation were there.


On a different note, I read somewhere that once HHVM has loaded each of 
your PHP files once, it no longer needs a copy on the file system, and 
can be told to never check for one. Thus you can deploy PHP code to a 
server, "prime" the HHVM memory, and then delete the source files. I 
don't know if there's any way to persist that memory state and 
distribute it to another HHVM instance, though.

-- 
Rowan Collins
[IMSoP]