¿Cómo puedo crear una clave de producto para mi aplicación C #?

90

¿Cómo puedo crear una clave de producto para mi aplicación C #?

Necesito crear una clave de producto (o licencia) que actualizo anualmente. Además, necesito crear uno para las versiones de prueba.

Relacionado:

J3r3myK
fuente
@stukelly que se publicó después de que J3r3myK publicara su pregunta ...
Dozer789

Respuestas:

83

Puede hacer algo como crear un registro que contenga los datos que desea autenticar en la aplicación. Esto podría incluir cualquier cosa que desee, por ejemplo, funciones del programa para habilitar, fecha de vencimiento, nombre del usuario (si desea vincularlo a un usuario). Luego, encripte eso usando algún algoritmo criptográfico con una clave fija o hash. Luego, simplemente verifíquelo dentro de su programa. Una forma de distribuir el archivo de licencia (en Windows) es proporcionarlo como un archivo que actualiza el registro (evita que el usuario tenga que escribirlo).

Sin embargo, tenga cuidado con la falsa sensación de seguridad: tarde o temprano, alguien simplemente parcheará su programa para omitir esa verificación y distribuirá la versión parcheada. O bien, encontrarán una clave que pase todas las verificaciones y la distribuya, o retroceda el reloj, etc. No importa cuán intrincado haga su esquema, cualquier cosa que haga para esto será, en última instancia, seguridad a través de la oscuridad y siempre lo harán. ser capaz de esto. Incluso si no pueden, alguien lo hará y distribuirá la versión pirateada. Lo mismo se aplica incluso si proporciona un dongle: si alguien lo desea, también puede parchear el cheque. Firmar digitalmente su código no ayudará, pueden eliminar esa firma o renunciar a ella.

Puede complicar un poco las cosas utilizando técnicas para evitar que el programa se ejecute en un depurador, etc., pero incluso esto no es a prueba de balas. Por lo tanto, debería hacerlo lo suficientemente difícil para que un usuario honesto no se olvide de pagar. También tenga mucho cuidado de que su esquema no se convierta en una molestia para los usuarios que pagan; es mejor tener algunas copias falsificadas que para sus clientes que pagan no poder usar lo que han pagado.

Otra opción es tener una verificación en línea: simplemente proporcione al usuario una identificación única y verifique en línea qué capacidades debe tener esa identificación, y almacénela en caché durante un período. Sin embargo, se aplican las mismas advertencias: las personas pueden evitar cualquier cosa como esta.

Considere también los costos de soporte de tener que lidiar con usuarios que han olvidado su clave, etc.

editar: Solo quiero agregar, no inviertas demasiado tiempo en esto o pienses que de alguna manera tu intrincado esquema será diferente e irrompible. No lo hará, y no puede ser así mientras la gente controle el hardware y el sistema operativo en el que se ejecuta su programa. Los desarrolladores han estado tratando de idear esquemas cada vez más complejos para esto, pensando que si desarrollan su propio sistema, solo ellos lo conocerán y, por lo tanto, será 'más seguro'. Pero realmente es el equivalente en programación a intentar construir una máquina de movimiento perpetuo. :-)

Frankodwyer
fuente
1
Buen resumen. Si alguien no cree que esto sea fácil de omitir, busque CheatEngine, es tan fácil que los no programadores puedan hacerlo. Lo mejor es simplificar esta capa.
Kelly
Tengo el mismo problema, hice una clave de licencia para mi aplicación con la fecha de vencimiento y la última fecha registrada para la verificación, pero el problema es que tengo que agregar la clave privada para editar el archivo para actualizar la última fecha registrada que es no es una forma inteligente de poner la clave en el código. algún consejo ?
Doicare
16

¿En quién confías?

Siempre he considerado esta área demasiado crítica para confiar en un tercero para administrar la seguridad en tiempo de ejecución de su aplicación. Una vez que ese componente se descifra para una aplicación, se descifra para todas las aplicaciones. Le sucedió a Discreet en cinco minutos una vez que eligieron una solución de licencia de terceros para 3ds Max hace años ... ¡Buenos tiempos!

En serio, considere lanzar el suyo propio para tener un control total sobre su algoritmo. Si es así, considere usar componentes en su clave de la siguiente manera:

  • Nombre de la licencia: el nombre del cliente (si lo hay) al que está licenciando. Útil para administrar las implementaciones de la empresa: haga que se sientan especiales al tener un nombre "personalizado" en la información de licencia que les proporcione.
  • Fecha de vencimiento de la licencia
  • Número de usuarios para ejecutar bajo la misma licencia. Esto supone que tiene una forma de rastrear instancias en ejecución en un sitio, de una manera similar a un servidor
  • Códigos de función: para permitirle utilizar el mismo sistema de licencias en varias funciones y en varios productos. Por supuesto, si está roto para un producto, está roto para todos.

