¿Cómo generar y validar una clave de licencia de software?


236

Actualmente estoy involucrado en el desarrollo de un producto (desarrollado en C #) que estará disponible para descargar e instalar de forma gratuita pero en una versión muy limitada. Para obtener acceso a todas las funciones, el usuario debe pagar una tarifa de licencia y recibir una clave. Esa clave se ingresará en la aplicación para "desbloquear" la versión completa.

Como usar una clave de licencia como esa es algo habitual, me pregunto:

  1. ¿Cómo se resuelve eso generalmente?
  2. ¿Cómo puedo generar la clave y cómo la aplicación puede validarla?
  3. ¿Cómo puedo evitar que una clave se publique en Internet y sea utilizada por otros que no hayan pagado la licencia (una clave que básicamente no es "suya")?

Supongo que también debería vincular la clave a la versión de la aplicación de alguna manera para que sea posible cobrar por las nuevas claves en las versiones de funciones.

¿Algo más en lo que deba pensar en este escenario?

Respuestas:


127

Advertencia: no puede evitar que los usuarios pirateen, pero solo facilita que los usuarios honestos hagan lo correcto.

Suponiendo que no desea hacer una compilación especial para cada usuario, entonces:

  • Generarse una clave secreta para el producto.
  • Toma el nombre del usuario
  • Concatene el nombre de usuario y la clave secreta y el hash con (por ejemplo) SHA1
  • Desempaquete el hash SHA1 como una cadena alfanumérica. Esta es la "clave de producto" del usuario individual
  • Dentro del programa, haga el mismo hash y compárelo con la clave del producto. Si es igual, está bien.

Pero, repito: esto no evitará la piratería


Recientemente leí que este enfoque no es criptográficamente muy sólido. Pero esta solución ya es débil ( ya que el software en sí tiene que incluir la clave secreta en alguna parte ), por lo que no creo que este descubrimiento invalide la solución en la medida de lo posible.

Sin embargo, pensé que realmente debería mencionar esto; si planea derivar algo más de esto, tenga cuidado.


13
si el programa incluye la clave secreta (como se indica en los pasos anteriores), descifrarlo es trivial
Steven A. Lowe

2
editado para ser más obvio; no puede sobre enfatizar algo tan fundamental ;-)
Steven A. Lowe

23
Use un método criptográfico asimétrico (como RSA) para generar y decodificar la clave del producto para evitar incrustar el secreto en el código.
Amir Moghimi

66
Creo que cuando alguien esté pirateando su código (posiblemente en el nivel de ensamblado) para encontrar su clave secreta, probablemente también esté en el nivel en el que pueda pasar por alto sus cheques por completo. No creo que haya un método de registro tan seguro que pueda sobrevivir a un buen hacker ejecutando el programa localmente. Como decía el comentario original, realmente se trata de cualquier cosa que lo haga un paso más difícil que simplemente copiar el archivo. Muchos juegos en estos días han renunciado a la protección de copia y simplemente toman el contenido del juego en línea, en cuyo caso el código está fuera de las manos del pirata informático.
JamieB

1
¿Es común incluir restricciones en la clave de licencia? Por ejemplo, restricciones de tiempo, conteo de usuarios concurrentes, módulos para instalar, etc.
Carlo

97

Hay muchas formas de generar claves de licencia, pero muy pocas de ellas son realmente seguras. Y es una pena, porque para las empresas, las claves de licencia tienen casi el mismo valor que el efectivo real.

Lo ideal sería que sus claves de licencia tengan las siguientes propiedades:

  1. Solo su empresa debería poder generar claves de licencia para sus productos, incluso si alguien realiza una ingeniería inversa de sus productos (lo que sucederá, hablo por experiencia). Ofuscar el algoritmo u ocultar una clave de cifrado dentro de su software está realmente fuera de discusión si se toma en serio el control de las licencias. Si su producto tiene éxito, alguien creará un generador de claves en cuestión de días desde su lanzamiento.

  2. Una clave de licencia debería ser utilizable en una sola computadora (o al menos debería poder controlarla muy estrictamente)

  3. Una clave de licencia debe ser breve y fácil de escribir o dictar por teléfono. No desea que todos los clientes llamen al soporte técnico porque no entienden si la clave contiene una "l" o un "1". Su departamento de soporte lo agradecería y tendrá costos más bajos en esta área.

