PHP Classes

PHP Source Code Protection Solutions - PHP Application Packer package blog

Recommend this page to a friend!
  All package blogs All package blogs   PHP Application Packer PHP Application Packer   Blog PHP Application Packer package blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP Source Code Prote...  
  Post a comment Post a comment   See comments See comments (6)   Trackbacks (0)  

Author: Vallo Reima

Posted on:

Package: PHP Application Packer

Many PHP developers need to protect their source code when they distribute it to customers, to minimize the chances of their work being altered or copied without their permissions.

Read this article to learn about PHP source code protection solutions in general, and how PackApp package can help protecting your PHP source code.








PHP developers are faced with the problem of protection their intellectual property after delivering the product to the customer. A EULA (End User License Agreement) or a proprietary license provides legal protection, but will not actually prevent unauthorized use of the software product.

Compiling or encoding of the source code would eliminate the problem but imposes requirements to the customer server so the compiled code can run.

Using of the SaaS model could be another solution but it requires the vendor server support to be available 24/7.

However, when the product is to be installed in the client's server, usually it provides a standard environment like LAMP based stack. This article discusses how to protect a PHP application in this case.


The PHP application in the client's server needs 2 kinds of protection:

  1. Prevent reading and modifying the application's source code
  2. Prevent redistribution of the entire application

The first measure to make the source code more difficult to read is the "minification". Removing the comments, white space and line breaks significantly reduces readability. However, it is not a problem to write a small script to reformat minified code to make it readable. The mnemonic identifier names are still informative enough to understand the code with some effort.

Another measure that may help here is obfuscation. Renaming the identifiers with occasional values makes the source code very hard to understand, alter or use.

The minified and obfuscated source code can still be copied and installed in any other server. So, the application must be locked to the client's site to prevent redistribution. There are several options for the locking the source code using: server IP address, site domain name, a specific URL, hardware (MAC) address. The application must include necessary functionality to verify the lock criteria before performing any actions.


There are many minifiers, obfuscators, encoders around. Some commercial encoders are very good, but rather expensive and may require system extensions. The other solutions may use very trivial algorithms or are limited only to a single source.

There are minifiers that take advantage of the PHP tokenizer to parse the source code into token values. The source code is rebuilt stripping the comments and whitespace.

The minified source code needs further scrambling which can be performed either by encoding or obfuscation. The simpler encoding method is to apply the base64_encode() and eval() to the unaltered source code or to use some encryption. But it is also easy for any competent PHP programmer to decode such script to see the source code.

The most reliable way to build a lightweight obfuscator is to parse the source code lexically, replace the identifiers with meaningless names, and then rebuild the PHP source code. That must be done across all source code files including also the templates. Therefore many online tools are not suitable for this purpose because they process only individual scripts.

Encryption and decryption based solutions have other problems. Ultimate tools like Zend Guard, SourceGuardian or ionCube use more sophisticated encoding methods. However, apart from the cost of these commercial solutions, they also require a PHP extension usually called the Loader. Different Loader versions are supplied depending on the web-server but the customers may not want to (or cannot) install them.

The encoders may have optional locking features. The locking code is built in the encoded source and the check is made during the execution. Again, a competent programmer can locate this code and eliminate the lock check.


The PHP Application Packer fills the gap between simple obfuscators and ultimate tools. For this package packing means minifying, obfuscation, compressing with ZIP.

PackApp.php packs the project files: minifies the source (HTML, CSS, JavaScript, JSON, PHP, XML), obfuscates the code (JavaScript, PHP) and compresses the resulting files. The source code can be either a single file or a folder which may have sub-folders. The result is either a packed file or a folder with the packed files. The ZIP archives are handled also: folder-to-zip, zip-to-folder, zip-to-zip.

You can try the single-file demo here.

Main features and benefits:

  • Packs an entire project at once
  • Suitable for back-end and front-end projects
  • Processes different source types and embedding
  • Minification and obfuscation are separated
  • Lightweight and compatible as it is written in PHP
  • No system extensions and encoding is required

A Web based user interface is supplied to control the packing process with several options.

PackApp GUI

The PackApp can be called also from PHP script as explained in this description page.

The PackApp installation includes the registration which ties the package to the customer's web-directory. That could be a pattern for your own locking solution.

PackApp Install

The package's source code itself is minified and obfuscated - try to undo it! You can obtain the full version of the PackApp from here.


So just as a lock won't prevent others from breaking into your house obfuscation won't prevent others from using your code, it will just make it harder for them. The goal of the PackApp package is to make reverse engineering rather expensive to attempt to do that.

Sometimes it's enough to minify only, sometimes obfuscation is required to achieve necessary protection, or locking must be applied. The choice depends on particular application and business model.

Using any free solution is often not satisfactory. If it seems too much to pay a few tens of dollars for the utility, then probably that source code does not need the protection at all.

If you are looking for all-in-one protection, then you should be ready to pay 10 times more (maybe every year) and your client should be ready to install web-server extensions. In most cases an intermediate solution like PackApp is suitable for many independent software vendors.

If you liked this article or you have questions about protecting your PHP source code using PackApp, post a comment here.

You need to be a registered user or login to post a comment

Login Immediately with your account on:



3. great for locking your code from web hosting service providers - Wamala Phillip (2016-03-03 11:25)
great for locking your code from web hosting service providers... - 0 replies
Read the whole comment and replies

2. problems with variable variables - Csongor Halmai (2016-03-03 01:45)
problems with variable variables... - 2 replies
Read the whole comment and replies

1. Very nice package - Ezra Obiwale (2016-03-02 13:20)
Good work.... - 1 reply
Read the whole comment and replies

  Post a comment Post a comment   See comments See comments (6)   Trackbacks (0)  
  All package blogs All package blogs   PHP Application Packer PHP Application Packer   Blog PHP Application Packer package blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP Source Code Prote...