Additional bytecode protection
Since version 6.0 of SourceGuardian has new options for stronger bytecode protection. In addition to our standard bytecode compiling, encrypting and compressing, the new encoder can obfuscate the names of variables, functions and classes within
the bytecode to make it an unreadable value.
Additional bytecode protection may be set from levels 1 to 3. For levels 2 and 3 it will require a greater knowledge of your scripts and will require some manual intervention to exclude some variables, functions or classes from names changing - this may be necessary to ensure your application works as it should do.
If no bytecode protection level has been selected, then the encoder will work without obfuscation, but your scripts will still be compiled into bytecode, encrypted and compressed.
Levels of bytecode protection
Each level of bytecode protection includes the functionality of the previous one, but also adds more protection.
Please see the section "Bytecode Obfuscation". By default we have chosen "Bytecode with Obfuscation Level 1" but you can change it to any setting you wish.
Level 1 obfuscation - This provides name changing for local function variables. This level is safe to use as local function variables cannot be accessed externally and so may be easily renamed by SourceGuardian.
RECOMMENDATION: Use this option to quickly add additional protection when you don't want to analyze your code for adding to the exclusion lists.
Level 2 obfuscation - This level additionally changes the names of all global vars, function names and class names defined within the file.
RECOMMENDATION:
1) if register_globals is used and EGPCS vars are used directly then their names should not be changed. You need to put such global variables names into the global variables exclusion list (see below)
2) global variables accessed via the $GLOBALS array by name should keep their names and so need to be put into global vars exclusion list. By default names will be changed for all global variables and they may still be accessed correctly if within the project even if they are in different files.
3) global variables used in the project and accessed externally from other unencoded (or encoded with other options) scripts should keep their names and they should not be obfuscated so they need to be put into the global vars exclusion list.
4) possible errors could occur if a function or a class is defined in any script that is used in another script. If so put this function name or class name into the appropriate exclusion list.
Example for this level only:
a.php: <?php function myfunc() { echo 'test'; } ?>
b.php: <?php include "a.php"; myfunc(); ?>
The myfunc() function above is defined in one file and is also used in another one. To run under level 2 you need to put the "myfunc" function name in to the functions exclusion list.
Use this option for encoding separate scripts or projects which have not much code interaction between separate scripts. Each function or class defined in one script and used in another script should not change its name and so needs to be put in the exclusion list.
Level 3 obfuscation - additionally this changes the names of all functions, classes, class methods and class properties.
RECOMMENDATION:
Same as for level 2:
1) if register_globals is used and EGPCS vars is used directly then their names should not be changed. You need to put such global variables names into the global variables exclude list (see below)
2) global variables are accessed via the $GLOBALS array by name should keep their names and so to be put into global vars exclusion list.
3) global variables used in the project and accessed externally from other unencoded (or encoded with other options) scripts should keep their names so need to be put into the global vars exclusion list. By default names will be changed for all global variables and they still may be accessed OK if within the project even in different files.
New to level 3:
4) names of functions and classes defined in the extensions should not be changed and so need to be defined in the exclusion lists. ex.
mysql_connect(), mysql_select_db(), mysql_query()...(mysql),
preg_match()...(pcre), MimeMessage class (mailparse) etc.
This option will change the names for the user defined or extended functions and classes. It will not change the names for standard built-in functions such as print(), str_replace(), etc and built-in classes such as Exception, Iterator etc.
One other difference from level 2 is that as names will be changed for all functions and classes by default then there is no problem for the script to include a file from the same project and call a function defined in the included file or to create an object of the class defined there.
Example for this level only:
a.php: <?php function myfunc($arg) { return preg_match('/test/',$arg); } ?>
b.php: <?php include "a.php"; myfunc(); ?>
preg_match() is not a standard PHP function. This function is defined in separate pcre extension and so its name "preg_match" should be put into the functions exclusion list to run under level 3. Please note, there is no problem with the
myfunc() function being defined in one file and used in another one under level 3.
Use this option for encoding the whole projects which will include everything needed to run your application and which has no unencoded functions or classes. There are no problems to still have a custom settings file as such settings are usually done via assigning global vars, constants or even ini files.
RECOMMENDATION for all levels of bytecode protection; Except for level 1 the encoder does significant changes to the bytecode this creates additional protection. You should test your encoded projects well and understand the risk of this kind of additional protection that if not used correctly you may have obfuscated and unobfuscated information that will then not work well together. Analysis is definitely required for using levels 2 and 3 and this cannot be done automatically by the encoder. Therefore you need to fill in the exclusion lists for global variables, functions, classes and class properties according to your code.
Bytecode protection exclusion lists
For bytecode protection levels 2 and 3 you need to specify the names of global variables, functions, classes as well as class properties for which names should not be changed. Use Exception lists for this. As usual you can Add/Edit/Remove items.