Luego, haga una suma de verificación y agregue cualquier cifrado (reversible) que desee para que sea más difícil de descifrar.

Para crear una clave de licencia de prueba, simplemente establezca valores para los valores anteriores que se traducen como "modo de prueba".

Y dado que este es probablemente el código más importante en su aplicación / empresa, además de / en lugar de ofuscación, considere colocar las rutinas de descifrado en un archivo DLL nativo y simplemente P / Invoke .

Varias empresas para las que he trabajado han adoptado enfoques generalizados para esto con gran éxito. O tal vez no valía la pena romper los productos;)

Spiffeah
fuente
3
El cifrado para su información es siempre reversible, sería inútil no poder leer lo que se ha cifrado. El hash es la única forma de "cifrado" en la que podría estar pensando.
Samuel
"No desarrolle su propio esquema de cifrado", que creo que es de Bruce Scheier (no estoy seguro), es el camino a seguir. Es posible que desee echar un vistazo a esta respuesta: security.stackexchange.com/questions/2202/…
Shadok
¿Puede desarrollar "..P / Invocarlo"? Miré la página vinculada pero no me hizo más sabio: - /
MrCalvin
11

Si pregunta sobre las claves que puede escribir, como las claves de producto de Windows, entonces se basan en algunas comprobaciones. Si estás hablando de las claves que tienes que copiar y pegar, entonces están basadas en una firma digital (cifrado de clave privada).

Una lógica de clave de producto simple podría ser comenzar diciendo que la clave de producto consta de cuatro grupos de 5 dígitos, como abcde-fghij-kljmo-pqrst , y luego especificar relaciones internas como f + k + p debería ser igual a a, es decir, los primeros dígitos de 2 , 3 y 4 grupos deben sumar a. Esto significa que 8xxxx-2xxxx-4xxxx-2xxxx es válido, al igual que 8xxxx-1xxxx-0xxxx-7xxxx. Por supuesto, también habría otras relaciones, incluidas relaciones complejas como, si el segundo dígito del primer grupo es impar, entonces el último dígito del último grupo también debería ser impar. De esta manera, habría generadores de claves de producto y la verificación de claves de producto simplemente comprobaría si coincide con todas las reglas.

El cifrado es normalmente la cadena de información sobre la licencia cifrada con una clave privada (== firmada digitalmente) y convertida a Base64 . La clave pública se distribuye con la aplicación. Cuando llega la cadena Base64, la clave pública la verifica (== descifra) y, si se encuentra válida, se activa el producto.

Kinjal Dixit
fuente
8

Ya sea trivial o difícil de descifrar, no estoy seguro de que realmente marque una gran diferencia.

La probabilidad de que su aplicación sea descifrada es mucho más proporcional a su utilidad que a la fuerza del manejo de la clave del producto.

Personalmente, creo que hay dos clases de usuarios. Los que pagan. Aquellos que no lo hacen. Los que lo hagan probablemente lo harán incluso con la protección más trivial. Aquellos que no lo hagan esperarán una grieta o buscarán en otra parte. De cualquier manera, no obtendrá más dinero.

gastador
fuente
6

Tengo que admitir que haría algo bastante loco.

  1. Encuentre un cuello de botella de CPU y extráigalo a un archivo DLL P / Invokeable .
  2. Como acción posterior a la compilación, cifre parte del archivo DLL con una clave de cifrado XOR.
  3. Seleccione un esquema de clave pública / privada, incluya la clave pública en el archivo DLL
  4. Realice los arreglos para que descifrar la clave del producto y XORing las dos mitades juntas dé como resultado la clave de cifrado para la DLL.
  5. En el código DllMain de la DLL, desactive la protección (PAGE_EXECUTE_READWRITE) y descifrela con la clave.
  6. Haga un método LicenseCheck () que realice una verificación de cordura de la clave de licencia y los parámetros, luego compruebe sumas del archivo DLL completo, arrojando una violación de licencia en cualquiera de ellos. Ah, y haz otra inicialización aquí.

Cuando encuentren y eliminen LicenseCheck, qué diversión seguirá cuando la DLL comience a fallar en la segmentación .

