¿Convenciones a seguir para hacer que el software comercial sea más difícil de descifrar?

Question

¿Cuáles son algunas buenas convenciones a seguir si quiero que mi aplicación sea más difícil de descifrar?

Answer 1

Siempre que toda su aplicación sea del lado del cliente, es completamente imposible protegerla de grietas. La única forma de evitar que una aplicación se resquebraje es hacer que tenga que conectarse a un servidor para funcionar (como un juego en línea, por ejemplo).

E incluso entonces, he visto algunas grietas que simulan un servidor y envían una confirmación ficticia al programa, por lo que piensa que está hablando con un servidor legítimo real (en este caso estoy hablando de una "llamada a casa") estrategia de verificación, no un juego).

Además, tenga en cuenta que donde hay un testamento, hay una manera. Si alguien quiere tu producto mal, lo obtendrá. Y al final implementará protección que puede causar complicaciones a sus clientes honestos y simplemente se considera un desafío para los crackers.

También, vea this thread para una discusión muy detallada sobre este tema.

Answer 2

esto es casi como misión imposible, a menos que tenga muy pocos clientes.

considere: ¿alguna vez ha visto una versión de Windows que no esté rajada?

Answer 3

libro: Writing Secure Code 2

Answer 4

Hay 3 ª Parte herramientas para ofuscar su código. Visual Studio viene con uno.

PERO, primero, debes pensar seriamente por qué te molestaría. Si su aplicación es lo suficientemente buena y popular como para desear que se rompa, será, a pesar de todos sus esfuerzos.

Answer 5

Lo que ocurre con el código .NET es que es relativamente fácil realizar ingeniería inversa usando herramientas como .NET Reflector. La ofuscación del código puede ayudar, pero aún es posible funcionar.

Answer 6

Si inventa una forma de protegerlo, alguien puede inventar una forma de descifrarlo. Dedique suficiente esfuerzo para que cuando las personas lo usen de una manera "ilegal", lo sepan. La mayoría de las cosas más allá de eso corren el riesgo de ser una pérdida de tiempo; o)

Answer 7

Si desea una solución rápida (pero, por supuesto, no hay promesa de que no se rajeará, es solo una "protección"), puede buscar para algunas herramientas como Themida o Star Force. Estas son las dos cáscaras de protección famosas.

Answer 8

Es realmente imposible. Simplemente suelta un parche a menudo y luego cambia la sal en tu encriptación. Sin embargo, si su software se resquebraja, sea orgulloso, debe ser realmente bueno :-)

Answer 9

Muchas de las respuestas parecen perder el sentido de que la pregunta era cómo dificultarla, no cómo hacerla imposible.

La ofuscación es el primer paso crítico en ese proceso. Cualquier cosa más será demasiado fácil de resolver si el código no está ofuscado.

Después de eso, depende un poco de lo que intenta evitar. Instalación sin una licencia? La prueba cronometrada explotando? ¿Aumenta el uso del software (por ejemplo, en más CPU) sin pagar tarifas adicionales?

En el mundo de las máquinas virtuales de hoy en día, la estrategia a largo plazo contra la formación de grietas debe incluir algunas llamadas de hogar.El entorno es demasiado fácil de hacer prístino. Dicho esto, algunos tipos de software son inútiles si tiene que volver a un estado prístino para usarlos. Si ese es su tipo de software, entonces hay lugares bastante oscuros para poner cosas en el registro para rastrear las pruebas cronometradas. Y, en general, un esquema de clave de licencia que es difícil de falsificar.

Sin embargo, hay que tener en cuenta una cosa: no seas demasiado elegante. Muy a menudo, el esquema de licencias obtiene la menor cantidad de control de calidad, y golpea problemas serios en la producción donde los clientes legítimos quedan bloqueados. No aleje a los clientes que realmente pagan por temor a que las personas los copien, lo más probable es que no le hayan pagado ni un centavo.

Answer 10

Éstos son algunos consejos, no es perfecto, pero tal vez podría ayudar:

• actualización de su software con frecuencia
• si su software se conecta a algún servidor en algún lugar cambiar el protocolo de vez en cuando. incluso puede tener una serie de protocolos y alternar entre ellos en función de algún algoritmo
• almacenar parte de su software en un servidor que descarga cada vez que ejecuta el software
• cuando inicia su programa haga una verificación crc de su dlls que cargue, es decir, que tenga una lista de crc para los dll aprobados
• tenga un servicio que pase por alto su aplicación principal haciendo comprobaciones crc de vez en cuando y monitoreando sus otros dll's/assemblies dependientes.

Desafortunadamente cuanto más gasta en copiar y proteger su software, menos tiene que gastar en funcionalidad, todo sobre el equilibrio.

otro enfoque es vender su software barato, pero para hacer actualizaciones/actualizaciones frecuentes, baratas, de esa manera no será rentable crackear.