Applies to:
Zend Guard
Security
Summary
People are often concerned about various technologies that exist that claim to reverse the protection provided by Zend Guard. We thought it was important to address it here.
Zend Guard provides some of the best technology available to protect applications from reverse engineering but Zend has never claimed that Zend Guard is impervious to reverse engineering. Given enough time and a determined hacker, any encoding technology can be broken. This has been true since the first hacker decompiled binary machine code.
Technical Aspects
The first level of protection is encoding. During encoding the PHP source code is converted to a binary format that is used at runtime by the PHP engine in conjunction with Zend Loader. Only the encoded files are deployed and your original source code remains secured which prevents your application from being read by the casual observer. Unfortunately technologies do exist that will allow encoded files to be decoded. Due to the open source nature of PHP there is virtually no way to prevent a person from hacking at the PHP engine code to intercept the bytecode after it has been decoded for execution.
The second level of protection is obfuscation. During obfuscation the encoded files are further processed to obscure the names of classes, methods, variables and other items in the code. Obfuscation of names cannot be automatically reversed without a key that only exists on your system. However, it is still possible from someone willing to spend enough time to figure out what is going. It's a lot harder with variable names like XsddR2245as and class names like wwEgg33k55jsc but it is not impossible.
The last protection feature is licensing, although it does not touch or alter the PHP source or entities, but rather limits execution to bind with a license file, signing the PHP scripts according to a specific product name, which also appears in the license file. It makes another level, or layer of code protection, by making sure that whomever for a specific application and license from a specific software vendor, would be able to run the protected application. This reduces the number of random people who can run your code and try to hack into it's source, since you normally know exactly who gets a license to your application, and can limit its expiration and other aspects, such as IP or Host Id for example.
Conclusion
So while Zend Guard can make the job of someone wanting to steal your code/IP harder, ultimately your protection has to be provided by your end user license agreement (EULA) and whatever remedies it provides for you and your customers in the event of a legal dispute.
Despite the above disclaimer, to this point there is no evidence of decoding, or resurrecting encoded + obfuscated PHP code generated by Zend Guard since version 5 (which introduced Syntax Obfuscation), and your best approach would be to follow all security features within the encoder / Guard project to apply:
- Obfuscating all levels - from Classes to Properties
- Removing PHPDOC if not used within reflection or auto loaders
- Work only with encoded files - checked
- Encapsulating PHP code within functions (and classes) - never in main PHP script level
- Licensing - makes sure that your application will only be executed on authorised / licensed PHP runtime.
- Code expiration - although this comes against many software policies which provides perpetual licenses, it can help to expire the files somewhere in the future which is practically beyond a specific version or branch end of life period. Once the PHP application expires, you make sure the client approaches the software vendor to acquire a new version, which is not only better in quality and modern, but also might facilitate newer security features which were not available in the original application version lifetime.
This text was updated by Zend Global Support on March 2nd, 2016, with reference to the Guard implemented security features and known decoding tools.
Comments