Entonces, ¿cómo resuelves estos desafíos?

  1. La respuesta es simple pero técnicamente desafiante: firmas digitales usando criptografía de clave pública. De hecho, sus claves de licencia deben ser "documentos" firmados, que contengan algunos datos útiles, firmados con la clave privada de su empresa. Las firmas deben ser parte de la clave de licencia. El producto debe validar las claves de licencia con la clave pública correspondiente. De esta manera, incluso si alguien tiene acceso completo a la lógica de su producto, no puede generar claves de licencia porque no tiene la clave privada. Una clave de licencia se vería así: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) El mayor desafío aquí es que los algoritmos clásicos de clave pública tienen grandes tamaños de firma. RSA512 tiene una firma de 1024 bits. No desea que sus claves de licencia tengan cientos de caracteres. Uno de los enfoques más potentes es utilizar la criptografía de curva elíptica (con implementaciones cuidadosas para evitar las patentes existentes). Las claves ECC son como 6 veces más cortas que las claves RSA, para la misma potencia. Puede reducir aún más los tamaños de firma utilizando algoritmos como el algoritmo de firma digital Schnorr (la patente expiró en 2008 - buena :))

  2. Esto se puede lograr mediante la activación del producto (Windows es un buen ejemplo). Básicamente, para un cliente con una clave de licencia válida, debe generar algunos "datos de activación", que es un mensaje firmado que incorpora la identificación del hardware de la computadora como los datos firmados. Esto generalmente se hace a través de Internet, pero solo UNA VEZ: el producto envía la clave de licencia y la identificación del hardware de la computadora a un servidor de activación, y el servidor de activación devuelve el mensaje firmado (que también se puede hacer corto y fácil de dictar sobre el teléfono). A partir de ese momento, el producto no verifica la clave de licencia al inicio, sino los datos de activación, que necesitan que la computadora sea la misma para validar (de lo contrario, los DATOS serían diferentes y la firma digital no se validaría).

  3. Bueno, simplemente elimine los caracteres redundantes como "1", "l", "0", "o" de sus teclas. Divida la cadena de clave de licencia en grupos de caracteres.


8
¿No podrían simplemente editar el software agregando / quitando código para que la verificación se omita por completo?
Pacerier

¿La respuesta al número 1 necesita esencialmente un servicio de activación / desactivación en línea?
Dan W

2
Me gustaría señalar cuán inmensamente superior es esta respuesta a la otra cuestión.
Erik Aronesty

1
@Pacerier Hay muchas cosas de las que las claves de licencia protegen a las compañías de software. Modificar el exe no es uno de ellos.
Erik Aronesty

1
Vale la pena señalar que incluso con las claves privadas / públicas de criptografía asimétrica, todavía es posible generar licencias falsas, simplemente reemplazando la clave pública incluida en el software con otra clave pública, y usando su clave privada correspondiente para firmar la licencia falsa. Es por eso que tenemos y necesitamos Autoridades de Certificación confiables por cierto, que vinculan las claves públicas a las identidades. Entonces, si bien esto podría agregar un aro más para saltar, no garantiza por sí solo el n. ° 1.
Saeb Amini

76

Respuesta simple: no importa qué esquema utilices, se puede descifrar.

No castigue a los clientes honestos con un sistema destinado a prevenir a los piratas informáticos, ya que los piratas informáticos lo romperán independientemente

Un código hash simple vinculado a su correo electrónico o similar es probablemente lo suficientemente bueno. Las ID basadas en hardware siempre se convierten en un problema cuando las personas necesitan reinstalar o actualizar el hardware.

Buen hilo sobre el tema: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34


