SourceCop Redux

Quite some time back, I mentioned SourceCop in a diatribe on source obfuscation. Today someone apparently representing SourceCop wrote a comment on that post which reads very much like a commercial for their product. I did not approve the comment because my blog is not a sales platform and also because it was quite long. I have, however, chosen to reproduce most of it here and address the points it makes. You may want to read the previous article for context.

Below is the original message with a few edits marked by brackets. My own comments are interleaved with their text. The purported author of this comment is on Gary MacDougall using a SourceCop email address. I will not provide any link back to SourceCop because I do NOT endorse their product in any way and actively discourage anyone to use it. Since the original was submitted as a public comment on my web site, I assume I have permission to reproduce it.

True, SourceCop is a relatively simple technology to encode PHP scripts so that the PHP source code is either not revealed to the user or cannot be altered.

But it's also affordable at [price redacted] and very easy to use. 

The above is clearly just a sales pitch. I suppose that’s the job of a marketer, but if you’re trying to rebut a point, a sales pitch does rather bury the lead, doesn’t it?

I read your blog piece and do agree with most of what you said. However, I disagree with your idea of "one way encryption" as being false.  In fact, it is one-way encryption because each encrypted code base is unique to the time it's encoded based on the machine that does the encoding.  That means that yes, you can figure out how to decode it (which you have) but it's not the same encoded algorithm for each encoded code base -- it's different for each.  I know that sounds like a side step, but think about the fact that if we offered a "decode" in the product, what that would mean to people who could by SourceCop and decode ANY code based that was encoded?   It would compromise the trust of the product with the customer knowing that anybody could just get a copy of the SourceCop client and decode anything out there that was encoded.

But this is a long way of saying, SourceCop is not a perfect solution -- but it's a good deterrent.

The above is a fair comment overall except for the “one-way” assertion. Yes, their product cannot be used to do the decoding, but that does not make it one-way. The actual definition of a “one-way encoding” or “one-way encryption” or “one-way function” (all of which describe the same thing) is a process that cannot be reversed by any means. Hash functions such as SHA or MD5 are one-way because you cannot take the hash and reconstruct the original through any algorithm whether you have the original encoder or not. On the other hand, SourceCop has to be able to feed the original PHP code (or at least something programmatically equivalent to it) to the PHP interpreter which means it cannot be a one-way encoding process according to the actual definition.

Basically, they’re selling an M.C. Escher style maze wall to surround your property and then putting the instructions on how pass through that knot in space-time on a little sign post at the driveway entrance. Sure, it will deter people who are just passing by and might cause an evangelist or travelling salesman or two to disappear, but anyone who really wants to will get in.

I should point out here that this “one-way” claim is the only part of their marketing on their product that I think is not kosher. Basically, they’re overselling their product by coƶpting an industry term and using it incorrectly.

With that, we do NOT condone people using SourceCop in a malicious way as you've described in your blog post or in a way to "cripple" a Website.  However, when this does happen, there's really nothing we can do to help -- we state this in our FAQ on the site.  We have however seen customers of SourceCop "lock down" parts of a site so people couldn't change it -- it's just a matter of how you set expectations with the client and what your encoding.  A good example of this is people using SourceCop to encode PHP that has passwords or sensitive data in it to hide it from prying eyes -- which in the case you described could have been the issue.  Not an excuse, just an observation.

They do get credit for this bit and, as I said in my original post, it is hardly SourceCop’s fault if a bad actor uses their technology in such a way. It’s just like how you can use PGP to encrypt planning a bank heist or for planning a surprise birthday party for your friend.

It is nice to know that they officially don’t support malicious use of their product, though. I also don’t expect them to police their customers.

We have a lot of customers over the last 10 years who like SourceCop's simplicity and what it does for the price.

The technology for most "non-programmers" works because it obfuscates the code base just enough to deter the novice from making changes, or worse, stealing their code.  SourceCop does this in a way (as you've found) to just simply make the code unreadable using well, PHP to obfuscate and PHP only.

It's by far, not a fool proof method.

More sales here. It doesn’t matter how much your customers like your product. That doesn’t magically make your “one-way” claim accurate. The next paragraph is a bit hard to parse (bad word order, I think). However, the point is valid. A novice isn’t going to have any idea what to do when faced with a wall of encoded text. They also get credit for being honest (in their FAQ) about the fact that the decoding cannot be prevented. I don’t recall if that was mentioned 18 months ago, but they do mention it now. The best part, though, is that by their own FAQ, their encoding is not one-way, even though they do not state it quite that plainly.

As you stated, we have no control over how people use the product, unfortunately.  Good will or bad will, people can do malicious things with this product if they want, we've got plenty of emails to demonstrate that.  Like most tools like this, we're not responsible for how people use it and can't be.  It's no different than someone using "rm -f -r *" on a folder then blaming Linux for having such a "complicit" way to remove all files!

How nice of them to get around to acknowledging that I was not blaming them for the nefarious use of their product. Okay, that was a bit snarky. This is my blog. I can snark if I want to!

With that said, I think it's important to explain the value of the product and what it's original intention is.

And here, we’re back to the sales pitch.

Most of our customers actually use SourceCop to deter people (passively) from taking code they wrote and either distributing it, stealing it or simply making sure that that it can't be modified. 

It's not a foolproof technology, but what encoder is?  Take solace in understanding that you (with clearly some capable PHP and programming skills) were able to decode the files and restore the PHP back to it's original state -- other encoders which use runtime libraries which need to be loaded as PHP modules through Apache will not allow for you to do this (easily).  In fact, although the other encoders are a harder to decode, they are still not infallible and can be decoded (Google around on that), but it requires some additional work and a lot of knowledge of decryption.  That might sound like a better way to approach it from a perspective of encoding, but when you have to install additional modules to get your code to run on a hosting provider, you're already asking for too much of the customer -- SourceCop is easy and simple.  With that comes some risk.

I hope I've been able to shed some light on the product.

Gary MacDougall

I don’t take issue with the fact that the SourceCop product exists. I do not endorse such products (I think using such a product is just stupid) but if you are using one and you understand its limitations, fine. I rather suspect that most users of SourceCop do not since they don’t make the possibility of decoding obvious unless you read the FAQ. I don’t know how many potential customers bother doing that, but I suspect its much lower than one would hope. Still, to be fair, they also aren’t making any particular attempt to hide the relevant FAQ, either, so there’s a large caveat emptor there.

Their point about other encoders that require environment modifications is valid, even if it is really a sales pitch in disguise. If I can put on my $dayjob hat for a moment, I can honestly say we do not permit customers to install arbitrary Apache or PHP modules on their sites, and that includes source code obfuscation support libraries.

As far as shedding light on the product goes, I don’t think I needed any shed on it. I already understood fully just what the product does and how.

Anyway, aside from redacting the price and explicitly excluding their email address and domain, I have not modified the original comment. The majority of it is a thinly disguised sales pitch which I could not allow to stand unanswered on my blog. The only real point of dialogue was the assertion that their use of “one-way” is correct. It is not. And I will stand by that assertion. That disagreement could have been addressed with a single paragraph or two in which case I would have let the comment stand as just that and replied to it.

Leave a Reply

Your email address will not be published. Required fields are marked *