In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

His encryption method - sending everything in a single string and modifying the scheme each time - uses static pairs of values (of your choosing) to "encode" the outgoing string. It actually consists of three different files: the script itself, a single-use script that makes the third file, an include file to handle the conversion back from the encoded results.

Yesterday, I released Solar 0.27.0, then quick-fixed two minor bugs and released 0.27.1 an hour later. It feels so good to be back doing releases on a monthly basis.

Some of the updates/changes in these new releases include:

• The use of spl_autolaod to load classes
• Locale functions have a new home
• a super-fast JSON encoder/decoder
• a modification to the SQL adapter for PDO
• A new bit of functionality in Solar_Url that can find the ".ext" filename extension in a URL automagically

Got an email that claimed to be from my host, it used a generic return address and talked about security upgrades and such and how due to new policy to help keep a secure data center I was required to upload and run 1 of 2 files in a zip attachment, the first was a php file the other was an asp file.

Of course, it wasn't from the host, so he investigated a little further to find out exactly what was going on with the file. Basically, it was a modified nsTView file with some added emailing and password discovery code. The code was "hidden" though - through a base64_encode call on one side and then decoded it on the other to cause the server to execute the code. He even posts and example of what the base64ed code might look like.

Jim also notes that several of the links to the sites were found in Zend's own forums (which, apparently, have been removed), and includes links to screenshots of their site...]]> Fri, 27 Jan 2006 12:49:20 -0600 http://www.phpdeveloper.org/news/4625 http://www.phpdeveloper.org/news/4625 Jim Plush's blog today, there's a new post as a follow up to his previous post concerning the Zend Encoder and some issues with sites that can decode its files.

I made a post on the Zend Forums asking for a statement on the decoding of Zend Encoded files.

Notice how there is NO MESSAGE. Why would they delete the text of my forum post? I was asking for a statement and a patch fix for a list of sites offering the decoding of encoded files. Is Zend trying to sweep this under the rug because they're looking to dump the encoder project and don't want to waste any money on fixing this issue? This doesn't look good for Zend PR.

It's definitely interesting to see that they removed the post - not just replied with a simple "We're looking into it" or "We're aware of the situation. Thank you for your input" kind of thing. Instead, they take the "what forum post?" approach. Well, Jim's posted another message that, as of the writing of this post, is still there, but unanswered...]]> Mon, 09 Jan 2006 06:37:40 -0600 http://www.phpdeveloper.org/news/4618 http://www.phpdeveloper.org/news/4618 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.]]> Fri, 06 Jan 2006 06:56:23 -0600