Projects / PHPCoder

PHPCoder

PHPCoder is a Web-based frontend to the Turck MMCache encoding functions, which are similar to the Zend Encoder product. PHPCoder enables you to encode your PHP scripts and applications into non-reversible bytecode, thus preventing users of your programs from viewing or altering the source code while having full functionality. Another excellent use for PHPCoder is to encode your applications PHP configuration files, that way someone viewing your source code does not see your databae login and password information. It also allows you to set restrictions on the encoded scripts, you can lock a script to a particular server IP address, server host name, visitor IP, or even place a time limit on the script so it will expire after a configurable amount of time. You specify Text, HTML, or PHP code that should be prepended and appended to each file before it is encoded, allowing you to easily and securely implement your own licensing scheme.

Tags
Licenses
Operating Systems
Implementation

RSS Recent releases

  •  22 Aug 2004 02:46

Release Notes: This release is updated for PHP 4.3.8 and MMCache 2.4.7, corrects errors reported by XDebug, now outputs W3C- compliant HTML/CSS, adds tool tips, adds a plain text help document, and is tested on Mozilla 1.6, Firefox 0.8, and IE 6.

  •  11 Aug 2003 16:40

Release Notes: This release adds an "ignore file extensions" option. Encoding results are now displayed above the main form. The remaining realpath() calls have been removed for maximum portability.

  •  10 Jul 2003 13:56

Release Notes: Absolute expiration date by typing in the date. Scripts can now be locked to multiple visitor IPs, server IPs, and server names. There are fixes to the coder class, better HTML and CSS, TurckLoader.so instead of mmcache.so, and improved error handling. This release verifies that subdirectories are writable.

  •  07 Jul 2003 17:53

No changes have been submitted for this release.

RSS Recent comments

13 Jul 2003 15:51 phirate

Re: Reversability

> Of course financial information should
> very rarely ever be stored on servers
> unless you have invested considerable
> effort and funds into securing a
> system(s) you should pass financial
> information directly to real time
> authorization providers.

Absolutely agreed :)

> The code itself more than likely will not be able
> to be converted back to source code but
> any program can be reversed engineered,
> simply encoding an application will not
> make it secure but it can increase
> security by leaps and bounds.

Agreed. I just felt that it was an important point to make. Many people read about Zend encoder and others and come to the conclusion that it really *is* safe. The problem with this attitude is not so much the difficulty involved in reversing the code, but the subsequent ease of distribution.

Many games for example, have found that despite advanced copy protection schemes, their software has simply been reverse-engineered (from compiled optimised code, much harder than PHP bytecode!), the protection removed, and a patch or full defanged executable made available via kazaa or usenet for the entire world to grab. If it were 2 weeks effort for each person who wanted the unprotected source that would be one thing, but it isn't, its 2 weeks work then everybody gets it.

This shouldn't prevent people from distributing their work in this way, it is handy and in a court action would likely prove due diligence (IANAL), but it is not a substitute for good relations with your clients and a competitive product which people are glad to buy.

Encoders should also beware the temptation to artificially limit the capability of their product (say, single domain or 50 users only type things) because it is that kind of limitation that makes reverse engineering the most tempting.

07 Jul 2003 20:07 jsheets

Re: Reversability

> It is important to note that this
> project, and Zend encoder and all
> equivalents that I am aware of are not
> failsafe as far as security goes. Once
> you place your code, bytecode or not, on
> someone elses system it is possible,
> with the necessary effort and skill, to
> reverse engineer the code into a form
> which can be operated on to remove time
> limits, IP address blocks, and to obtain
> passwords or other strings stored within
> the file.
>
> For the vast majority of uses the
> strength of the encoding provided is
> "good enough", however if
> you're talking about financial
> transactions, or software worth many
> thousands of dollars, you cannot trust
> this or any other encoding software to
> prevent disassembly and modification.
> Some are harder than others but in the
> end you are looking at one or two weeks
> work by someone with the necessary
> skills in order to reverse the encoding
> into something usable, even if it is not
> exactly equivalent to the original
> source (which it won't be).
>
> There are no tools that I am aware of
> available at this time to support the
> reverse engineering task, but I would
> not be surprised if they are around in
> one form or another, and conventional
> system tracing and crypto tools are
> still helpful.
>

Of course financial information should very rarely ever be stored on servers unless you have invested considerable effort and funds into securing a system(s) you should pass financial information directly to real time authorization providers. The code itself more than likely will not be able to be converted back to source code but any program can be reversed engineered, simply encoding an application will not make it secure but it can increase security by leaps and bounds.

07 Jul 2003 20:03 phirate

Reversability
It is important to note that this project, and Zend encoder and all equivalents that I am aware of are not failsafe as far as security goes. Once you place your code, bytecode or not, on someone elses system it is possible, with the necessary effort and skill, to reverse engineer the code into a form which can be operated on to remove time limits, IP address blocks, and to obtain passwords or other strings stored within the file.

For the vast majority of uses the strength of the encoding provided is "good enough", however if you're talking about financial transactions, or software worth many thousands of dollars, you cannot trust this or any other encoding software to prevent disassembly and modification. Some are harder than others but in the end you are looking at one or two weeks work by someone with the necessary skills in order to reverse the encoding into something usable, even if it is not exactly equivalent to the original source (which it won't be).

There are no tools that I am aware of available at this time to support the reverse engineering task, but I would not be surprised if they are around in one form or another, and conventional system tracing and crypto tools are still helpful.

Screenshot

Project Spotlight

RESTClient

A Java Swing application to test RESTful Web services.

Screenshot

Project Spotlight

unco

Undo any command.