Has Zend Source Encryption Been Rendered Useless?

tinkertim asks: "Recently I happened upon this freelance job posting and was intrigued by the domain name suggesting Zend decoding. After looking around a bit and finding the sandbox testing, I realized this is not a gimmick. Reverse engineering used to be a service one had to look for at length, and now there's companies offering it hoping to get on the Google top 10. Obviously - they aren't afraid of lawsuits or police action. If Zend and Source Guardian are so easily broken, are PHP developers wasting their time? Should companies selling scripts just open source them now so they have some control over what seems to be the inevitable release of their code? And what happens when vulnerabilities in popular PHP based billing applications that rely on security via obscurity are found from released decoded source?"

Comments

Non-Story

[Angst Badger]

The original poster raises two questions: If the source of obfuscated PHP scripts can be recovered, should PHP script vendors just open source their products now so that they have some control over them? And what about products that depend on security through obscurity?

In the first case, vendors already have control. It's called copyright. If you misappropriate copyrighted code, there are an amazing vast number of avenues for the aggrieved party to take through a very well-developed legal system. Frequent Slashdot readers are painfully well aware of this system, both through its abuses (SCO) and its creative uses (GPL). If you're trying to conceal trade secrets, that's another matter, but then, if you're trying to conceal trade secrets, you probably aren't implementing them in PHP.

The second question has the same answer it always has: security through obscurity is weak security. Making the source available makes it easier to crack, but that's all. Inherently weak systems that try to avoid attack by concealing their weakness always fail. PHP is neither here nor there as far as that issue is concerned.

It was useless from conception

[The Wicked Priest]

Anyone who paid for this was a sucker.

However, there's no reason that "can't obfuscate" should translate into "must open-source". Yeah, you have to provide source, because it's an interpreted language. But the license is whatever you want it to be. There was a time, you know, when most programs came with source, but were under commercial licenses.

Even with compiled languages, source hiding is just lame.

No.

[cperciva]

Zend Source Encryption has not been rendered useless, because it never existed in the first place.

Zend Source Obfuscation, on the other hand, has not been rendered useless because it was already useless in the first place.

SEO?

[marcsherman]

I can't shake the feeling that this Ask Slashdot article was posted as part of the SEO contract solicited in TFJobPosting.

100% spam

[nacturation]

As someone else pointed out, it's an even bigger non-story. The freelance job posted is asking for someone to promote zendecode.com to the top of Google, MSN, etc. and posting on Slashdot certainly helps. The link to "Zen decoding" just goes to zendecode.com. The "sandbox testing" link goes to the forums on zendecode.com. And finally, the link to "popular PHP-based billing applications" just goes to modernbill.com and doesn't link to any reports of bugs. The whole thing is 100% spam backed by FUD. Whoever submitted this is trying to get the keywords "zen decoding" and "sandbox testing" ranked in search engines as being popular terms for zendecode.com. And they're perhaps trying to promote ModernBill for keywords such as "PHP billing application" as well.

Re:DRM

[SanityInAnarchy]

I actually got a response from one company, who called themselves "American Computer Systems". I followed a link from a spam, and they were actually relatively advanced -- they use JavaScript to construct your source from a very long string of alphanumeric characters. At the end, they document.write it. They show this effect off on their homepage. So, I made a textarea in the original page, swapped "document.write(foo)" for "document.(the.text.area).value = foo", then sent it all back to them. Here's the first email I sent them:

Well, that was an interesting little project. Too bad client-side JavaScript will always be vulnerable to a little tweak here and there, and you didn't even bother to crunch the HTML down ahead of time. It is nice, clean, and readable... Why is it you used to play WMA music? Ah, nevermind, wouldn't have worked, I'm on a Mac at the moment.

Really, why do you bother? All this does is provide a fun exercise for people like me. I actually automated the process, just for fun. All this does is make the page completely unreadable to people who don't have JavaScript enabled, and it makes it impossible to save bandwidth by compressing the page, as it's now encrypted. Oh, it does compress, but the compressed version of your encrypted JavaScript is twice as big as the compressed version of the original source.

Anyway, I've found the source code to your main frame, and I've attached it to this email. Now, please stop spamming me, and please find something better to do with your life. And while you're at it, you should read a bit about open source philosophy.

Now that I look at it, I can see why you'd want to keep it a secret. Looks like you're borrowing source code just like everyone else. That's not a bad thing, but everyone else isn't trying to sell a product on the idea of wanting to not share source code. Someone shared their code with you, but you don't want to share back?

Well, if you're going to be that way, I guess I won't give you the source code to the program I have which now decrypts the results of your software.

To my astonishment, I actually got a response. A response somehow defending the position of "encrypting" websites.

Hi David.

Thanks for your message. Is nice to read your opinion.You know there is always a better or faster or cheaper way.
With this program it is the same as with a car. There is no 100% protection, but it help's a lot to lock it.
By the way I dont steal code to produce my websafe. It is 100% maded here. By the way the original code is abt. the same size
as the scrambled one. We dont write code like the one you send me. He is already stripped.