Joshua
fuente
¿No sería necesario entonces que DEP esté desactivado?
Rowland Shaw
No. Establecer PAGE_EXECUTE_READWRITE es la forma correcta documentada de escribir código de modificación automática y borra el bit NX solo en esa página.
Joshua
8
Esta técnica general fue muy popular a finales de los 80. Su debilidad es que el código "secreto" se descifra en la RAM, lo que facilita su robo de cualquier copia del software en ejecución.
Ray Burns
5

También existe la opción Servicios de protección y licencias de software de Microsoft (SLP). Después de leerlo, realmente desearía poder usarlo.

Me gusta mucho la idea de bloquear partes del código según la licencia. Cosas interesantes y lo más seguro para .NET. ¡Interesante lectura incluso si no la usas!

Los servicios de protección y licencias de software (SLP) de Microsoft® son un servicio de activación de software que permite a los proveedores de software independientes (ISV) adoptar términos de licencia flexibles para sus clientes. Los servicios SLP de Microsoft emplean un método de protección único que ayuda a proteger su aplicación y la información de licencias, lo que le permite llegar al mercado más rápido y, al mismo tiempo, aumentar el cumplimiento del cliente.

Nota: Esta es la única forma en que publicaría un producto con código sensible (como un algoritmo valioso).

cocine
fuente
Para aquellos que lo recuerdan como cancelado: SLP se relanza nuevamente
Michael Olesen
5

Si desea una solución simple solo para crear y verificar números de serie, pruebe Ellipter . Utiliza criptografía de curvas elípticas y tiene una función de "Fecha de vencimiento" para que pueda crear versiones de prueba o claves de registro de tiempo limitado.

Roland
fuente
2

Otra buena herramienta económica para claves de producto y activaciones es un producto llamado InstallKey. Eche un vistazo a www.lomacons.com

Che
fuente
2

Un método simple es utilizar un identificador único global (GUID). Los GUID generalmente se almacenan como valores de 128 bits y comúnmente se muestran como 32 dígitos hexadecimales con grupos separados por guiones, como {21EC2020-3AEA-4069-A2DD-08002B30309D}.

Use el siguiente código en C # por System.Guid.NewGuid().

getKey = System.Guid.NewGuid().ToString().Substring(0, 8).ToUpper(); //Will generate a random 8 digit hexadecimal string.

_key = Convert.ToString(Regex.Replace(getKey, ".{4}", "$0/")); // And use this to separate every four digits with a "/".

Espero que ayude.

Aishwar C Nigam
fuente
1

El truco consiste en tener un algoritmo que solo tú conozcas (de modo que se pueda decodificar en el otro extremo).

Hay cosas simples como "Elija un número primo y agréguele un número mágico"

Opciones más complicadas como el uso de cifrado asimétrico de un conjunto de datos binarios (que podría incluir un identificador único, números de versión, etc.) y distribuir los datos cifrados como clave.

También podría valer la pena leer las respuestas a esta pregunta , así

Rowland Shaw
fuente
6
"El truco consiste en tener un algoritmo que solo tú conozcas"; esta es más o menos la definición de seguridad por oscuridad, y una idea realmente mala.
Nick Johnson
3
Sin embargo, todas las licencias se realizan mediante un algoritmo que involucra secretos. A menudo, la mejor forma de abordar la concesión de licencias es invirtiendo en abogados, en lugar de la carrera armamentista de crear llaves "irrompibles"
Rowland Shaw
+1 para el comentario sobre el cumplimiento de la licencia a través de medios legales
Rob
Sí, todas las licencias son débiles, al igual que DRM. Sin embargo, confiar en un algoritmo secreto es demostrablemente más débil .
Nick Johnson
1
Te di +1 por una buena respuesta, y deseo darte otro para contrarrestar el voto negativo. Lamentablemente, hay algunos bebés muy inmaduros en el mundo.
ProfK
0

Puede comprobar LicenseSpot . Proporciona:

  • Componente de licencia gratuito
  • Activación en línea
  • API para integrar tu aplicación y tienda online
  • Generación de números de serie
  • Revocar licencias
  • Gestión de suscripciones
Jose
fuente
1
"Gratis" no es realmente gratis. Es gratis incrustar el componente de licencia en su aplicación; no es gratis que la aplicación utilice realmente el componente de licencia. Más allá de 10 activaciones, debe pagar una tarifa mensual. No es un porcentaje por activación. Para aplicaciones .NET de bajo volumen y bajo costo, este modelo de precios será una desventaja. No es como la AppStore de Apple para aplicaciones .NET.
Cheeso
0

