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
Related
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.
I've been searching the internet for over 3 days now and cannot find anything that has a clear explanation of how to install ffmpeg for php. I currently have ffmpeg installed correctly on my Mac command line but as to how to use it in my php scripts is beyond me. How do I install ffmpeg for php? Any help would be great. Thanks.
ffmpeg is a set of executable programs and not an API. There was a project I was aware of in the past that built a php extension, but it was not robust and never really emerged as viable for a number of reasons, not the least of which is that ffmpeg has a lot of different options and builds.
Several years ago I was tasked with building an audio and video encoding system for a social network startup, utilizing PHP as the middleware, so I've been through this exact exercise.
One of the most challenging aspects was coming up with a working compiled version of ffmpeg with all the encoders we wanted to have. In our case our hosted environment was AWS and we were using Amazon linux servers, so there were a few hiccups along the way, and patches I had to chase down. There were packages available that had ffmpeg, but they were hopelessly outdated and missing key features we needed. The only way to get things working was to get the ffmpeg source and compile it, along with the source for the various codecs we were using, primarily to get mpeg4 video and compatible audio. If you aren't comfortable doing this, you will probably not be able to get things working.
In regards to the PHP side of it, I ended up using the PHP-FFMpeg library suggested in the comment above, but I did fork it and made a lot of customizations that worked for us, but were not really contributable back upstream. Subsequently, the maintainer of the library has addressed many of the issues I had and it is a much more robust library now that should save you a lot of problems if you were to try and create your own wrapper.
In summary your server needs:
A working compiled version of ffmpeg and its associated helper
programs which may be of need depending on what you're going to be
doing with media you are producing. For example, there is a separate media introspection program (ffprobe) that is used to determine the characteristics of media you want to encode.
A PSR-0/Composer compatible project. Ours was built on top of Symfony 2.x but that isn't a requirement. I did want to mention it as the project has really pushed the improvement and stability of the symfony component that wraps the php 'exec' function at the heart of any effort to call an external program.
Following the instructions and reading through the API you should be able to get a sample encoding to work with PHP, but keep in mind that ffmpeg works with files, and there are lots of file related issues you have to think through (original files, rendered files and naming, temporary file locations) all of which you'll have to deal with unless you're doing something trivial. In our case these programs were async command line/batch oriented and there was a lot of time and effort that needed to go into figuring out a way to scale and be performant. Needless to say, encoding video can take a lot of time, and is not something you want to do in a monolithic php script where the end user uploads and then waits while you do all the processing in the same script!
I know you are trying to do this on your Mac. Is this really the target environment for your production deployment? This is finicky and platform dependent enough of a process that I don't think it's advisable to try and get a hacky version on your Mac, because the process of getting ffmpeg, and the exact version and components is highly variable and extremely important to your success.
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.
Is it possible to convert PHP to binary mode (compile) and run it in all standard web servers?
There are various PHP accelerators that cache the compiled byte code the interpreter produces. Not sure if they will run without the source still on the server though - I've never tried!
One Facebook developer is working on a compiled form called "Hyper-PHP", and it's not even clear if that will be an open system once complete, but no solution exists yet.
PHP Will never be a compiled Language. It will stay as an Interpreted Language.
#Matchu Facebook is just Promoting their site, so this is just an Promotion action of Facebook
There is a number of tools that will convert your php source to bytecode and allow you to protect your source code. Some of the more popular ones are Zend Guard by Zend and Ion Cube encoder. You will still need their respective loaders installed on the target server for them to function.
A friend has recommended that I install php APC, claiming it will help php run faster and use less memory
sounds promising but I'm a little nervous about adding it to my VPS server
I have one small app that I've built using codeigniter, and several sites that use the popular slideshowpro photo gallery software
could install this break any of the back end code on my sites?
I'm no high tech server guy, but should I give this a try?
Depends entirely on your situation.
Is your site unresponsive or slow at the moment? Is this definitely due to the PHP scripts and not any other data sources such as a database or remote API?
If you answered yes to the above, then installing one of the many PHP accelerators out there would be a good shout. As for using less memory, that's largely dependent on your apache/lightppd/nginx config and php.ini variables.
Most PHP accelerators work by converting the (to be) interpreted PHP code into opcode. This is then stored in memory (RAM) for fast access. If you haven't already implemented file-based caching in CodeIgniter then the benefits of installing a PHP accelerator would be noticeable. If you haven't, then I suggest you do that first before moving straight over to (wasting?) spending time trying to install APC manually.
If your site is currently performing well and you're not too confident in your *nix skills then I suggest you try implementing CodeIgniter caching first rather than try messing with what is an already working VPS.
My personal preference is PHP eAccelerator.
Should installing a PHP cache engine not improve your site's performance then I suggest you look at what other factors influence your application. As stated above, these could be: database or API to name a few.
Hope this helps.
APC is basically a cache engine that stores your compiled php scripts on a temp location on your server. Meaning that these do not have to be interpreted every time someone calls your sccript. It is a PHP extension can can safely be turned ON or OFF and it does not affect your actual code. So... do not fear!
When a php script is processed, there is a compilation phase, where php converts the source code of the php files into "opcodes". APC simply caches the result of this compilation phase, so it should be safe to turn on.
That said, when making such changes to production code it is always wise to run a regression test to ensure no new issues have been introduced.