I have seen that your hometown isin the east of the USA. My self I was living quit a while im Maryland. Was a good time David.
Ok I hope I'm not wasting your time.

Thanks for your message.

Erwin

ps. The wma comes back. Just a filesize problem with one of my providers.

Funny, I could swear I saw the WMA bit commented out? Ah, well, I'll give him that one, but this is too fun to stop now...

Erwin Jabor wrote:
> >
> > Hi David.
> >
> > Thanks for your message. Is nice to read your opinion.You know there is
> > always a better or faster or cheaper way.
> > With this program it is the same as with a car. There is no 100%
> > protection, but it help's a lot to lock it.

Only, in this case, I have the equivalent of a master key. You're
better off simply not putting so much value on your HTML design.

> > By the way I dont steal code to produce my websafe. It is 100% maded
> > here.

I meant the code for your website, not your software, and no, it's not.
You actually give credit to the place you got your hit counter and
other such things. I can point it out for you if you like.

The difference is, most w

ModernBill Security

[MGB-Ben]

I am one of the developers who works on ModernBill. We are very proactive about security.

We do not rely on security by obscurity on anything but the licensing. There is a difference between _using_ something and _relying upon_ it. We _rely upon_ proven, peer-reviewed, open source libraries to handle credit card encryption. We _use_ obscurity to help protect our "IP" for the same reason people use locks to protect other types of "property". To not make that distinction is polarizing the dichotomy.

Another important dichotomy is the distinction between what is possible and what is accessible. This same distinction needs to be made when arguing for the usefulness of open source. It is of course easier to have the source when you want to understand a program. What the encoder does is make the code less easy to understand. Even in decoded form, it is less easy than having the documented code. It also makes it easier to prove that we were the original author of the code.

That is also why we have unencoded source for most of the code, especially all of the business-specific and display logic that people will likely want to change. We rewrote all of ModernBill over the last year and a half for version 5, which has a front-end for the business-specific and display logic, and a back-end for the business-independent logic. The back-end is encoded to protect our copyright. There is no licensing code in the front-end.

We are active in protecting our clients' and their clients' security. We encourage the gateways we deal with to allow us to use cross-reference IDs to refer to billing account information for recurring charges, so that the billing account information does not need to be retained. We encourage our clients to use all of the security features we make available to them. We have a fraud prevention add-on (that is only an add-on because of the per-lookup charge we incur on our end), and we make it a point to explain why having lower fraud rates is better for everyone because they get better merchant account rates, and avoid chargeback fees. We rewrote the entire application for version 5.0, making many architectural changes to improve security.

For example, we don't use cookies or PHP sessions, avoiding well-known security issues involving those. We lock sessions to IPs. We use an IP whitelist, secret key, and SSL for API access. At the interface level, every hit requires a session ID to be either posted or in the URL, and an action ID determined by an unencoded file, which allows an admin to do whatever they like with the action ID lookups. I will be adding an option to have that be randomized per-session. That is all to make remote exploits more difficult just in case the worst happens and a vulnerability is found. We are not foolishly optimistic.

We have privilege separation by making it possible to separate ModernBill into 4 pieces: the back-end, and the 3 interfaces (admin, client, and order). We don't allow anything encrypted to leave the API, only enter it. All processing of encrypted data must be done by the back-end.

We deal with security issues ethically and promptly. We take security very seriously. We understand that we write billing software in PHP, and that immediately brings concern. ModernBill is not a typical PHP application. It is written in PHP due to its proliferation and portability, not because we are beginnnig programmers who don't know anything else. BTW, you can watch us at http://www.iseedevpeople.com/ when we are at the office.

Re:Doesn't Zend filter comments and rename vars?

[HappyDrgn]

Zend Encoder first obfuscates function and variable names in addition to stripping comments and whitespace as you speculate, but it also "encrypts" the files into a "binary" form. When you open a Zend Encoded file you get a bunch of text that looks like you just opened a PNG in vi. An example of two lines of PHP code encoded with Zend Encoder looks like this:

Y2\½\7v~sâù=Ãs"...p1ÅZ,á'¼¼--E"lo"ÑÌX;ë÷f(TM)yöz(r ¥Jè'&áÆÔ@`!ÀÛ¥pUÈ9¼--Y--äEdëýÉÃóEòðB>ðéjòz½Y
o©Z(ê5"*øÏÏÏÎ>:Ï7` ÛÝæt±:&UM"È÷ëåêSW¼nR éf3ýääl±±8&oe7l£0XMwév1;y|...ÊihÉfÑõùj

A Zend Encoded PHP file will not run with a standard PHP install. It requires Zend Optimizer, a free download which allows these files to run. According to the docs Zend Optimizer also makes your PHP scripts run faster, I've not really seen a difference.