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?

  • Related : stackoverflow.com/questions/3550556/… Jun 8, 2016 at 15:12
  • It is pretty much impossible to make a crack-proof application if you don't control the hardware. If your app is that important then consider offering it as a service so you still keep control of the servers the code is running on. And it's not about making it not worth it for the attacker to crack your app - most of them don't do this to actually use your app (indeed it'll probably be easier to just buy it than crack it), they do it for the fun and the pride, so their cracking group is recognized as the best. Jun 8, 2016 at 15:15
  • 1
    I have not heard the term "nulled" before. Can you please explain it? Jun 8, 2016 at 16:33
  • 1
    @Dogeatcatworld that's what crackers call cracked web applications. Jun 8, 2016 at 18:19

2 Answers 2


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.

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.

  • 1
    Denuvo would be very hard to apply to an interpreted language. And even that will get cracked. The reason Denuvo (kinda) works is that it takes some time to crack it and by the time it's cracked the game is no longer popular and thus most of the people who wanted the game either already bought it or will most likely not buy it at all. For an app that doesn't really apply as you buy an app based on the needs rather than "it's a new app, I want it!" which often applies for a game (Denuvo's main market). Jun 8, 2016 at 15:18
  • @AndréBorie Oh yeah, I forgot that it was PHP, that does makes it harder to protect. I'm not aware of any actual, working public crack for Denuvo though, all the cracks I've heard about exploit weaknesses in other systems.
    – 0xFF
    Jun 8, 2016 at 15:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .