¿Cómo puedo hacer que mi producto sea una versión de prueba por 30 días?

He creado mi producto y también he generado una clave de licencia para eso, pero quiero pedir esa clave luego de 30 días. tengo que hacerlo con el valor de registro almacenando la fecha con la adición de 30 días en eso. pero encontré que si el usuario cambia la fecha del sistema con 30 días antes de que mi lógica no funcione.

Entonces, ¿hay alguna solución para el software de la versión de prueba sin verificar la fecha del sistema y permitir solo 30 días de prueba?

Puede tener otra clave de registro que incremente después del uso diario. De esta forma, incluso si cambian la fecha de la computadora, esta tecla indicaría a su progtwig que ha estado funcionando durante> 30 días.

Además, este valor podría cifrarse de modo que si el usuario intenta cambiarlo manualmente, el progtwig puede negarse a ejecutarlo porque no pudo descifrar el valor y obtener un número válido de él.

Para evitar las reinstalaciones, puede agregar cierta información a cualquier archivo guardado con la versión de prueba de su aplicación, que es exclusivo de esa versión específica de la aplicación (quizás una marca de tiempo desde el momento en que se instaló). Cuando una versión de prueba de su aplicación intente abrir un archivo, comprobará esta firma y se asegurará de que se haya creado con la misma instancia; de lo contrario, se rehusará a abrir el archivo. Esto esencialmente neutraliza la capacidad de simplemente reinstalar la aplicación y continuar usándola.

Sin embargo, al final del día, el usuario tiene control total sobre su máquina y probablemente pueda encontrar la forma de hacerlo (a menos que tenga acceso a un servicio web donde se guardan estos detalles antes de permitir que el usuario use la aplicación). ) Probablemente no deberías gastar tanta energía tratando de detener a los muchachos que están dispuestos a pasar por este problema adicional, sino que gastarán ese tiempo extra / dinero / energía mejorando la aplicación para aquellos que estén dispuestos a pagar.

Puede usar un componente de licencia. Puede hacer uno usted mismo (consulte la clase LicenseManager ), o compre uno de un proveedor (por ejemplo, CryptoLicensing ).

Tengo una solución simple para ti.

Tome 2 variables para el registro: 1. fecha 2. contador

pasos:

  1. Establecer un contador = 1

  2. Copiar fecha del sistema hasta la fecha

  3. Verifique cada vez si la fecha es diferente a la fecha actual, luego copie esa fecha en la fecha de registro, también incremente el contador en 1. Si la fecha es la misma, no haga nada.

  4. Ahora puede verificar su contador para el vencimiento de los días de prueba

Mediante el uso de este truco, si el usuario cambia la fecha del sistema a la fecha anterior que también funciona.

¡Para el registro puede encriptar la fecha y el contador para que la persona técnica no reconozca su lógica!

aclamaciones…

ADICIONAL

¡Esta lógica falla solo cuando el usuario no cambia la fecha de cada día! Nuevamente tenemos la solución para eso!

No sé si es posible o no, pero siempre puedes tener alguna solución:

  1. cuente el tiempo total para el período de prueba y guárdelo en el registro.
  2. Ahora cuente el tiempo total de cada ejecución y agréguelo a otra variable. (Espero que se pueda hacer por temporizador)
  3. Compare los dos valores anteriores para tomar la decisión de vencimiento.

Debe tener una forma de detectar si el usuario cambia la fecha desde la primera vez que inició la prueba. En las soluciones que he usado anteriormente, hemos guardado la fecha de “última ejecución” y la fecha de “primera ejecución” y si el reloj cambia a algo más de dos días de “última ejecución” vencemos la prueba. También necesita un contador de “días ejecutados” para que no puedan seguir moviéndose la fecha de hace dos días (se olvidó de mencionar esa parte): el contador se incrementa en cada ejecución.

Por supuesto, los sistemas de licencias de software como este siempre se pueden evitar desinstalando y volviendo a instalar con la actualización adecuada del registro: el truco es ofuscar y duplicar la información de licencia lo suficiente como para dificultar esto, pero finalmente se lo encontrará (especialmente si utilizando una base de código .Bus no obstruida).

Difícil de procesar 30 días sin referencia a la fecha / reloj del sistema. Siempre puede mantener una lista de las fechas en que se inició la aplicación y contar 1 por cada vez que fue diferente de la última vez. De esta forma, su usuario debería establecer la misma fecha cada vez que active su aplicación.

