¿Cómo mantener la lógica del programa .NET (razonablemente) en secreto?

Question

Correcto, estoy hablando del código de validación de licencia en una aplicación de escritorio, p. un método bool ValidateLicense(string licenseCode). Por supuesto, cualquier esquema de protección puede ser modificado por ingeniería inversa por un cracker experto y determinado. Sin embargo, me gustaría evitar que cualquiera con conocimientos básicos de programación pueda usar Reflector para construir un keygen en un par de minutos.

posibles enfoques

1. Ofuscación. Según entiendo, ofuscar causa una sobrecarga de rendimiento y puede dificultar la depuración (legítima). Entonces, ¿hay herramientas que permitan ofuscar solo los métodos seleccionados?

2. Mueva el método al ensamblado ngen'ed o DLL no administrado. ¿Pero no es esto una invitación a simplemente reemplazar el DLL? Alguna idea de cómo prevenir esto (léase: hacerlo un poco más difícil para un atacante)?

3. Otro?

PS: Pregunta está obviamente relacionado con Protect .NET code from reverse engineering? tratando de poner pensamientos de allí a practicar

ACTUALIZACIÓN

a 1. Un primer paso ofuscación que seguramente sería cambiar el nombre del método de validación. (Gracias, Jonathan)

Para 2. Suponiendo que la aplicación utiliza los métodos API de Win32, podría redirigir las llamadas a través de una DLL no administrada, convirtiéndola así en una parte integral de la aplicación. Jugar con las firmas del método (por ejemplo, nombre de cambio, parámetros de intercambio) lo haría menos obvio. ¿Crees que los inconvenientes innatos están justificados?

To 3. No distribuir el método de validación pertenece aquí. Guárdelo en su servidor y llame de forma remota, es decir, use la validación en línea (Gracias, David Hedlund)

Answer 1

Eazfuscator le permitimos ofuscar su código solo en la Versión, lo estamos usando para no sentir ningún problema de rendimiento. Le permite oscurecer los métodos seleccionados también. Tenga en cuenta que los métodos públicos no pueden ofuscarse.

Cualquier función como su ValidateLicense se puede modificar fácilmente con un buen reflector de insertar un retorno verdadera como la primera línea :(Te recomiendo este articule sobre la inyección de código en asambleas: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection

Usted debe firmar los ensamblados para evitar modificaciones, pero ... La firma también se puede eliminar con las herramientas adecuadas: http://www.nirsoft.net/dot_net_tools/strong_name_remove.html

Lo sentimos, pero no hay ningún truco para evitar la ingeniería inversa en .Net, solo puede hacer las cosas más difíciles. (por ej. no nombre su función ValidateLicense y haga su lógica de validación un poco críptica)

Answer 2

Un enfoque que muchos proveedores de software han adoptado es requerir la activación en línea. De esta forma, el código de validación de clave solo se puede ejecutar en su servidor, lo que lo haría menos accesible para los posibles hackers.

Por supuesto, introduce la nueva vulnerabilidad de simplemente redirigir la llamada de validación a un servidor personalizado que envía una respuesta exitosa, si el pirata informático sabe o puede extraer información sobre cómo se espera que parezca dicha respuesta. Pero, como usted señala, siempre habrá alguien que pueda piratear su producto, por lo que aún diría que esta es una opción viable.

Answer 3

Tres posibles ataques contra la validación son

1. Sin pasar por la validación mediante la eliminación de las llamadas a la misma
2. inversa lógica de validación ingeniero para revelar los códigos legítimos
3. lógica de validación de técnicas de ingeniería inversa para permitir la condición de validación para reunido modificando entorno

Un enfoque es validar la licencia en varios puntos de la aplicación; esto ayuda a mitigar 1. La ofuscación de código ayuda a mitigar 2 y 3, pero en última instancia es un problema difícil de resolver.

Mi opinión es que una combinación de estos enfoques evitaría que los programadores básicos robaran su programa, pero de nuevo, si algo vale la pena, entonces alguien lo hará.

Answer 4

Sé que no es la respuesta, pero sugeriría usar .NET Reactor http://www.eziriz.com/ ya que tiene mecanismos para ambas licencias (con varios escenarios de licencia) y una sólida protección de código.