¿Cómo se anula una aplicación PHP y cómo evitarla?

Está asumiendo que un atacante solo rompería los métodos de protección en una aplicación por razones financieras. Esto no es exacto: durante mucho tiempo, este tipo de craqueo de software se ha hecho para elogios, para mostrar habilidades o simplemente por diversión. Agregar más capas de protección puede incluso atraer a más personas para que lo intenten, ya que hay felicitaciones adicionales por romper un desafío difícil, al igual que las personas tienden a sentirse más impresionadas por las hazañas difíciles, como escalar el Everest, que las mundanas, como subir las escaleras. Incluso cuando la acción subyacente es muy similar (y sí, sé que escalar el Everest es difícil, ¡pero estoy haciendo un punto!).

En cuanto a diferentes tipos de protección:

• código confuso - si solo quiero ejecutarlo, no importa. Una vez que tengo una copia del código, puedo usarlo sin necesidad de saber lo que realmente dice. Si quiero modificar la aplicación, hace las cosas más difíciles, ya que tendría que desobstruirla, averiguar qué información de los nombres de funciones y variables faltaba y luego hacer las modificaciones. Siempre puede desofigurar el código, si se realiza un esfuerzo suficiente.
• activación de la clave de licencia: si tengo acceso al código completo, por ejemplo, al ingresar a un servidor de una empresa que lo pagó, no importa. Puede rastrear qué copia fue robada o compartida, pero eso es una cosa legal, en lugar de una cosa técnica.
• validación interna persistente - ah, ahora estamos llegando a cosas divertidas. O bien puedo cambiar todos los lugares en los que ha incrustado el nombre de dominio después de aplicar ingeniería inversa al cifrado, lo que parece un gran esfuerzo, o puedo encontrar dónde llamar a las rutinas de verificación y cambiarlos para devolver que siempre es válido , o simplemente elimine ese código.
• validación externa periódica: esta rompe algunos usos potenciales del código. Por ejemplo, es razonable tener una regla de firewall que evite las conexiones salientes en un servidor con acceso a Internet para el usuario del servidor web; esto significa que si alguien se interrumpe, es difícil para ellos usar mi servidor para enviar correo no deseado, por ejemplo. Sin embargo, su software no funcionará en él. Para descifrarlo, desobduzca y elimine el código, o proporcione mi propia capa de validación, para que los usuarios puedan agregar el nombre de su servidor a su archivo de hosts y obtener una respuesta de localhost diciendo "válido" en cualquier forma que solicite.

En respuesta a tu segunda pregunta

  

hay alguna posibilidad de construirlo para que sea tan difícil de anular que el trabajo para   ¿El atacante no da resultado?

Supongo que al "anularse" te refieres a agrietado o alterado de alguna manera que les permita usarlo libremente.

La única forma realmente efectiva es no dar todos los códigos / binarios. Rediseñe su aplicación para que sea cliente-servidor y solo envíe el cliente (incluso si el cliente realmente es un servidor para otras cosas). Identifique las funcionalidades principales, extráigalas a un servidor que administre y solo venda el acceso. De esa manera, lo peor que pueden hacer es piratear a un cliente inútil (bueno, a menos que su servidor sea hackeado).

Si eso no es deseable, los esquemas DRM como Denuvo parecen ser un buen elemento de disuasión hasta el momento.