2
De acuerdo, ¡no querrás molestar a los usuarios que realmente compran tu producto! (preste atención m $, manzana, etc.)
Jason

2
MS, Apple, etc. pueden salirse con la suya ya que son grandes y proporcionan productos básicos que son difíciles de conseguir en otros lugares o tienen una gran sombra de mercado que pueden usar para forzar a las personas. El pequeño desarrollador no puede.
goleta

1
un esquema de firma de clave pub / priv no se puede "descifrar" para producir nuevas claves válidas para los usuarios que desean ejecutar código firmado descargado del sitio del editor, en lugar de software descifrado. mientras que un esquema hash / simétrico se puede descifrar para producir nuevas claves de licencia válidas, indistinguibles de las inválidas. Gran diferencia.
Erik Aronesty

Enlace roto ...
stigzler

56

Al generar la clave, no olvides concatenar la versión y el número de compilación a la cadena en la que calculas el hash. De esa manera, no habrá una sola clave que desbloquee todo lo que haya lanzado.

Después de encontrar algunas claves o parches flotando en astalavista.box.sk , sabrá que logró hacer algo lo suficientemente popular que alguien se molestó en descifrar. ¡Alegrarse!


8
"no olvides concatenar la versión y el número de compilación a la cadena en la que calculas el hash", ¿pero eso no hará que la clave se rompa cuando el usuario actualice a una versión de parche menor?
thomthom

1
@thomthom ¿Qué tal si asociamos una versión máxima a una clave? La idea de la versión en sí es plausible y agrega más seguridad
Marvin Thobejane

@MarvinThobejane para asociar una versión máxima, puede firmar la versión máxima permitida y hacer que el código repita un poco su versión. pero no> = operaciones permitidas en sigs.
Erik Aronesty

22

Además de lo que ya se ha dicho ...

Cualquier uso de aplicaciones .NET es inherentemente rompible debido a los problemas de lenguaje intermedio. Un simple desmontaje del código .NET abrirá su producto a cualquiera. Pueden pasar por alto fácilmente su código de licencia en ese momento.

Ya ni siquiera puede usar valores de hardware para crear una clave. Las máquinas virtuales ahora permiten a alguien crear una imagen de una máquina con licencia y ejecutarla en cualquier plataforma que elijan.

Si es un software costoso, hay otras soluciones. Si no es así, solo hazlo lo suficientemente difícil para el hacker casual. Y acepte el hecho de que eventualmente habrá copias sin licencia.

Si su producto es complicado, los problemas de soporte inherentes serán crear cierta protección para usted.


99
+1 para evitar la debilidad en los valores de hardware debido a las máquinas virtuales.
Rubens Mariuzzo

3
Para eso están los nombres seguros para .NET y Authenticode for PE. Si alguien ha descompilado, modificado y reconstruido su biblioteca, no se firmará y la aplicación simplemente no se ejecutará. La máquina virtual .NET no lo permitirá.
Stephen Tunney

2
La firma es para validar el origen del programa que ejecutará. Si el usuario no se preocupa por el origen porque sabe que está modificado y agrietado, el cracker quitará la firma o incluso la firmará con su propia firma. La firma deja de mezclar conjuntos confiables con conjuntos no confiables.
jesusduarte

una aplicación móvil puede usarse como un dongle de hardware manipulado por un jurado para software costoso ... solo pague usando la aplicación e inserte una clave de firma en el elemento seguro de la aplicación. entonces puede activar usando la aplicación de escritorio + ... desactivando el otro escritorio. colocar algunas áreas de código de sección críticas en la aplicación y / o en los servicios de computación homomórficos en línea puede ayudar a prevenir la descompilación trivial.
Erik Aronesty

12

El motor C # / .NET que utilizamos para la generación de claves de licencia ahora se mantiene como código abierto:

https://github.com/appsoftware/.NET-Licence-Key-Generator .

Se basa en un sistema de "Verificación de clave parcial", lo que significa que solo un subconjunto de la clave que utiliza para generar la clave debe compilarse en su distribuible. Usted crea las claves usted mismo, por lo que la implementación de la licencia es exclusiva de su software.

