Many "encoders" use just pseudo-secure algorithms which packs the source code into 'eval(decode(..))' expression or require special loader or extension to run encrypted source code - on shared servers may be hard to get these loaders working. Main purpose of srcProtector is to encrypt original source code parts like variables, constants, functions, class names or strings. This process is only one-way and there is no way to get the original, even if you know the encoding function. After that your PHP applications are fully functional, but it is very difficult to change source code, or even understand it.
Also files encoded by srcProtector don`t need any loader, php extension etc. to run. The encoded project has exactly the same requirements and functionality as the original (with the exception of using gzip deflate encoding, than you need Zlib extension to be installed on server, but this is a common configuration).
You can`t use srcProtector for applications that require 'register_globals' directive. But in the most of applications this isn’t used.
Special case is the eval() function - which contains php code as string that can`t be sometimes right processed, extract() function that defines variables from the string, or some functions with callable parameter (when the parameter is not just string, but variable). This wouldn’t work right when the variables or functions (or classes) are renamed. But there is a workaround: you can exclude these parts of code that are used in these expressions to make your application working.
The analysis engine included in the application warns you, when some of these 'dangerous' codes are found and offers you a solution. You can check compatibility page for broader descriptions of source code requirements.
Yes, but if these scripts are used for inclusion in others or the others include this script, you should encode the whole project
or the rest of your project mark as framework (you can generate framework definition of files in your project on the Framework page in the application).
Otherwise scripts that includes this encoded file shouldn’t reach the encoded variables, function or class names.
Only functions, classes and constants defined in the analysed files are encoded, but there is a risk of duplicities. Variables are encoded always, therefore you can`t share variables between the scripts to keep the functionality, when you encode only some scripts of larger project and you don`t define the rest as framework (this is part of code which elements are excluded from encryption).
Generally, you should exclude these names which you want to keep in the original or these which origin from some external source.
Also you should exclude function, or variables which are called in more complex way as is shown on the example below.
First, when you call the function standard way, or like eval() or call_user_func(), it`s fine, srcProtector can handle that. But when you call the function with other function in between, this may cause some troubles. For (very simple) example:
function func(){
…
}
function call($str){
call_user_func($str);
}
call("func");
srcProtector cannot handle that, because there is a function in between and application cannot know what is string and what is call. You should function, which is here called 'func', exclude from the encryption, so you should add this function to the 'Exclude from encryption" list.
Only .Net Framework 4. If you use older OS than Windows 7 and you aren’t using automatic updates, it's possible that you will have to install .Net framework first, or you will experience some errors when you will be trying to run this application - so download .Net framework 4. Encoded scripts have no additional requirements (with only exception of Zlib extension when you use option to encode source using gzip deflate function).
You can call srcProtector.exe with 3 parameters:
Example:
srcProtector.exe "c:\path\srctest.penc" "c:\path2\project" "c:\path2\encodedproject"