The Hardened-PHP Project has put out another advisory for the PHP distribution itself, versions 5.1.6/4.4.4 and below dealing with the HTML entity encoder heap.

While we were searching for a hole in htmlspecialchars() and htmlentities() to bypass the encoding of certain chars to exploit a possible eval() injection hole in another application we discovered that the implementation contains a possible bufferoverflow that can be triggered when the UTF-8 charset is selected.

The issue has been corrected in the latest PHP 5 release - version 5.2 - but is still present in the PHP 4.4 series (they have a recommended patch until the new version is posted). You can get complete information about this issue from the full vulnerability listing.

The Hardened-PHP Project has put out another advisory for the PHP distribution itself, versions 5.1.6/4.4.4 and below dealing with the HTML entity encoder heap.

While we were searching for a hole in htmlspecialchars() and htmlentities() to bypass the encoding of certain chars to exploit a possible eval() injection hole in another application we discovered that the implementation contains a possible bufferoverflow that can be triggered when the UTF-8 charset is selected.

The issue has been corrected in the latest PHP 5 release - version 5.2 - but is still present in the PHP 4.4 series (they have a recommended patch until the new version is posted). You can get complete information about this issue from the full vulnerability listing.

Alan Knowles has posted this post about some of the thinks that came from a previous post he did concerning a tool for encrypting PHP scripts. In this new post, however, he mentions something on the other side of the equation - a "PHP recovery tool".

Someone posted a comment on a post I did a while back about a product that was supposed to provide encryption on PHP scripts. (That blog post was probably my most controversial, as the author of the application send me an email asking me to contact his lawyers....)

The post this time was about another magic cure, php recovery, a new web site claiming (or appearing to) sell a product to recover php source code after it has been encrypted. Well, considering my last post, using plain old PHP methods, this is perfectly feasible. However they also claim to restore your code if it was encrypted with ioncube and Zend's encoders, which, not having tried them, but knowing the author of both products reasonably well, I have a few doubts about.

He mentions what most of the encoders on the market do to accomplish their protection (the translation into bytecodes) and what some of the potential problems with converting the bytecodes back to PHP would be. There's on piece of software he mentions ("Derick's VLD"), but that's only really useful because it dumps back the opcodes in a readable format.

Alan Knowles has posted this post about some of the thinks that came from a previous post he did concerning a tool for encrypting PHP scripts. In this new post, however, he mentions something on the other side of the equation - a "PHP recovery tool".

Someone posted a comment on a post I did a while back about a product that was supposed to provide encryption on PHP scripts. (That blog post was probably my most controversial, as the author of the application send me an email asking me to contact his lawyers....)

The post this time was about another magic cure, php recovery, a new web site claiming (or appearing to) sell a product to recover php source code after it has been encrypted. Well, considering my last post, using plain old PHP methods, this is perfectly feasible. However they also claim to restore your code if it was encrypted with ioncube and Zend's encoders, which, not having tried them, but knowing the author of both products reasonably well, I have a few doubts about.

He mentions what most of the encoders on the market do to accomplish their protection (the translation into bytecodes) and what some of the potential problems with converting the bytecodes back to PHP would be. There's on piece of software he mentions ("Derick's VLD"), but that's only really useful because it dumps back the opcodes in a readable format.

In this post from the SitePoint PHP Blog, Harry Fuecks talks about a new package of software he's worked up to make it possible for PHP to handle UTF-8 encoded strings - PHP UTF-8.

Been messing around with bits of this code for a long time, in fact since first really getting to grips with Dokuwiki, but finally got the first release out.

PHP UTF-8 is intended to make it possible to handle UTF-8 encoded strings in PHP, without requiring the mbstring extension (although it uses mbstring if it's available). In short, it provides versions of PHP's string functions (pretty much everything you'll find on this list), prefixed with utf_ and aware of UTF-8 encoding (that 1character >= 1 byte). It also gives you some tools to help check UTF-8 strings for "well formedness", strip bad sequences and some "ASCII helpers".

He continues the post, mentioning where some of the code for it was pulled from and a note about the documentation (there, but scarce). He also includes a warning for the use of it - not to use it "blindly" and only to use it when you need it, not to replace the standard PHP str_* functions.

In this post from the SitePoint PHP Blog, Harry Fuecks talks about a new package of software he's worked up to make it possible for PHP to handle UTF-8 encoded strings - PHP UTF-8.

Been messing around with bits of this code for a long time, in fact since first really getting to grips with Dokuwiki, but finally got the first release out.

PHP UTF-8 is intended to make it possible to handle UTF-8 encoded strings in PHP, without requiring the mbstring extension (although it uses mbstring if it's available). In short, it provides versions of PHP's string functions (pretty much everything you'll find on this list), prefixed with utf_ and aware of UTF-8 encoding (that 1character >= 1 byte). It also gives you some tools to help check UTF-8 strings for "well formedness", strip bad sequences and some "ASCII helpers".

He continues the post, mentioning where some of the code for it was pulled from and a note about the documentation (there, but scarce). He also includes a warning for the use of it - not to use it "blindly" and only to use it when you need it, not to replace the standard PHP str_* functions.

On his blog today, Jim Plush has a list of sites that have "popped up" to decode Zend encoded files.

I have yet to find a response by anyone from Zend on this matter but it seems sites are popping up all over the place that can decode Zend Encoded scripts. Since my company is a customer of this product and rely on this product I'm quite scared as to the slowness of Zend's response.

Some of the sites listed are:

• phpdecode.com
• phprecovery.com
• zic-recovery.com

Of course, of the ones he lists, only one might be a free service. Otherwise, the prices range widly from $15 USD all the way up to $2000 USD.

On his blog today, Jim Plush has a list of sites that have "popped up" to decode Zend encoded files.

I have yet to find a response by anyone from Zend on this matter but it seems sites are popping up all over the place that can decode Zend Encoded scripts. Since my company is a customer of this product and rely on this product I'm quite scared as to the slowness of Zend's response.

Some of the sites listed are:

• phpdecode.com
• phprecovery.com
• zic-recovery.com

Of course, of the ones he lists, only one might be a free service. Otherwise, the prices range widly from $15 USD all the way up to $2000 USD.