Voy a aprovechar un poco la gran respuesta de @ frankodwyer y profundizar un poco más en las licencias en línea. Soy el fundador de keygen , una API REST de licencias creada para desarrolladores.

Dado que mencionó que desea 2 "tipos" de licencias para su aplicación, es decir, una "versión completa" y una "versión de prueba", podemos simplificar eso y usar un modelo de licencia de funciones en el que usted licencia funciones específicas de su aplicación (en este caso, hay un conjunto de funciones "completo" y un conjunto de funciones de "prueba").

Para empezar, podríamos crear 2 tipos de licencias (llamadas políticas en Keygen) y cada vez que un usuario registra una cuenta, puede generar una licencia de "prueba" para que comiencen (la licencia de "prueba" implementa nuestra política de funciones de "prueba") , que puede utilizar para realizar varias comprobaciones dentro de la aplicación, por ejemplo, el usuario puede utilizar la función de prueba A y la función de prueba B .

Y basándose en eso, cada vez que un usuario compra su aplicación (ya sea que esté usando PayPal, Stripe, etc.), puede generar una licencia que implemente la política de funciones "completa" y asociarla con la cuenta del usuario . Ahora, dentro de su aplicación, puede verificar si el usuario tiene una licencia "completa" que puede hacer Pro-Feature-X y Pro-Feature-Y (haciendo algo comouser.HasLicenseFor(FEATURE_POLICY_ID) ).

Mencioné permitir que sus usuarios creen cuentas de usuario, ¿ qué quiero decir con eso? Entré en esto en detalle en un par de otras respuestas , pero un resumen rápido de por qué creo que esta es una forma superior de autenticar e identificar a sus usuarios:

  1. Las cuentas de usuario le permiten asociar múltiples licencias y múltiples máquinas a un solo usuario , lo que le brinda información sobre el comportamiento de sus clientes y les solicita "compras en la aplicación", es decir, comprar su versión "completa" (algo así como aplicaciones móviles).
  2. No deberíamos exigir a nuestros clientes que ingresen claves de licencia largas, que son tediosas de ingresar y difíciles de rastrear, es decir, se pierden fácilmente. (¡Intente buscar "clave de licencia perdida" en Twitter!)
  3. Los clientes están acostumbrados a utilizar un correo electrónico / contraseña ; Creo que deberíamos hacer lo que la gente está acostumbrada a hacer para poder ofrecer una buena experiencia de usuario (UX).

Por supuesto, si no desea manejar cuentas de usuario y desea que sus usuarios ingresen claves de licencia, está completamente bien (y Keygen también admite hacerlo ). Solo estoy ofreciendo otra forma de manejar ese aspecto de las licencias y, con suerte, proporcionar una buena experiencia de usuario para sus clientes.

Por último, dado que también mencionó que desea actualizar estas licencias anualmente, puede establecer una duración en sus políticas para que las licencias "completas" caduquen después de un año y las licencias "de prueba" duren dos semanas, lo que requiere que sus usuarios compren una nueva. licencia después de la expiración.

Podría profundizar más, asociar máquinas con usuarios y cosas así, pero pensé que trataría de mantener esta respuesta breve y centrarme en simplemente otorgar licencias de funciones a sus usuarios.

ezekg
fuente
0

Compruebe esta respuesta: https://stackoverflow.com/a/38598174/1275924

La idea es utilizar Cryptolens como servidor de licencias. Aquí hay un ejemplo paso a paso (en C # y VB.NET). También adjunté un fragmento de código para la verificación de clave a continuación (en C #):

var licenseKey = "GEBNC-WZZJD-VJIHG-GCMVD";
var RSAPubKey = "{enter the RSA Public key here}";

var auth = "{access token with permission to access the activate method}";
var result = Key.Activate(token: auth, parameters: new ActivateModel()
{
    Key = licenseKey,
    ProductId = 3349,
    Sign = true,
    MachineCode = Helpers.GetMachineCode()
});

if (result == null || result.Result == ResultType.Error ||
    !result.LicenseKey.HasValidSignature(RSAPubKey).IsValid())
{
    // an error occurred or the key is invalid or it cannot be activated
    // (eg. the limit of activated devices was achieved)
    Console.WriteLine("The license does not work.");
}
else
{
    // everything went fine if we are here!
    Console.WriteLine("The license is valid!");
}

Console.ReadLine();
Artem
fuente