At $dayjob, I recently encountered a WordPress installation that was created by some overseas developers on behalf of our client. Let’s call the client Fred. So Fred asks me to make a duplicate of his site on a subdomain so he can have some development work done without messing up the live site. That’s perfectly reasonable and ordinarily poses no problems. You just duplicate the WordPress files and database, update the configuration file, maybe fix a hard coded URL or two, and Bob’s your uncle. Alas, this time it was not that simple.Everything went as expected until I went to change the configuration to point to the new database. I opened up wp-config.php and was confronted with an impenetrable wall of PHP code, all on one line, with identifiers like “528fa54b2b” all over the place. My first thought was the site was hacked since often times back doors left by hackers look just like that. Some quick checks later, I determined that not to be the case.
Some further investigation revealed that the file had been encrypted with Sourcecop, who I will not provide a link to because nobody should be using any scheme like that to “encrypt” PHP code.
Now it makes some sense to use a scheme to obfuscate source code for something you don’t want your casual customers to stuff with. However, encoding a configuration file is just plain stupid. Yet that is what these developers did. I can only think the developers were intending to hold Fred hostage if he ever needed to change anything. In fact, I suspect the entire WordPress installation had been encrypted with this Sourcecop technology but a regular WordPress update replaced all its core files with clean ones.
Now, in Fred’s case, I was able to grab a clean wp-config.php file and configure it appropriately for the new database. Once that was done, the site was operational. However, there are other files in Fred’s site that are similarly encrypted, notably in the theme. Yup, the scumbag overseas developers are definitely trying to hold his site hostage.
All that said, nothing about the encryption on Fred’s site is Sourcecop’s fault. Sourcecop themselves had nothing to do with Fred’s predicament save for providing a broken by design source code encryption service for PHP files. The same scam could be pulled using any other source code obfuscation scheme.
I have, since, spent a grand total of 15 minutes messing with that encrypted wp-config.php file and the support file in the “scopbin” folder. Most of that time was spent formatting the code so I could trace it. I very quickly identified the code that tries to identify if you are circumventing the protection scheme (by replacing “eval” with “print” or similar). I disabled the call to that, changed the “eval” to “print”, ran the result through the php binary in command line mode, and, presto!, I had the original wp-config.php file back.
According to Sourcecop’s web site, “SourceCop is one-way encryption.” They make that statement in response to a FAQ about whether someone else with Sourcecop’s encryption tool and decrypt the file. They state that their tool only allows encryption, which I will assume is accurate. However, the claim of “one-way encryption” is demonstrably false. I don’t think they’re intentionally lying. Rather I think they’re not using the term “one-way encryption” in its usual context. I do think, however, that they are doing that deliberately to confuse the issue. Typically, “one-way encryption” means a scheme for encoding data that has no reverse process. That is, once encoded, the original data cannot be recovered at all, period. The term does not refer to the tool doing the encoding, but rather refers to the actual algorithm used.
Because Sourcecop’s encryption scheme has to be able to feed the original source code into PHP so PHP can actually execute it, any encoding scheme must, necessarily, be two-way. It must be possible to get the original source code back. If it isn’t, then the code cannot be executed. It doesn’t matter whether the encoding scheme requires extra modules or whatever added to PHP or not, it cannot be one way. In Sourcecop’s case, no extra modules or configuration is required which means that even the decryption algorithm is discoverable because the code that does the decryption has to be executable by PHP. (That’s the only benefit of an extra module or whatever. You can hide the decryption algorithm.)
Now, back the Fred’s site. The scummy developers used Sourcecop’s tool to encrypt source code on the site, including the original WordPress source files which they had no business encrypting (and doing so may have violated the WordPress license). For an average site operator, that would be enough to lock them out of their web site forever. Even most web developers these days would be stumped since most web developers these days have no idea what they’re doing beyond mixing and matching parts built by others. However, a reasonably competent PHP programmer can reverse the Sourcecop encryption in no time. The same is necessarily true for any similar tools. So if you ever find yourself in the same situation as Fred, and you think you need to go back to the original site developer for a solution and would rather not, you can relax somewhat. Just look around for a PHP programmer willing to do a bit of work to decode everything.
Update on April 12, 2017: Just today, someone apparently representing SourceCop left a comment on this post. That comment was held for approval. I chose not to approve it since it was excessively long and is mostly a sales pitch. I have, however, put up a new post which reproduces the comment and responds to it more directly than I would be able to in a comment here. That post is over here.