Введение
Это расширение является ЭКСПЕРИМЕНТАЛЬНЫМ. Поведение этого расширения, включая имена его функций и относящуюся к нему документацию, может измениться в последующих версиях PHP без уведомления. Используйте это расширение на свой страх и риск.
Bcompiler was written for several reasons:
- To encode entire script in a proprietary PHP application
- To encode some classes and/or functions in a proprietary PHP application
- To enable the production of php-gtk applications that could be used on client desktops, without the need for a php.exe.
- To do the feasibility study for a PHP to C converter
The second of these goals is achieved using the bcompiler_write_header(), bcompiler_write_class(), bcompiler_write_footer(), bcompiler_read(), and bcompiler_load() functions. The bytecode files can be written as either uncompressed or plain. The bcompiler_load() reads a bzip compressed bytecode file, which tends to be 1/3 of the size of the original file.
To create EXE type files, bcompiler has to be used with a modified sapi file or a version of PHP which has been compiled as a shared library. In this scenario, bcompiler reads the compressed bytecode from the end of the exe file.
bcompiler can improve performance by about 30% when used with uncompressed bytecodes only. But keep in mind that uncompressed bytecode can be up to 5 times larger than the original source code. Using bytecode compression can save your space, but decompression requires much more time than parsing a source. bcompiler also does not do any bytecode optimization, this could be added in the future...
In terms of code protection, it is safe to say that it would be impossible to recreate the exact source code that it was built from, and without the accompanying source code comments. It would effectively be useless to use the bcompiler bytecodes to recreate and modify a class. However it is possible to retrieve data from a bcompiled bytecode file - so don't put your private passwords or anything in it.
Коментарии
The paragraph on code protection is somewhat misleading. While it is correct that the exact source code can not be recreated this does not offer anything in terms of code protection and lures people into a false sense of security. The same was thought of machine code until backward-engineering became so advanced that programs were "rewritten" to change the behaviour of functions or enable/disable them and the same is true for classes.
Overconfidence and "impossibilities" are what people looking for a challenge thrive on. Encryption and obfuscation are ways to make it more difficult but not impossible. As a general rule if it can be executed it can be modified so if you don't want it to be put under the microscope then don't release it in the first place.
I fully support this effort and while it is true that any released binary file can be exploited, the last comment completely misses the point. By using something like bytecode, you are making it harder for someone to see your code, and thus, are making a good faith effort to protect your IP. In a perfect world, people would not try to steal your IP or your physical property. Since people will steal your stuff, following the same logic above, the author would have us EITHER leave our keys in our car, keep our house doors unlocked, and walk down dark alleys at night OR living in a cave that we never leave.
I have many years of security experience. The common rule of thumb in encryption is to encode something past the point that normally makes it worth decrypting. NSA can break into your SSL traffic any time they want, but why bother. There is normally nothing there worth anything (to them) and they have other uses for their CPU cycles. The thing that protect the data in your SSL transaction is not the rather low-level method of encryption being used, but the sheer volume of SSL traffic that makes it doubtful anyone will even bother to decrypt it.
Some companies, like mine, need to pay their employees so we need to do the best job we can at not releasing the results of our NRE. I plan to use something like bytecode to protect our new product to reduce (not eliminate) the chance the code will be used illegally. People who are smart enough to reverse engineer bytecode, should be smart enough to read a licensing agreement and understand that a company has legal recourse for breaking it.