Slashdot Mirror
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?"
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.
Proud member of the Weirdo-American community.
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.
Share and Enjoy: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Really it's the whole DRM scam all over again. You can't give someone a lock, and the key to the lock, and expect them to not be able to open it. Especially when the thing behind the lock is something that they want. And you have to give them the key, because their computer has to be able to read the files. There's a thousand sites available the will try to sell you tools to protect your precious HTML source code. That's right. HTML Source. These tools are compeletly useless, because with a quick Disable JS, Ctrl-A, Right Click, View Selection Source, you get all the HTML Source code. The disable JS being necessary because they disable the right click with JS. I wrote an email to one of these companies once asking if they knew how easy it was to bypass their tool, with exact instructions on how to do it. They never sent me a response.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
an interesting article about this can be found here:
e cting-your-php-code/
http://www.whenpenguinsattack.com/2006/07/15/prot
it talks about obfuscation as a method (rather than pure encoding).
Well, for starters, you shouldn't ever rely on "security via obscurity".
Yes, you can copyright php source code and achieve a degree of protection.
Copyright in fact originally presumed that you gave the copyright office a clear copy of what was copyrighted, so it would become public domain after a few years. The current distortion that effectively makes copyright last VERY long and that does not require deposit of whole works would tend to guarantee they would eventually disappear, rather than contributing to future utility. In computer software, ever stop to think how many clever programs no longer are available and have sources which were copyrighted but probably exist no more in complete form anywhere? How many wheels have been re-invented (and these days possibly even patented) long after the initial invention?
Technology that makes it impossible to hide sources may not affect the time of copyright, but it would help ensure that such material in some far distant future may become available. Also and more usefully it will provide evidence of inventions which may inhibit slightly the tendency of Johnny come latelies to patent things that have been invented by others long before. Registering something for copyright really ought to do that now but that is another of the areas various governments have conveniently forgotten.
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.
Tarsnap: Online backups for the truly paranoid
Nearly every scheme to interfere with reverse engineering code that runs on a machine you control, especially interpreted code, has been rendered useless. Those that haven't are only still useful because their intended use is not to prevent, but to delay.
Eventually the code must be executed and must be in a form the machine(virtual or real) can process. The code may be really hard to for humans to understand, but it won't be impossible.
At least with hardware you can add forms of protection that require complicated and expensive methods to defeat. Software just takes time.
This article should be marked troll. Door locks are there to protect you against thieves by offering a pretty good level of protection against the scum of society. Just because a small percentage of people have figured out how to pick locks, should we do as the poster suggests and simply not lock our doors because it's clearly futile? Obviously not. Things like Zend exist to offer a pretty good level of protection against those who would use the results a person or company's hard work without paying for it. Just because some people are dishonest enough to break that protection doesn't mean that the protection doesn't serve a purpose in the first place.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Front page on slashdot.. it would appear they are getting their money's worth, in that SEO posting, before that little reverse auction even closes...
I suppose a link to the site appearing on slashdot front page won't hurt the chances appearing on top of google, et al, right?
I can't shake the feeling that this Ask Slashdot article was posted as part of the SEO contract solicited in TFJobPosting.
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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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.
I'm not familiar with the Zend encoder, but I would assume that it strips out comments and changes variables to something serialized rather than descriptive. If that's the case, then this would be about the same as every "decompiler" that gets released for every programming environment at one point or another. Yes, nicely indented and spaced code is easier to read than assembly (or whatever zend encoded code is), but it's still a far cry from "open source".
Now, if this actually does reconstruct the original source files, well, then there's a serious problem.
I code the bulk of my stuff in PHP for the same reason I have no problem using HTML, XML or JavaScript: because I really, really don't think what I code is amazing flaming shit that the Russian mafia is trying to steal.
I'm still baffled by the number of people who completely lack any perspective about their own coding.
Most of this business is selling the service, not the product. There aren't many webservices that are so unique that the people involved have to specifically make an effort to control the secret sauce for fear that others will enter thir industry. Yahoo does search quite actively without having Google's code.
Only HTML "programmers" would be dumb enough to think something like PHP obfuscation was big shit.
That said, PHP obfuscation sounds like a good business. No one ever went broke selling people's asses back to them.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
The last time someone did a better job than Zend they offered him a job.
Support Eachother, Copy Dutch Property!
Earlier this year we were made aware of sites such as the ones pointed out here that offered commercial services to decript the intellectual property of others. We must stress the illegality of such services, and we will fight such efforts in all ways available to us. Let's analyze the problem. The vast majority of PHP code is deployed as a web application. In that case, no-one has access to the PHP code - only to the output of the application (the (X)HTML produced to create the dynamic webpages). The vulnerability discussed in this SlashDot thread therefore does not apply to that scenario. But the strength of PHP is driving another use of the language. More and more software vendors are creating applications that will be distributed traditionally - by download or CD, and in such cases there is a clear necessity to hide the intellectual property that went into the creation of their application. That is what our Encoder products were designed to make possible. As pointed out in this debate, any attempt to encode a language is countered by attempts to decode. There is no language that is exempt from this (Google for " decoder" if you are interested). In the case of PHP, encoders may well encrypt the language that makes up the IP in the application, but at runtime it has to be decrypted to the format that the PHP interpreter can process. Those who are smart enough to snoop into the interpreter can see the straight PHP code being executed. This is true for Zend, IonCube and all others who provide encoding solutions. The metaphore of using keys to lock your house is applicable. It will not stop the most determined thief, even if it does keep out most of them. And as thiefs become more sophisticated, we want to make our locks more robust. Zend Technologies has been pursuing an additional strategy of encoding. Today, even if the decoders manage to recreate the code encrypted by our newest product, Zend Guard 4, they will find little if anything that will be meaningful to them. The reason for that is the strong obfuscation that Zend introduced with Zend Guard 4 - it is the first product that obfuscates object oriented programs created with PHP 5.x. The decoders may be at work to figure out how to reconstruct the original code from this obfuscated code, but they should know that we'll deliver even stronger obfuscation in the 4th quarter of this year. They will have to keep investing time and money to keep up with our development cycle, not to mention figuring out how they can make a business out of this illegitimate activity. ==== When the news of the decoders broke earlier this year, we informed all our customers (and former customers) about the situation, what steps to take, and made Guard 4 available to them for free when it shipped in April. Thousands of them have upgraded and are ahead of the decoders today. Through their ongoing relationship with Zend they will stay ahead. ==== So TinkerTim has an option to release his PHP application securely - and if he was a Zend Encoder customer he would have known. If his intent is not that, but instead to promote the decoders, then our message to him is that we will make his life very difficult by continually advancing the encryption technology. Mark de Visser Zend Technologies PS - because of a trademark dispute with a European company we had to change the trademark for our product to "Zend Guard" (we combined the functionality of Zend Encoder and Zend SafeGuard Suite in this new release).
Considering that your encoder is easier to circumvent than Adobe eBook or DVD encryption, what justifies the obscene subscription price? In light of this news, the cost is absolutely ridiculous. Who cares about obfuscation if the licensing can be cracked so easily?