Como se indicó anteriormente, si su código se puede descompilar, es relativamente fácil eludir la mayoría de los sistemas de licencias.


¿Estaría dispuesto a hacer un tutorial para usar este producto? Encontré su wiki un poco escaso.
Anthony Ruffino

El proyecto ahora se ha abierto en GitHub si eso ayuda (respuesta editada con enlace).
gb2d

11

Soy uno de los desarrolladores detrás de la plataforma de licencias de software Cryptolens y he estado trabajando en sistemas de licencias desde los 14 años. En esta respuesta, he incluido algunos consejos basados ​​en la experiencia adquirida a lo largo de los años.

La mejor manera de resolver esto es configurando un servidor de clave de licencia que cada instancia de la aplicación llamará para verificar una clave de licencia.

Beneficios de un servidor de clave de licencia

Las ventajas con un servidor de clave de licencia es que:

  1. siempre puede actualizar o bloquear una clave de licencia con efecto inmediato.
  2. cada clave de licencia puede bloquearse en cierto número de máquinas (esto ayuda a evitar que los usuarios publiquen la clave de licencia en línea para que otros la usen).

Consideraciones

Si bien la verificación de licencias en línea le brinda más control sobre cada instancia de la aplicación, la conexión a Internet no siempre está presente (especialmente si se dirige a empresas más grandes), por lo que necesitamos otra forma de realizar la verificación de la clave de licencia.

La solución es firmar siempre la respuesta de la clave de licencia del servidor utilizando un criptosistema de clave pública como RSA o ECC (posiblemente mejor si planea ejecutar en sistemas integrados). Su aplicación solo debe tener la clave pública para verificar la respuesta de la clave de licencia.

Entonces, en caso de que no haya conexión a Internet, puede usar la respuesta de clave de licencia anterior en su lugar. Asegúrese de almacenar tanto la fecha como el identificador de la máquina en la respuesta y verifique que no sea demasiado antigua (por ejemplo, permita que los usuarios estén desconectados como máximo 30 días, etc.) y que la respuesta de la clave de licencia pertenezca al dispositivo correcto.

Tenga en cuenta que siempre debe verificar el certificado de respuesta de la clave de licencia, incluso si está conectado a Internet), para asegurarse de que no se haya cambiado desde que salió del servidor (esto aún debe hacerse incluso si su API el servidor de clave de licencia usa https)

Proteger algoritmos secretos

