ionCube stores php files in encrypted format and it is installed as php extension but what i want to know is when I request the encrypted php file from non-encrypted php file how does php compiler executes it.
Does it send the encrypted file to ionCube server and get the original file and compile that or there is something else.
Means how the communication is going on between our server and ionCube. I guess it is through curl but i want to know how it works.
As you may have picked up on now, original code is never obtained, and processing is based on bytecode.
Here's some high level information that may help.
PHP Extensions
PHP has two types of extensions, module extensions such as CURL that typically wrap external APIs and expose their functionality via new PHP functions, and PHP engine extensions. Though the distinction isn't set in stone, engine extensions tend to interact with PHP's compiler and execution engine, though they may add new PHP functions too. ionCube is an engine extension that also adds PHP functions for its API and also to support ionCube24, though used also to be installable as a module extension using dl(). Both kinds of modules are shared libraries, and a single line to the php.ini file is used to add an extension to PHP, with PHP making use of OS functions to dynamically link the library into the running process.
Hooks
PHP has internal hooks that allow an extension to intercept the compile and execute stages of source file processing. An extension might use these simply to perform additional steps before or after regular processing, or replace the usual processing entirely. The ionCube Loader uses the compile hook to examine a file before the PHP engine compiles it, and takes over the task of processing the file if it is an ionCube file. The result of either reading an ionCube file or normal compilation is ultimately bytecode, however ionCube bytecode is non-standard, and with version 9 it may still be encrypted or unavailable for other reasons after initial processing of a file. As the standard execution engine cannot process ionCube bytecode, the Loader also uses the execution hook to take over execution of the compiled code if it was read from an ionCube encoded file.
A further task of the Loader is to allow files produced for certain older version of PHP to run on newer versions, and where necessary the Loader performs on the fly transformations of the compiled code to make it usable on whatever version of PHP is running. PHP internals change significantly from time to time, most recently and most significantly between PHP 5 and 7, making this a challenging but important task for end user experience.
Processing of ionCube files does not require communication with outside servers, however since version 9, code can be protected with encryption keys that only exist when created at runtime by the PHP application itself, and an application developer may write PHP code that makes external calls to obtain data for constructing the decryption keys when required.
Encoded files
In terms of the files themselves, early PHP encoding tools of this type in essence compiled to bytecode and serialised this form directly to files. There was little knowledge and interest in PHP internals among developers in general, and this approach gave good protection and excellent performance. When interest first emerged in producing bytecode decompilers from a hacker group in China called the "Blue Wind" around 2006 ish, simply compiling to bytecode was clearly no longer acceptable. To varying degrees, tools such as ionCube then added more protection around the bytecode to hamper the task of successful reverse engineering. Though steps can be taken to limit the effectiveness of decompilation even if bytecode is recovered, the success at code protection still depends fundamentally on the ability to hide the necessary decoding key(s) though, and all encoding tools of this type store such a key in the encoded file itself.
In evolving code protection for ionCube version 9, a challenge was to address the limitation of stored keys, and the ability to encrypt code without storing the necessary decryption key statically anywhere was the obvious and necessary next step. This was added as a feature called "Dynamic Keys".
Hopefully that gives some insight into how ionCube and in some respects similar tools work. For more detailed knowledge of engine extension implementation, I'd recommend looking at the source code for the PHP OpCache and also Derick Rethans Xdebug.
Disclosure: I am associated with ionCube.
Related
The PHP interpreter is converting as a first step the souce code into bytecode. In a second step, the bytecode is passed to a Zend Engie that creates the machine code for the relevant CPU. If opcache is activated, the bytecode is stored in cache, so that the first step can be skipped in subsequent calls.
(Image taken from PHP Master Write Cutting-Edge Code)
However, I do not understand why opcache is caching bytecode instead of maschine code? Would it not be a big benefit if one could skip the first and second step? Also, since a website is in many cases only executed on one single server, I don't see that PHP is using the benefit of bytecode, which is (if I understood correctly) that the code can be used on different hardware.
About my research: Most questions that I found were about if PHP is interpreter or compiler language.
The closest relevant question that I found was: Can you "compile" PHP code and upload a binary-ish file, which will just be run by the byte code interpreter? - but here it was asked if it is possible to parse the bytecode beforehand and upload it (instead of caching). But my question is if the machine code can be cached instead of the bytecode.
I am assuming that this is done so that there only needs to be one compilation strategy and leave it up to the OS dependant PHP interpreter to convert the OpCache to machine code that can run natively.
Compare it to java, where the compilation artifacts are JVM bytecode and it's up to the JVM which is platform specific to turn this bytecode into executable machine code.
If PHP would have to know every possible platform (intel,amd,spark,arm,etc.) this would massively bloat OpCache compiler. However you usually only have the PHP runtime (refered to as Zend Engine in your diagram) that you need on your machine.
I'm trying to obfuscate and speed up my code using Zend OpCache, but OpCache doesn't seem to have the usual functions to store bytecode in a file like other older caching systems did. As OpCache is the native method of caching files in memory in opcode, I'd like to continue using it, but I need to be able to obscure my code in the case of a system breach. (Just another security precaution)
What options do I have available to me to store my PHP files as compiled code in opcode or bytecode?
EDIT: I think people misunderstood what I was looking for for the most part. Please read my comments on the posts. I'm a professional web developer of over 12 years, so I'm not new to this. I just wanted to change my tactics a bit and see if others knew of a way to pull this off that I didn't think of.
It's definitely not a good idea to start developing your own tools for obfuscating or protecting your PHP code.
For protected your code use SourceGuardian or Nu-Coder. Both tools, however, require installing special PHP extension on server, which is not an option for many webhosting companies. These tools provide possibility to lock your code to certain machine (hardware hash, IP binding, ..), control the number of licences, expiration etc.
If you are serious about protecting your code (not only obfuscation) use virtual server + one of the tools mentioned. In run-time, both extensions hold in-memory opcached decrypted low-level code, so besides protecting the code they provide also performance boost. I tested PHP 5.5.x with loaded both SourceGuardian and opcache and there were no conflicts.
Guys recently I decided to go back to PHP and do some more complex stuff than a simple log in page. For 3 years I've been programming with Java/JavaEE and have a good understanding of the architecture of of Java Applications. Basically, a virtual machine ( a simple OS process ) that runs compiled code called byte code. a simple Java web server is basically a java application that listens on provided TCP port for Http requests and responds accordingly of course it is more complicated than that but this is its initial work.
Now, what about PHP ? How does it work ? What, in a nutshell, is its architecture.
I googled about this question but in 90% the articles explain how to implement and construct a web application with PHP which is not what I am looking for.
The biggest difference between a Java web server and PHP is that PHP doesn't have its own built-in web server. (Well, newer versions do, but it's supposed to be for testing only, it's not a production ready web server.) PHP itself is basically one executable which reads in a source code file of PHP code and interprets/executes the commands written in that file. That's it. That's PHP's architecture in a nutshell.
That executable supports a default API which the userland PHP code can call, and it's possible to add extensions to provide more APIs. Those extensions are typically written in C and compiled together with the PHP executable at install time. Some extensions can only be added by recompiling PHP with additional flags, others can be compiled against a PHP install and activated via a configuration file after the fact. PHP offers the PEAR and PECL side projects as an effort to standardise and ease such after-the-fact installs. Userland PHP code will often also include additional third party libraries simply written in PHP code. The advantage of C extensions is their execution speed and low-level system access, the advantage of userland code libraries is their trivial inclusion. If you're administering your own PHP install, it's often simple enough to add new PHP extensions; however on the very popular shared-host model there's often a tension between what the host wants to install and what the developer needs.
In practice a web service written in PHP runs on a third party web server, very often Apache, which handles any incoming requests and invokes the PHP interpreter with the given requested PHP source code file as argument, then delivers any output of that process back to the HTTP client. This also means there's no persistent PHP process running at all times with a persistent state, like Java typically does, but each request is handled by starting up and then tearing down a new PHP instance.
While Java simply saves persistent data in memory, data persistence between requests in PHP is handled via a number of methods like memcache, sessions, databases, files etc.; depending on the specific needs of the situation. PHP does have opcode cache addons, which kind of work like Java byte code, simply so PHP doesn't have to repeat the same parse and compile process every single time it's executing the same file.
Do keep in mind that it's entirely feasible to write a persistent PHP program which keeps running just like Java, it's simply not PHP's default modus operandi. Personally I'm quite a fan of writing workers for specific tasks on Gearman or ZMQ which run persistently, and have some ephemeral scripts running on the web server as "frontend" which delegate work to those workers as needed.
If this sounds like a typical PHP app is much more of a glued-together accumulation of several disparate components, you'd be correct. Java is pretty self-contained, except for external products like RDBMS servers. PHP on the other hand often tends to rely on a bunch of third party products; which can work to its advantage in the sense that you can use best-of-breed products for specific tasks, but also requires more overhead of dealing with different systems.
This is how does PHP work:
(one of the best over the Internet)
In general terms, PHP as an engine interprets the content of PHP files (typically *.php, although alternative extensions are used occasionally) into an abstract syntax tree. The PHP engine then processes the translated AST and then returns the result given whatever inputs and processing are required.
Below image will depict more information
Source: freecodecamp.org
I have an old flat file perl db that's part of an eCommerce site I want to migrate to a new php application.
Is it possible to read with php the "table" files have no file extension and seem not be just csv's or similar?
If I understand your question correctly, you have the kind of Perl database that's accessed with a so-called bound hash.
This uses technology generically known as dbm. The most recent implementation is gdbm, a GNU version, that's described here. http://www.gnu.org.ua/software/gdbm/ It's likely (but not 100% certain) that's the version used by the Perl infrastructure of your old app.
There's a PHP API with functions like dba_open() that also supports dbm variants. http://www.php.net/manual/en/ref.dba.php . You should be able to handle that file of yours with it.
It's worth observing that this dba_ extension wasn't loaded in my php implementation until I enabled it explicitly. You may have to mess around with various dbm implementations until you find the one that matches. The three I know about are the original UNIX one, dbm, ndbm, and gdbm.
I'm looking to protect small parts of my source code from being read when it is installed in other servers. Our created software consists of an engine, which is entirely copyrighted and an open source UI layer, which is released as open source.
That engine works with many API calls to our central server and is encrypted, but if source code of the engine can be read then that causes problems for data integrity when information is sent or received from central server. As a result we need the engine source code to be both fast and not readable.
I know that APC can cache bytecode and is very fast, but can I somehow convert the source code to bytecode and release it that way directly, without needing APC? As in, convert PHP source code to bytecode without requiring to install additional extensions to the other server?
I'm not looking for software such as IonCube or Zend Guard or any obfuscators.
Any help would be appreciated, I read through a handful threads here about compilers and obfuscators, but nothing that seemed to be the solution.
You could use apc_bin_dumpfile to store your files' generated bytecode and then redistribute it. Other platforms must have apc installed to be able to read it using apc_bin_loadfile.
You could also try compiling your code as a php extension using phc