Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Has Zend Source Encryption Been Rendered Useless?

Cliff posted more than 8 years ago | from the decompilers-ain't-nothing-new dept.

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?"

cancel ×

60 comments

Sorry! There are no comments related to the filter you selected.

Non-Story (5, Insightful)

Angst Badger (8636) | more than 8 years ago | (#15726568)

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.

Patent side effects are important here. (2, Interesting)

Anonymous Coward | more than 8 years ago | (#15726613)

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.

100% spam (5, Interesting)

nacturation (646836) | more than 8 years ago | (#15726928)

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:100% spam (3, Funny)

rk (6314) | more than 8 years ago | (#15727039)

And you're helping by mentioning the aforementioned domain name four times in your post... ;-)

Re:100% spam (1)

foniksonik (573572) | more than 8 years ago | (#15727247)

Google themselves used to advertise (maybe they still do) job listings for people to write "Provocative Text for Advertising Placement and Marketing". It looks like our friends at OSTG may have a similar position.... whose sole job is to rewrite summaries to include SEO links to paying customers??? I'm sure I've seen ads for that freelancer site on here before and wouldn't be surprise to see the others as advertisers... though because they don't have a familiar brand... going with an inline text link is probably a great strategy.

Re:100% spam (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15727783)

Then maybe I should fight back and promote IntraISP [intraisp.com] as PHP billing software.

Disclaimer: I work there. It pays my paychecks. I'm in it for the money.

Re:100% spam (0)

Anonymous Coward | more than 8 years ago | (#15742007)

Man, you're right, everything makes sense!

Shame on me for thinking the poster was an idiot...

It was useless from conception (4, Informative)

The Wicked Priest (632846) | more than 8 years ago | (#15726575)

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.

Re:It was useless from conception (1)

MGB-Ben (989133) | more than 8 years ago | (#15729233)

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 (1)

The Wicked Priest (632846) | more than 8 years ago | (#15729402)

Indeed it was! So, are you seriously maintaining that obfuscated source is a security feature? LOL.

Re:It was useless from conception (1)

MGB-Ben (989133) | more than 8 years ago | (#15729826)

No. I am not. It is an obfuscation feature. I was just pointing out the speciousness of your argument. And indeed, it is no surprise that your next argument was a straw-man.

Re:It was useless from conception (1)

The Wicked Priest (632846) | more than 8 years ago | (#15729879)

It was a question, really, not an argument. My point was that I fail to see your point. It was a different era... but obfuscated/hidden source isn't any more useful now than it was then. If you think it is, then please explain how. I interpreted your remarks as best I could; maybe it's not what you were trying to get at, but I wasn't setting up a straw man.

Re:It was useless from conception (1)

MGB-Ben (989133) | more than 8 years ago | (#15729927)

The point was _not_ that it _is_ any _more_ useful. The point was that it _is not_ any _less_ useful because of your argument. Personally, I would prefer the source to be available, but there are very valid reasons, like the fact that we know that many people actively try to go around the licensing, but are not competent enough to figure out how, like the people who try to work around the system by using a 1 month for 50 cents coupon over and over again, even though the license does not allow it. Because of the obfuscation, we can catch people like that.

Re:It was useless from conception (1)

The Wicked Priest (632846) | more than 8 years ago | (#15729977)

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.

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 (1)

MGB-Ben (989133) | more than 8 years ago | (#15730141)

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, 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.

That is a pretty good argument against a lot of cases, but there is a big difference between trusting encoded code given to them by us, and cracked code. Sure, for a photoshop desktop, one can just wipe their install and start fresh if the cracked version causes problems. But for software that runs your business, and handles your billing, no one in their right mind would use cracked software.

DRM (1)

CastrTroy (595695) | more than 8 years ago | (#15726581)

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.

Re:DRM (4, Interesting)

SanityInAnarchy (655584) | more than 8 years ago | (#15727011)

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 web designers don't have this concept of
"stealing" HTML code. After all, it's not as if you lose the code from
your own site if someone else "steals" it. In fact, maybe they improved
it, and you find their code on their website and "steal" it back. This
is how real progress is made.

Oh, and have you read about open source code and free software?

> > By the way the original code is abt. the same size
> > as the scrambled one.

Yes, it is... if you're not doing compression. You do know about gzip
compression, right? My web server compresses the HTML before it sends
it, if the browser supports decompression. And the original code
compresses better than the scrambled code, resulting in about half the
amount of data actually sent over the network.

By the way, this will always be true -- encrypted data doesn't compress
well. That's why, when using things like SSL for encryption, it's a
good idea to compress the data first, and then encrypt it. But
including a way to decompress your data in JavaScript would probably
make it much bigger than you would save on the script itself.

> > We dont write code like the one you send me. He is
> > already stripped.

The code I sent you is exactly the same as the code on your website,
except I... er... descrambled it.

> > I have seen that your hometown isin the east of the USA.

Midwest, actually. Nowhere near Maryland.

> > My self I was
> > living quit a while im Maryland. Was a good time David.
> > Ok I hope I'm not wasting your time.

Nono, not anymore. This is highly amusing.

The funny thing is, you could do much more to "protect" your HTML code (if you care) by running HTML, JavaScript, and CSS separately through obfuscators which strip them of all meaningless whitespace and comments. It would be insanely easy to write. And still, all it would mean is that people would have to run the code through a pretty-printer to be able to read it.

But at least that would remove comments. Their page was actually 100% intact, comments and all. I can't find it now, though, been Googling for a bit because I wanted to link to it. Maybe if I look in my deleted spam... Aha! There it is. But it proves another point -- all the keywords on the page, including the meta information, was entirely obfuscated -- I don't know why they bothered with metas -- easy enough for me to decrypt, but Google won't do it automatically (AJAX sites take note!), so, if you're so inclined, check them out here [websafe-acs.com] . The site appears unchanged, so you can decode it for yourself if you like, and see all the stuff they rip off -- as much as they try to prevent you from ripping their stuff off.

I guess they were hoping frames would do something? Hah!

Although, I admit the disabling of right-click stalled me for awhile. Eventually I simply read the source of the master frame, loaded up the child frame, and read the source of that. Again, I laugh at using frames to "protect" anything.

Ordinarily I would hide Erwin Jabor's name and email address [mailto] (acs9999@yahoo.co.uk), but charging $39.95 for this service is already a scam, and he put the nail in the coffin by making false claims like "The code has already been stripped" -- yeah, bullshit, unless that's retardo-Indian-English for "The code has already been 'scrambled'." I attached his source code, so he should know he can't pull that on me, no "stripped" code would include the full comments and whitespace -- unless he really has no clue how it works.

And then he tries to get chummy with me by saying "I see you live on the east coast"... WTF? Even if he was looking at server logs or ran some sort of GeoIP search on my domain name, it should be obvious where my ISP is -- even Adult Friend Finder knows the city I live in. Midwest, as I said -- you know my email address, look it up if you like. Yeah, he's only off by 998 miles. Jackass.

People, always assume that ANY source code you send to the client is already stolen. If you must "protect" it, use Java. Similarly, on the server side, either sell your PHP program as a service (which you run on your servers and jealously guard) or don't use PHP. You can still use LAMP -- use mod_python and python bytecode, or one of the mod_parrot or mod_mono languages, or even a real Java or .NET server.

But please, please, please don't try to "encrypt" source code in such a way that it's still evaluated as source code. No, not even Perl. It just makes you look retarded. Especially perl.

Re:DRM (2, Informative)

Mprx (82435) | more than 8 years ago | (#15727254)

Using Firefox there's a much easier way: select all, view selection source. Decrypted HTML is shown. This works for any HTML "encryption" method.

Re:DRM (1)

SanityInAnarchy (655584) | more than 8 years ago | (#15728685)

Dosen't work when they disable right-click, and the bookmarklets for re-enabling it don't work with frames. Might have made it easier once I got around the frameset, though.

Re:DRM (1)

Mprx (82435) | more than 8 years ago | (#15729096)

Just turn off Javascript after the page has loaded. Disabling right-click is a even more trivial "protection".

Re:DRM (1)

Bert64 (520050) | more than 8 years ago | (#15727397)

Wow! now i can protect my site from "prying ices" too!

Re:DRM (1)

NemosomeN (670035) | more than 8 years ago | (#15728023)

Actually, he seemed to have been very nice, and you were being a bit assy. He's offering his service, probably geared toward personal websites (Think one step above MySpace) of people who get pissed when people steal their layouts. The vast majority of people cannot handle more than view source/copy/paste. Yeah, it's stupid, but hey, let him have his stupid business. He probably got scammed by the spammers anyway (Look into the spamming business, most of the places they are advertising for are being bilked/lied to). My CAPTCHA was "stolen".

Re:DRM (1)

SanityInAnarchy (655584) | more than 8 years ago | (#15728994)

Actually, he seemed to have been very nice, and you were being a bit assy.

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 -- simply distribute your site as a bunch of small-ish images spliced together by a table layout, and block right-clicking -- even if they do manage to duplicate it entirely, they won't be able to steal your layout and design easily. If they do, there will probably be watermarks all over it (so you can sue them), and it forces them to use Photoshop or something similar, making it a lot more effort to make it work successfully than just "view generated source" or modifying a single line of JavaScript.

Another possibility would be to do the entire thing in Java or Flash, not JavaScript. Java, especially -- decompiling and figuring out where the text is to be replaced -- or the url that fetches the text -- could certainly be a lot more effort than either the above JavaScript hack or photoshopping. They're also less efficient -- a Java app can take awhile to start, Flash is slow, both can be uglier and less flexible, and images are even slower, and none of them can be indexed by Google. But that's basically what he's doing -- making tradeoffs that really are unacceptible (load time, searchability, bandwidth) to add a barrier to would-be theives that's a bit less like Severe Tire Damage and more like a bump -- nay, a pebble in the road.

I thought those up as fast as I could type them. Either I'm really just that smart, or these ideas are so blatantly obvious that this guy must have thought of them also -- meaning he knew what he was doing when he said "safe to the max". He certainly knew when I decrypted his page and sent it back to him that his "crypto" was no good. My guess is that he didn't do any of the above because he realized they would be a bit more obviously bad for your website (visibly slow loading times) and they'd also be much more work for him.

He's offering his service, probably geared toward personal websites (Think one step above MySpace) of people who get pissed when people steal their layouts.

Keep in mind, he's charging almost $40 for a service which may stop the "one step above MySpace" ripoffs -- maybe. The downside? You pay $40 for something that problably took 10 minutes to write, your website is completely un-indexable by search engines (thus you move from "one step above MySPace" to one step below MySpace), it wastes bandwidth (mod_gzip, mod_deflate), it requires JavaScript and has no fallback for anyone without it, it disables right-click (annoying to someone wanting to, say, copy and paste his email address into a webmail -- of course, not immune to even the simplest attack) and it adds to the page load time -- not significant, but your grandmother on a Pentium 1 on dialup will definitely notice the lack of compression AND the need for JavaScript. The grandmother-on-dialup or ghetto-friend-on-dialup is certainly an important factor for the just-above-MySpace crowd.

And, as others have shown, Firefox can probably beat this automatically. It relies on being low-profile -- if it ever did become particularly popular, I could write a bookmarklet that would expose the source. If he could sell his "encryption", I could probably sell "decryption". I'm too ethical to do that, but there are plenty of smart, unethical people out there.

In other words, it's all downside, no upside. And that's just from what I've observed -- I imagine it would cause problems for anyone trying to create a dynamic site. I can't prove that, of course -- if he were to implement it as a proxy, it would work easy on any page. But the fact that the download comes in an EXE file does suggest that this is intended to work on static HTML files, before they even get to a server.

I mean, for $40, I'd expect him to at least be able to spell "eyes". I doubt anyone actually falls for it, though, so I doubt I'm hurting him that much by posting here.

For comparison, $40 could be 4 months of web hosting for a site that size. Or say you up the price just a bit -- Apple's iLife costs $79, and includes iWeb, probably a much more useful tool for developing web sites -- and four other programs, meaning if they're of equal value, iWeb only costs $16. iWork is also $79. And before I sound like too much of an Apple shill, there are many more tools you can get for free that will add much more value to your web site than "encryption". Take WordPress -- let them try to rip off your layout, you got it for free from the community, and people like your website for content.

In other words, while I can imagine this guy being decent, he is, knowingly or not, ripping people off.

He probably got scammed by the spammers anyway (Look into the spamming business, most of the places they are advertising for are being bilked/lied to).

And if he takes the same amount of care in creating this software he's selling as he does in researching his marketing options...

Besides, let me clear that up a bit. Here's the original spam:

Dear Sir/Madam.
We like to introduce to you the revolutionary new Websafe Tools.
Now you can afford to hide your HTML-Website for Code-Thief's.
American Computer Systems give you the Tools. Thanks to Java-Script
Technology. Your website will be safe to the maximum possible extend.
No code stealing anymore, because the code is for a human been unreadable.

For more information please look to our website: http://www.websafe-acs.com/

Truly yours,

The Team of American Computer Systems.

Remarks: This is a one shot mail. You cannot answer to this. Please use : http://www.websafe-acs.com/

Really, tell me he didn't write that. He knew he was spamming.

In fact, the Received header (on my server, so I know it wasn't forged) shows the same ip address (124.106.220.203) both times. First time, X-Mailer was The Bat!, a client I've found in a couple of other spams. Second time, it was Outlook Express. Putting it together, this means it was probably the same guy -- probably uses Outlook Express for personal email, and The Bat! to send his spams. Unfortunately, my server didn't resolve that, and it's been awhile, but it now resolves to 124.106.220.203.pldt.net. Unfortunately, I can't find much more information about pldt.net, as www.pldt.net resolves to 192.168.254.1, which is by definition unroutable -- someone ISP is trying to host a website from behind a NAT router, I'd guess. A Google search on "pldt" shows most results for the Phillipines Long-Distance Telephone company -- gee, what a surprise, given the guy's broken English, spamming habits, and shoddy software.

To be fair, I've gotten that message exactly once, which puts him miles above most spammers. But really, spam is spam. There are much better ways of advertising.

Aside from that, it's also got more lies. "You cannot answer to this." Riight. That would explain why both "from" and "reply-to" point to the same address listed on the site. You'd think it would be in his best interest to let people reply to it...

Re:DRM (1)

rjhubs (929158) | more than 8 years ago | (#15786977)

You sir, are incapable of writing short comments.

Re:DRM (0)

Anonymous Coward | more than 8 years ago | (#15728066)

Well there's actually a much easier way to do it if you're using Firefox.

First, you'd usually have configured your firefox to disable all the JS crapnoyances such as disabling right-click (Tools -> Options -> Content -> Activate Javascript -> Advanced -> Uncheck everything), so you can just right-click the page and select "This Frame -> Show only this frame" (or something like that, i'm on a localized Fx right now).

Then, either you have installed the Web Developer Toolbar and select "Show Generated Source" or you select all (CTRL+A) and then right click on the page and "Show selection source code", which gives you the generated source code.

Tada, you're done.

Re:DRM (1)

SanityInAnarchy (655584) | more than 8 years ago | (#15728708)

Does this show me what happens with this line: document.write('<scr'+'ipt>document.write("hi")</s cr'+'ipt>');

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 (1)

soliptic (665417) | more than 8 years ago | (#15728244)

Although, I admit the disabling of right-click stalled me for awhile.
Add this as a bookmarklet:

javascript:void(document.oncontextmenu=null)

Re:DRM (1)

Ant P. (974313) | more than 8 years ago | (#15773154)

I like using the method of having a document.write(''); before the normal "encrypted" output. It does exactly what it says, and works in IE/Firefox. Of course it shouldn't but it's nice to have around sometimes.

Re:DRM (1)

Ant P. (974313) | more than 8 years ago | (#15773160)

Stupid HTML filter...

Should be "document.write('<'+'plaintext>')"

wrong way (1)

Beuno (740018) | more than 8 years ago | (#15726592)

Well, for starters, you shouldn't ever rely on "security via obscurity".

Re:wrong way (1)

m1ndrape (971736) | more than 8 years ago | (#15727886)

vs lbh oernx guvf rapelcgvba v'z tbvat gb fhr lbh jvgu zl fhcre QZPN pbj cbjref!

Re:wrong way (1)

RobertLTux (260313) | more than 8 years ago | (#15728428)

umm since you "stole" your method from Caesar it just happens to be one of the methods that is just a few clicks from being decoded via LeetKey

Moo

Re:wrong way (1)

m1ndrape (971736) | more than 8 years ago | (#15728448)

hey it worked for adobe why can't it work for me!

No. (5, Funny)

cperciva (102828) | more than 8 years ago | (#15726631)

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.

Yes (1)

Zerth (26112) | more than 8 years ago | (#15726654)

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.

Lame (2, Insightful)

nacturation (646836) | more than 8 years ago | (#15726695)

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.
 

Re:Lame (2, Informative)

Kadin2048 (468275) | more than 8 years ago | (#15726779)

Except that this isn't much of a door lock.

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 the charlatans who try to foist snake-oil "protection" schemes on unwitting consumers and companies.

Re:Lame (1)

nacturation (646836) | more than 8 years ago | (#15726835)

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.

A person who is an accomplished lockpick can pick your average brass deadbolt in a few minutes or less... so to them, every lock is effectively papier mache. However, your comment about encryption is accurate as it's simply a form of good enough protection for most.
 

Re:Lame (2, Interesting)

SanityInAnarchy (655584) | more than 8 years ago | (#15727033)

A person who is an accomplished lockpick can pick your average brass deadbolt in a few minutes or less... so to them, every lock is effectively papier mache.

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 straight to the pawnshop. This kind of thing is easily possible with this kind of "encryption" (sorry, "protection") -- I can certainly automate the process of Googling for code that looks like it was "protected" this way, "decrypt" it, and email the results to me, figuring that anyone using this probably has something to hide in their PHP -- maybe a vulnerability, even.

In any case, would you feel as confident about this if someone really was selling paper-mache deadbolts? If it really is just a question of magnitude, remember, someone still might be able to decompile code fairly quickly (and crack it to do things it tries to prevent, like making a game run without the CD). Compiling, even just to bytecode (and you can do that with some variants of PHP), is more like a real deadbolt. "Encrypting" is paper-mache, and I don't see how it's even "good enough for most".

Ah, well, at least this is better than the HTML "encryption", which seriously damages the usability of your site, without even slowing down a "hacker" wanting to "steal" your code -- not that you should care about this in HTML, anyway.

Re:Lame (2, Insightful)

senzafine (630873) | more than 8 years ago | (#15726818)

I agree completely. For the most part...even if you don't have the source it only takes a decent programmer to "reverse engineer" the application into code. Zend's encoder serves a purpose...but one of them isn't "make your code impossible for anyone to decode".

Re:Lame (1)

rlanctot (310750) | more than 8 years ago | (#15726820)

Actually, most door locks provide you with the ILLUSION of pretty good protection from thieves. Just look at the combination lock, it can be cracked open with a bic pen top. They sell the sizzle, not the steak, and I think that's what the point of the article was.

Re:Lame (1)

dougmc (70836) | more than 8 years ago | (#15726862)

Just look at the combination lock, it can be cracked open with a bic pen top.
Close, but no cigar. It was a kryptonite [engadget.com] lock, with one of those round keys.

But yes, the point about things like locks and encrypted source only providing only limited protection is well taken.

Re:Lame (1)

nacturation (646836) | more than 8 years ago | (#15726885)

Just look at the combination lock, it can be cracked open with a bic pen top.

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 point of the article was.

Did we read different Slashdot stories? Whoever posted this one asked if all applications should be open sourced given that the protection offered isn't perfect -- that was the point. The point wasn't to argue that Zend shouldn't overstate how much mitigation their solution provides against attack, but rather to use this as a rather bizarre line of reasoning to argue in favor of open sourcing everything as a means to eliminate all bugs and just accept the inevitable. So because some people are able to extract the source code from a Zend-encoded PHP app, companies should forego making revenue from their PHP apps and just open source it all and hope to make it up elsewhere? That's about the dumbest thing I've ever heard.
 

Wow... (3, Insightful)

mysidia (191772) | more than 8 years ago | (#15726747)

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? (4, Interesting)

marcsherman (300604) | more than 8 years ago | (#15726762)

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

ModernBill Security (5, Informative)

MGB-Ben (989133) | more than 8 years ago | (#15727034)

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/ [iseedevpeople.com] when we are at the office.

Re:ModernBill Security (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15727296)

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 authors or there employers hold the copyright on their work. Anybody who talks about protecting 'IP' is obfuscating the issue as 'Intellectual Property' implies ownership and you don't 'own' a copyright, you 'hold' or are assigned a copyright.

Re:ModernBill Security (2, Informative)

MGB-Ben (989133) | more than 8 years ago | (#15728421)

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 credit. Why then would they single out billing software, using the word "rely", and not mention licensing at all? To the submitter, it was all about advocating open source by showing the weekness in encoding, appealing to the security sense of the _users_. That implies that their legitimate use of the software is harmed by the decoding, which implies, just as they said, that we "rely" on it for application security. Otherwise, the argument wouldn't make sense.

The alternative interpretation that you provide is counter to the submitter's argument. If the encoder prevents illegitimate uses, like someone using it to run their multi-million-dollar business for nothing, then it is obviously not useless. We never claim that the encoding is for anything other than preventing illegitimate uses, and is for _our_ benefit. That is the whole point.

BTW: Software is covered by copyright, the authors or there employers hold the copyright on their work. Anybody who talks about protecting 'IP' is obfuscating the issue as 'Intellectual Property' implies ownership and you don't 'own' a copyright, you 'hold' or are assigned a copyright.

All forms of property are imaginary, legal constructs, anyway. Informal language is defined by usage. One could argue the same thing about any form of property, saying that ownership is merely holding the object, and many people actually make that argument, which is actually wrong. The use of the word "hold" also has misleading connotations, but just in a different way. It omits the legal assignment aspect, which you mentioned yourself. At any rate, any of those uses are perfectly valid common usages unless you are in a philosophical debate over the semantics, which we are not.

Anyway, the only clients who say anything about the encoded source issue are the ones who are technically competent enough that they have NDAs with us, and we work with them directly on any issues they have, so they often see the source anyway. We are very open to working with and trusting our legit clients.

We are not some megacorp looking for any way we can screw over our clients. We are a very ethically-minded small business, and we all work hard for reasonable compensation, even the owners. I am a Green Party member who boycotts Wal-Mart, and I can still say that, so it must be true. ;)

Doesn't Zend filter comments and rename vars? (1)

WoTG (610710) | more than 8 years ago | (#15727166)

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.

Re:Doesn't Zend filter comments and rename vars? (5, Informative)

HappyDrgn (142428) | more than 8 years ago | (#15727244)

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.

Fool proof method discovered (3, Insightful)

SlappyBastard (961143) | more than 8 years ago | (#15727754)

Learn C++. Shhh... don't tell anyone. They're still trying to figure out where the compiler is on their Linux server.

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 (1)

CDarklock (869868) | more than 8 years ago | (#15747115)

> I really, really don't think what I code is
> 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 (1)

Skinkie (815924) | more than 8 years ago | (#15729445)

The last time someone did a better job than Zend they offered him a job.

Zend Encoder (3, Informative)

MarkAtZend (989268) | more than 8 years ago | (#15731303)

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).

Re:Zend Encoder (2, Informative)

MarkAtZend (989268) | more than 8 years ago | (#15731364)

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 code - only to the output of these applications (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 "[your language] 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 to 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 legal dispute with a European company we had to discontinue the trademark "Zend SafeGuard", and replaced that with "Zend Guard" (we combined the functionality of Zend Encoder and Zend SafeGuard Suite in this new release).

Re:Zend Encoder (0)

Anonymous Coward | more than 8 years ago | (#15747026)

Your business must be pretty lucrative to keep fighting such an obviously losing battle.

My employer is a customer of yours (that decision was made before I was hired...). Hopefully, at least, this article and the associate comments and links will finally convince them what a foolish waste of money your product is.

Re:Zend Encoder (2, Funny)

Anonymous Coward | more than 8 years ago | (#15734903)

So, trying to obfuscate your posts, too, by eliminating whitespace?

Re:Zend Encoder - Discounts now? (1)

pestilence669 (823950) | more than 8 years ago | (#15752967)

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?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>