How does a PHP application get nulled and how to avoid it

Question

As so many others, I've been a victim of having a PHP product of mine be nulled and put available on the internet to download freely. The purpose of this question is to try to make it more difficult for someone to null an entire PHP application by understanding how it's done and other perspectives on how to avoid it as much as possible.

What I'm trying to know is how does a PHP application with the following protection strategies gets nulled. What does an attacker thinks and do when it wants to null an application:

• obfuscated code
• license key activation (delivering the rest of the code once the license is validated and successful)
• persistent internal validation: validation of auto generated files, upon finishing the app installation, containing encrypted data of the approved domain and hidden in multiple subdirectories with different filenames and extensions
• periodic external validation: periodic cURL validations to my server (hidden in multiple parts of the obfuscated core of the application) with all the common function names used to communicate with external servers also obfuscated with different encodings

I know it's impossible to build an application to be delivered to the public to be attack-proof but is there any chance to build it to be so hard to null that the job for the attacker doesn't payoff?

Answer 1

You are making the assumption that an attacker would only break the protection methods in an application for financial reasons. This isn't accurate - for a very long time, software cracking of this kind has been done for kudos, to show skills, or just for fun. Adding more layers of protection can even entice more people to try, since there is additional kudos from breaking a difficult challenge - just like people tend to be more impressed by difficult feats, such as climbing Everest, than mundane ones, such as climbing the stairs, even when the underlying action is very similar (and yes, I know that climbing Everest is difficult, but I'm making a point!).

As for different types of protection:

• obfuscated code - if I just want to run it, doesn't matter. Once I've got a copy of the code, can use it without needing to know what it actually says. If I want to modify the application, it makes things harder, since I'd need to deobfuscate it, work out what information from variable and function names was missing, then make my modifications. You can always deobfuscate code, given sufficient effort.
• license key activation - if I've got access to the full code, for example, by breaking into a server of a company who paid for it, it doesn't matter. You can track whose copy got stolen or shared, but that's a legal thing, rather than a technical thing.
• persistent internal validation - ah, now we're getting to fun things. Either I can change all the places you've embedded the domain name after reverse engineering the encryption, which sounds like a lot of effort, or I can find where you call the verification routines, and either change them to return that it is always valid, or just remove that code.
• periodic external validation - this one breaks some potential uses of the code. For example, it's reasonable to have a firewall rule preventing outbound connections on an internet facing server for the web server user - it means that if someone does break in, it's hard for them to use my server to send spam, say. Your software won't work on it though. To crack it, either deobfuscate and remove the code, or provide my own validation layer, so that users can add your server name to their hosts file, and get a response from localhost saying "valid" in whatever form you request.

Answer 2

In response to your second question

is there any chance to build it to be so hard to null that the job for the attacker doesn't payoff?

I assume by "getting nulled" you mean cracked or altered in some way that lets them use it freely.

The only really effective way is to not give all of the code/binaries. Rework your application to be client-server and only ship the client (even if the client really is a server for other stuff). Identify core functionalities, extract them to a server you manage and only sell access to it. That way, the worst they can do is pirate a useless client (well, unless your server gets hacked).

If that is undesirable, DRM schemes such as Denuvo seem to be a pretty good deterrent so far.