How it works

At first srcProtector analyses files and decides which parts of code are possible to be securely encrypted. It selects variables, constants, functions or classes which are defined in the code and add them to lists to be replaced. If you have defined framework, it automatically excludes these names, which are defined in your framework, from encryption. You can choose from the list of pre-generated framework definitions, or simply create your own one by selecting folder where framework is located.

The encoding process consists of two phases.

First phase is focused on names encrypting given in the code analysis by replacing them to their hash values. This results in situation when output code is very difficult to understand. srcProtector extract all strings from php code and encode them to make them less readable and changes whole structure of code. In this phase all comments are also removed and optionally line brakes from code. Also this first phase is truly one-way - nobody can get back your original code from the encrypted one after this phase is finished.

For your customer who receives code of your application is now nearly impossible to edit the code. The encoded code now looks like random mix of characters, which nobody can understand in fact.

Purpose of second phase is to pack whole code into eval expression and encode it with one of integrated PHP functions. This code can be by reverse engineering putted back in the state before, but it will bring for potential source-code thief much more hard work. You can use both phases and combine them to reach the optimal level of source code protection. But it is not recommended to skip the first phase - code encryption, because just encoding into eval expression is not a sufficient level of protection.

How srcProtector works is also described on the scheme below.