La mayoría de las aplicaciones .NET se pueden realizar con ingeniería inversa con bastante facilidad (hay un desensamblador proporcionado por Microsoft para obtener el código IL y algunos productos comerciales pueden incluso recuperar el código fuente en, por ejemplo, C #). Por supuesto, siempre puedes ofuscar el código, pero nunca es 100% seguro.

En la mayoría de los casos, el propósito de cualquier solución de licencia de software es ayudar a las personas honestas a ser honestas (es decir, que los usuarios honestos que estén dispuestos a pagar no se olviden de pagar después de que caduque una prueba, etc.).

Sin embargo, es posible que aún tenga algún código que de ninguna manera quiera filtrar al público (por ejemplo, un algoritmo para predecir los precios de las acciones, etc.). En este caso, la única forma de hacerlo es crear un punto final de API al que llamará su aplicación cada vez que se ejecute el método. Requiere conexión a Internet, pero asegura que su código secreto nunca sea ejecutado por la máquina del cliente.

Implementación

Si no desea implementar todo usted mismo, le recomendaría que eche un vistazo a este tutorial (parte de Cryptolens )


Una pregunta sobre cómo restringir la clave de licencia guardada para que no sea demasiado antigua: dado que es posible que la PC no esté conectada a Internet, ¿su fecha y hora siempre pueden cambiarse para permanecer en la misma fecha válida?
Amir Mahdi Nassiri

¿No pueden los usuarios omitir el servidor de licencias en línea definiendo un host de bucle invertido en Windows? He visto muchas aplicaciones pirateadas así, Resharper y Matlab son las que recuerdo.
Amir Mahdi Nassiri

1
@AmirMahdiNassiri Para la pregunta 1: si la PC está permanentemente desconectada, puede usar un dongle de reloj en tiempo real (RTC) como fuente confiable de tiempo. Para la pregunta 2: Dado que la respuesta se firma con la clave privada del proveedor (y se verifica con la clave pública dentro de la aplicación), un adversario necesitaría volver a firmar el archivo sin conocer la clave privada, que, en el momento de la escritura, es no es posible con claves RSA de 2048 bits.
Artem

7

He usado Crypkey en el pasado. Es uno de los muchos disponibles.

Solo puede proteger el software hasta cierto punto con cualquier esquema de licencia.


6

No sé qué tan elaborado quieres ser

pero creo que .net puede acceder al número de serie del disco duro.

puede hacer que el programa le envíe eso y algo así (como el nombre de usuario y la dirección mac del nic)

calcula un código basado en eso y les envía la clave por correo electrónico.

evitarán que cambien las máquinas una vez que tengan la llave.


44
Y evite que reemplacen un HD muerto entre otros personajes, lo que lleva a la frustración. Desafortunadamente, no hay una respuesta fácil, debe equilibrar la confianza con los mecanismos básicos de licencias.
goleta

Trabajó muchos años como ingeniero de software con un producto que usaba el número de serie del disco duro, era completamente inseguro para aquellos que sabían cómo actualizarlo.
Oden

Estaba implicando usar este número con otras cosas (dirección mac, FQDN), tal vez arrojarlos a todos en un hash. El punto es hacer que sea un poco más difícil falsificar todos estos datos que invertir el software en primer lugar y eliminar el cheque porque siempre es una opción.
Crash893

4

La única forma de hacer todo lo que solicitó es exigir un acceso a Internet y verificación con un servidor. La aplicación debe iniciar sesión en el servidor con la clave y luego debe almacenar los detalles de la sesión, como la dirección IP. Esto evitará que la clave se use en varias máquinas diferentes. Esto generalmente no es muy popular entre los usuarios de la aplicación, y a menos que sea una aplicación muy costosa y complicada, no vale la pena.

Simplemente podría tener una clave de licencia para la aplicación, y luego verificar el lado del cliente si la clave es buena, pero es fácil distribuir esta clave a otros usuarios, y con un descompilador se pueden generar nuevas claves.


55
Trabajé en una empresa que utilizaba un esquema de licencias basado en Internet. Cada vez que el programa comenzó a funcionar en línea para validar, creo que la compañía gastó más $$ en infraestructura y desarrolladores para su solución de licencia de lo que habría perdido de la piratería (eran un producto de nicho).
Jason

3
Además, los costos de soporte técnico fueron enormes. muchas, MUCHAS veces un usuario usaría legítimamente otra computadora para intentar ejecutar el software, pero el hash fue diferente, lo que llevó a una gran cantidad de soporte técnico. en resumen, lo que dijo la goleta: no castigue a los usuarios honestos.
Jason

1
Parece que su empresa era un poco entusiasta al requerir validación en el inicio cada vez.
Jugg1es

@ Jason, bueno, deberían subir el precio del producto.
Pacerier

1
@Pacerier: respuesta incorrecta.
ligereza corre en órbita el

4

Implementé la activación única basada en Internet en el software de mi empresa (C # .net) que requiere una clave de licencia que se refiere a una licencia almacenada en la base de datos del servidor. El software llega al servidor con la clave y recibe información de licencia que luego se cifra localmente utilizando una clave RSA generada a partir de algunas variables (una combinación de CPUID y otras cosas que no cambiarán con frecuencia) en la computadora del cliente y luego la almacena en el registro

Requiere un poco de codificación del lado del servidor, pero nos ha funcionado muy bien y pude usar el mismo sistema cuando nos expandimos al software basado en navegador. También le brinda a su personal de ventas una gran información sobre quién, dónde y cuándo se está utilizando el software. Cualquier sistema de licencias que solo se maneja localmente es completamente vulnerable a la explotación, especialmente con la reflexión en .NET . Pero, como todos han dicho, ningún sistema es completamente seguro.

En mi opinión, si no está utilizando licencias basadas en la web, no tiene ningún sentido proteger el software. Con el dolor de cabeza que puede causar DRM, no es justo para los usuarios que realmente han pagado que sufran.


1
Pero el principal problema con las licencias web es que el servicio de licencias se convierte en un objetivo principal para los ataques DDoS ... que paralizan el servicio o inflan los costos de la nube.
afk5min

44
Eso es como decir que no hay razón para tener un sitio web porque es vulnerable a los ataques DDoS ...
jugg1es

@ jugg1es En ninguna parte de su comentario dijo "no tiene sentido". Simplemente señaló el hecho de que es una vulnerabilidad que debe considerarse.
Dan Bechard

Y los cheques aún se pueden eliminar en el cliente. Sin verificación, sin licencia basada en web ...
azarai

1
¿Te refieres al código de aplicación real con "información requerida"? ¿Código que sería necesario para ejecutar la aplicación? De lo contrario, pensaría que todavía dará como resultado llamar a los métodos de verificación con licencia en el código de las unidades.
azarai

4

Creo firmemente que solo el sistema de licencia basado en criptografía de clave pública es el enfoque correcto aquí, porque no tiene que incluir información esencial requerida para la generación de licencias en su código fuente.

En el pasado, he usado la Biblioteca de licencias de Treek muchas veces, porque cumple todos estos requisitos y ofrece un precio realmente bueno. Utiliza la misma protección de licencia para los usuarios finales y para sí mismo, y nadie lo descifró hasta ahora. También puede encontrar buenos consejos en el sitio web para evitar la piratería y las grietas.


¿La criptografía de clave pública necesitaría usar un servicio de activación en línea? Quiero decir, si no está en el código fuente (supongo que te refieres también al ejecutable), ¿dónde más podría estar?
Dan W

No, no tiene que usar el servicio de activación en línea. Puede generar archivos de licencia completamente fuera de línea.
panpernicek

La clave está en el hecho de que solo está colocando una clave pública en el código, que no se puede usar para generar licencias. Solo para su verificación.
panpernicek

3

Como algunos otros mencionados, soy un gran oponente de ser hostil a los clientes por defecto, algo por lo que la industria de licencias es conocida. Así que ampliaré una buena solución para su problema que también ofrece un buen cliente UX .

Para comenzar, mencionó que tiene una versión "limitada" de su software que está utilizando para tratar de convertir a los clientes a "actualizar" para obtener funciones adicionales. Así que lo que está buscando son las licencias de funciones de su producto, por ejemplo, un cliente puede comprar una licencia para funciones X o función-Y .

Construí Keygen con este tipo de licencia en mente. Keygen es una API REST de licencias que le permite administrar cuentas de usuario, licencias y también rastrear el uso / asociaciones de la máquina.

Lo que haría es configurar 2 tipos de licencia (una política dentro de Keygen) donde una es una política básica para la versión gratuita limitada y la otra es una política para la versión paga.

No estoy seguro de lo que está usando para los pagos, pero supongamos que está usando algo como Stripe (bastante estándar hoy en día) que ofrece webhooks . Keygen también tiene webhooks (ya sea que lo use o no, todo esto sigue siendo aplicable). Puede integrar Keygen para hablar con su proveedor de pagos utilizando webhooks de ambos lados (piense: customer.created-> crear una licencia base para el cliente, license.created-> cobrar al cliente por la nueva licencia).

Entonces, al utilizar webhooks, podemos automatizar la creación de licencias para nuevos clientes. Entonces, ¿qué pasa con la validación de la licencia dentro de la propia aplicación? Esto se puede hacer de varias maneras, pero la forma más popular es exigir a su cliente que ingrese una clave de licencia larga en un campo de entrada que luego puede validar; Creo que esta es una forma terrible de manejar la validación de la licencia en su aplicación.

¿Por qué pienso eso? En primer lugar, requiere que su cliente ingrese una clave de licencia tediosamente larga destinada al consumo de la máquina, y en segundo lugar, requiere que usted y su cliente realicen un seguimiento de dicha clave de licencia tediosamente larga .

Bien, entonces, ¿qué es una alternativa? Creo que la mejor alternativa es hacer algo a lo que estén acostumbrados todos sus clientes: permitirles crear una cuenta para su producto utilizando un correo electrónico / contraseña . Luego puede asociar todas sus licencias y sus máquinas con esa cuenta. Entonces, en lugar de ingresar una clave de licencia, simplemente pueden iniciar sesión con sus credenciales.

¿Qué ventaja te da eso? En primer lugar, elimina la necesidad de que usted y sus clientes realicen un seguimiento de las claves de licencia, ya que todo se maneja detrás de escena dentro de su cuenta de usuario y lo más importante: ahora puede ofrecer a sus clientes licencias y máquinas de autoservicio ¡activación! es decir, dado que todas sus licencias y máquinas están asociadas con su cuenta de usuario, puede solicitarles que compren una licencia cuando inicien su aplicación en una máquina no reconocida.

Ahora sobre validación de la licencia : cada vez que el cliente inicia sesión en la aplicación con su correo electrónico / contraseña, puede preguntar su cuenta de usuario para las licencias de su propiedad para determinar si pueden utilizar funciones X o función-Y . ¡Y dado que su aplicación ahora es de autoservicio , puede permitir que sus clientes compren funciones adicionales directamente desde su aplicación!

Por lo tanto, hemos introducido un montón de automatización en nuestro sistema de licencias, podemos otorgar licencias de funciones individuales (es decir, una versión limitada frente a la completa), hemos ofrecido una experiencia de usuario increíble para nuestros clientes y también hemos aliviado una de las principales razones para solicitudes de soporte: recuperación de clave de licencia.

De todos modos, esto se hizo largo, pero espero que ayude a alguien.


No puedo imaginar que una DLL tenga una licencia como esta en ninguna situación de desarrollo empresarial. Piense en escenarios automatizados de construcción e implementación, por ejemplo. O simplemente agregue este paso a los muchos que generalmente se requieren para configurar una máquina de desarrollador. Para mí, las claves de licencia deben ser emitidas previamente, y no basadas en máquinas individuales, para ser prácticas
DvS

2

No es posible prevenir la piratería de software por completo. Puede evitar la piratería casual y eso es lo que hacen todas las soluciones de licencia.

La licencia bloqueada de nodo (máquina) es mejor si desea evitar la reutilización de las claves de licencia. He estado usando Cryptlex durante aproximadamente un año para mi software. También tiene un plan gratuito , por lo que si no espera demasiados clientes, puede usarlo de forma gratuita.


2

Puede usar una solución de terceros gratuita para manejar esto por usted, como Quantum-Key.Net. Es gratis y maneja los pagos a través de PayPal a través de una página de ventas web que crea para usted, emite claves por correo electrónico y bloquea el uso de claves en una computadora específica para Prevenir la piratería.

También debe tener cuidado de ofuscar / cifrar su código o se puede realizar ingeniería inversa fácilmente utilizando software como De4dot y .NetReflector. Un buen ofuscador de código gratuito es ConfuserEx, que es rápido y fácil de usar y más efectivo que las alternativas costosas.

Debe ejecutar su software terminado a través de De4Dot y .NetReflector para realizar ingeniería inversa y ver qué vería un cracker si hicieran lo mismo y para asegurarse de que no haya dejado ningún código importante expuesto o sin disfraz.

Su software seguirá siendo crackeable, pero para el cracker informal puede ser suficiente para posponerlos y estos simples pasos también evitarán que su código sea extraído y reutilizado.

https://quantum-key.net

¿Cómo usar ConfuserEx?

https://github.com/0xd4d/de4dot

https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.