Aparte de eso, podría, siempre que hubiera acceso a Internet, consultar un servidor de buen tiempo conocido para la fecha actual. Esto podría evitarse mediante la desconexión, pero siempre podría exigir una conexión a Internet antes de que se inicie su aplicación.

Por último, una fuente de tiempo local y externa a través de un dongle de hardware o similar, pero creo que estás llegando al extremo en el que sería mejor que gestiones directamente los ensayos en persona.

SI puede garantizar una conexión a Internet, puede implementar un esquema en línea (consulte un servidor de tiempo o su propio servidor de autenticación). Por supuesto, eso introduce otra dependencia: si Internet se va, tus usuarios no podrán trabajar.

En última instancia, diría que comprar una solución de licencia de terceros: todavía no es irrompible, pero probablemente será más sólida que algo que puede hacer usted mismo sin mucho tiempo y esfuerzo.

Almacene la última fecha de ejecución, y cada vez que la fecha del sistema sea anterior a esa, expire la prueba.

El único método a prueba de fallas es validar la aplicación contra un servicio que usted aloja, suponiendo que nadie descifró su código de conexión;)

Siempre que puedan borrar el valor de registro / archivo de almacenamiento aislado / configuraciones guardadas: pueden simplemente reiniciar la versión de prueba. No hay mucho que puedas hacer al respecto. Es por eso que las personas optan por una funcionalidad reducida en el software de prueba, además de un período de prueba basado en el tiempo.

Si es aceptable permitir, digamos, 8 horas de uso de prueba (en lugar de una prueba de 30 días), entonces una forma de eliminar la dependencia del sistema DateTime es mediante el uso de un temporizador en la aplicación que se activa cada minuto. Cuente estos y así cada vez que se ejecute la aplicación, acumulará un recuento total de minutos de uso. A continuación, puede almacenar este valor de recuento en algún lugar, como en el registro.

Es una fecha de finalización simple para la evaluación de la tienda y la verifica todos los días. Para evitar el uso prolongado por manipulación de la fecha, mantenga un recuento de horas en la aplicación; sigue incrementándolo y escribiéndolo en el registro. Se debe hacer un chequeo tanto contra la fecha de finalización de la evaluación como contra el recuento de horas que no exceda 24 (puede ser 30 con cierta teolencia).

Piensa también en:

Guardando el DateTime del cierre de la aplicación, la próxima vez que se lance su aplicación podrá detectar si la configuración de Datetime fue modificada o no (al menos no pueden cambiarla antes a la hora de cierre). Ejemplo:

En el cierre de la aplicación:

Ahorro de tiempo => 15:34 31/03/2014 (guardado)

Siguiente inicio de la aplicación:

Consulte Datime.Now> 15:34 03/31/2014. (para que no puedan ir más abajo que …)

ADICIONAL :

Intente de alguna manera integrar la configuración de fecha y hora del sistema en el uso de su aplicación: generación de facturas, tickets, recibos … ¡lo que sea!

Puedes usar el proyecto gratuito Libprot. El sitio es https://github.com/libprot/trunk .

La idea es que debe ser simple y fácil de usar. Puede gastar $$$ en protección pero puede ser pirateado en una semana. Si alguien quiere hacer ingeniería inversa de su código, entonces nadie puede detenerlo. Mi consejo es usar métodos simples que funcionen.

Escribe una cadena como:

Empresa X | 10.2.2014 | 1.12.2015

donde el 10.2.2014 es la fecha actual y si la hora del sistema es menor, entonces alguien cambió el reloj del sistema => no deberíamos ejecutar

1.12.2015 – hasta qué hora la clave es válida

y nombre de la compañía que lo compró / descargó.

esa cadena debe estar ofuscada con un algoritmo asimétrico con clave privada / pública y codificada en una cadena que puede enviarse por correo electrónico, por ejemplo.

es posible que también desee tener algún servicio web para validación. cuando la conexión a Internet está activada, puede validar la clave; si está pirateada y disponible para el público en Internet, puede prohibirla. O si alguien escribiera el generador de claves, puede validar que esa clave es real.

puede agregar algunas secuencias de comandos PHP / java en su sitio para enviar automáticamente códigos de prueba.