Has Zend Source Encryption Been Rendered Useless? 60
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?"
Non-Story (Score:5, Insightful)
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.
Patent side effects are important here. (Score:2, Interesting)
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 clev
100% spam (Score:5, Interesting)
Re:100% spam (Score:4, Funny)
And you're helping by mentioning the aforementioned domain name four times in your post... ;-)
Re:100% spam (Score:2)
It was useless from conception (Score:5, Informative)
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.
Re:It was useless from conception (Score:1)
There was a time, you know, when most programs came with source, but were under commercial licenses.
Was that the same time barely any businesses had Internet access, let alone p2p, and security on the Internet wasn't a major concern?
Re:It was useless from conception (Score:2)
Re:It was useless from conception (Score:1)
Re:It was useless from conception (Score:2)
Re:It was useless from conception (Score:1)
Re:It was useless from conception (Score:2)
Obfuscation slows some people down, a little. For others, it merely creates an incentive to crack. Software which, otherwise, they'd have had no interest in, becomes their target, just for the challenge of it. And it ends up being circulated more widely than if there were no obfuscation in the first place.
Re:It was useless from conception (Score:1)
Well, people tried to go around the licensing back in the day, too (and succeeded, as they still do). So I still fail to see how this relates to your earlier comments.
Of course people succeeded. The relation is that some is not all. It is a valid point that it stops some people. It is the distinction between possibility and accessibility. But I see that you provide an argument against that:
Obfuscation slows some people down, a little. For others, it merely creates an incentive to crack. Software which
DRM (Score:2)
Re:DRM (Score:5, Interesting)
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:
To my astonishment, I actually got a response. A response somehow defending the position of "encrypting" websites.
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...
Re:DRM (Score:3, Informative)
Re:DRM (Score:2)
Re:DRM (Score:1)
Re:DRM (Score:2)
Re:DRM (Score:2)
Re:DRM (Score:2)
He was also either outright lying or completely clueless. I suspect the former. Again: Why even mention the east coast when it's obvious to any idiot that I'm in the midwest? He's only about a thousand miles off...
More to the point: "'Safe' your Website to the maximum possible Extend." It's usually a ludicrous claim, and it's plainly untrue -- not only is it fairly pointless, it's also easy to imagine an even more secure method
Re:DRM (Score:1)
Re:DRM (Score:2)
I know this guy had other scripts inside the page. Being able to capture the generated code exactly where I want to means I can rip off the scripts he had also "encrypted".
Re:DRM (Score:2)
javascript:void(document.oncontextmenu=null)
Re:DRM (Score:2)
Re:DRM (Score:2)
Should be "document.write('<'+'plaintext>')"
an interesting article (Score:1)
http://www.whenpenguinsattack.com/2006/07/15/prot
it talks about obfuscation as a method (rather than pure encoding).
wrong way (Score:2)
Re:wrong way (Score:1)
Re:wrong way (Score:1)
Moo
Re:wrong way (Score:1)
No. (Score:5, Funny)
Zend Source Obfuscation, on the other hand, has not been rendered useless because it was already useless in the first place.
Yes (Score:2)
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 co
Lame (Score:3, Insightful)
Re:Lame (Score:3, Informative)
This is like somebody going around selling paper-mache deadbolts and telling you about all the horrible things that can happen to your home if you don't buy one. There's an obvious level of dishonesty in selling something and calling it protection (particularly since they go so far as to call it "encryption") when it's fairly trivial to break, and won't protect you against anyone who wants to steal your stuff.
The only thing worse than the criminals themselves are t
Re:Lame (Score:2)
A person who is an accomplished lockpick can pick your average brass deadbolt in a few minutes or l
Re:Lame (Score:3, Interesting)
Except the difference here is, there are theives who would break in and steal your stuff without also knowing how to pick a deadbolt. Most people who want to steal this source code could do it easily.
What's more, automatic lockpicks don't work yet (as far as I know), nor can you easily build a robot to pick locks, run in, steal stuff, and bring it st
Re:Lame (Score:3, Insightful)
Re:Lame (Score:1)
Re:Lame (Score:2)
But yes, the point about things like locks and encrypted source only providing only limited protection is well taken.
Re:Lame (Score:2)
I think you mean Kryptonite's old cylinder key locks, and those could be opened with the end of a Bic pen's casing, not the top. And even military grade padlocks won't protect you against someone with large enough boltcutters or welding equipment. It seems rather disingenious to argue that it's merely sizzle if the protection isn't perfect against 100% of situations.
They sell the sizzle, not the steak, and I think that's what the p
Wow... (Score:3, Insightful)
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?
SEO? (Score:4, Interesting)
ModernBill Security (Score:5, Informative)
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/ [iseedevpeople.com] when we are at the office.
Re:ModernBill Security (Score:1, Insightful)
Of course you take application security seriously, would you have any customers if you didn't? I think the article submitter was implying that you obfuscated your PHP code, which doesn't enhance security in any way. The only gain for obfuscation in a commercial web app is to make it enough of a pain for average users to install the system on multiple hosts without licensing that they bite the proprietry bullet. You know it, I know it and your customers know it.
BTW: Software is covered by copyright, the auth
Re:ModernBill Security (Score:2, Informative)
Of course you take application security seriously, would you have any customers if you didn't? I think the article submitter was implying that you obfuscated your PHP code, which doesn't enhance security in any way. The only gain for obfuscation in a commercial web app is to make it enough of a pain for average users to install the system on multiple hosts without licensing that they bite the proprietry bullet. You know it, I know it and your customers know it.
I think you give the submitter too much cred
Doesn't Zend filter comments and rename vars? (Score:2)
Now, if this actually does reconstruct the ori
Re:Doesn't Zend filter comments and rename vars? (Score:5, Informative)
Y2\½\7v~sâù=Ãs"...p1ÅZ,á'¼¼--E"lo"ÑÌX;ë÷f(TM)yöz(
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.
Fool proof method discovered (Score:4, Insightful)
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.
Re:Fool proof method discovered (Score:2)
> amazing flaming shit that the Russian mafia
> is trying to steal.
That's the smartest thing I've heard another developer say in years.
I wonder why I haven't heard anyone else saying it?
Turck situtation (Score:1)
Zend Encoder (Score:3, Informative)
Re:Zend Encoder (Score:2, Informative)
My apologies, I should have hit preview first. Here is the formatted version:
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, users of the web application have no access to the PHP cod
Re:Zend Encoder (Score:2, Funny)
Re:Zend Encoder - Discounts now? (Score:2)