O.T. ejecutable con tiempo de caducidad.¿Alquien me ayuda?

[Pedro]

Hola a todos

Perdonad que haya extractado el título pero no me cabía entero, y el off topic.
Veamos si alguno me ayuda, pues lo que quiero es saber como se hace para que un ejecutable tenga una validez de un periodo de tiempo.
Vamos en pocas palabras un trial de 30 días de esos que abundan por internet.

¿Alguien me puede tirar unos deditos?

Si lo considera necesario puede enviarme la ayudita a mi correo y así no molestamos al foro.

[Antonio Linares]

Pedro,

Aqui tienes una conversacion interesante al respecto y con bastantes buenas ideas:

http://stackoverflow.com/questions/1871212/implementing-expiration-dates-in-an-application/1871231#1871231

Basicamente se resumiria en:

1. Tener un fichero cuya fecha es la fecha de instalacion o anotar esta fecha en el registry de Windows (opcionalmente encriptada)

2. Calcular la diferencia desde la fecha actual a esa fecha anotada.

3. En caso de que el usuario reinstale, la anotacion en el registro sirve para saber que ya se instalo previamente.

[Pedro]

Gracias Antonio

Nos pondremos manos al Google translator y a ver que es lo que nos sale.

[elvira]

Pedro,

El problema es que hay programas que monitorizan el reigstro de windows, localizarán ese cambio cuando instalas tu software, avisan al usuario y permiten borrar la clave, con la que la reinstalación infinita es posible.

Saludos

[Antonio Linares]

Como ayer leí al buscar esa información para Pedro:

"los sistemas de protección ayudan a los usuarios honestos a ser honestos y con eso es suficiente"

porque efectivamente todos los sistemas de protección son vulnerables

[Pedro]

Amigos, no hay nada, o casi nada, que sea invulnerable en informática, pero al menos, a los menos honestos les pondremos algunas trabas para que no les sea tan fácil robar el trabajo de otros.

[lucasdebeltran]

Pedro;

Mira éste:
http://www.oreans.com/themida.php

[MarioG]

Pedro;
Te paso una idea que la implemente ya hace años (si alguien logró quebrar... hasta ahora no me contó )

Code: Select all  Expand view  RUN

METHOD ChkArr33() CLASS TMGSesamo

   // Serás DEMO por 33 dias
   IF File( ::cArchLyP:= GetWinDir()+"\dmi&d.cfg" )
      // Restauro array para demos
      if ( ::nPos:= ::Restaura() ) == 0
         // Agrego ArchArray
         aAdd( ::aSesamoIni, {Encrypt( ::cAppName ), Array( _ARRSSMO ) } )
         ::nPos:= Len( ::aSesamoIni )
         ::ArrConfigDm()
         ::GuardaArr()
      end

   ELSE
      // Genero ArchArra[code][/code]y
      ::aSesamoIni:= { {Encrypt( ::cAppName ), Array( _ARRSSMO ) } }
      ::nPos:= 1
      ::ArrConfigDm()
      ::GuardaArr()

   END

   ::aSesamo:= ::aSesamoIni[::nPos,_SUBARR]

   return( nil )
// Fin

La primera vez que se ejecuta la aplicacion busca: GetWinDir()+"\dmi&d.cfg" (en la carpeta windows. Aunque en Windows7, por el tema permisos, lo guarda dentro del perfil del usuario en la carpeta "VirtualStore").
Como verás tengo un nombre de archivo (que guarda arrays ), bastante dificil de interpretar como para andar manipulando. Lo otro es que el array se guarda con sus items encriptados:

Code: Select all  Expand view  RUN

  METHOD ArrConfigDm()             INLINE  ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniSerUUID] := Encrypt( ::SerialProtect() ), ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniSerExa]  := Encrypt( "" ), ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniExpDmo]  := Encrypt( DtoC( Date() +33 ) ), ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniFeCtrl]  := Encrypt( DtoC( Date() ) )    , ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniFeExpAb] := Encrypt( DtoC( Date() +33 ) ), ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniUsuario] := Encrypt( "INVITADO" )        , ;
                                    ::aSesamoIni[::nPos,_SUBARR,IniVersion] := Encrypt( GetFileVersionInfo( ::cAppExe,_APP_VERS ) ), ;
                                    ::aSesamoIni[::nPos,_SUBARR,InieMeGe]   := Encrypt( _KEYCRYPT ), ;
                                    nil
 

Uno de los items: ::aSesamoIni[::nPos,_SUBARR,IniExpDmo] := Encrypt( DtoC( Date() +33 ) )
guarda la fecha de instalacion + 33 dias. De manera que en cada ingreso lo va evaluando con la fecha de instalación, guardada en: ::aSesamoIni[::nPos,_SUBARR,IniFeCtrl]
De manera que "si el picaro" cambia la fecha del sistema, no afecta al control y a los 33 días, de su instalación, caduca.

Lo otro tambien interesante, es el control de una aplicacion "legal" mediante: ::aSesamoIni[::nPos,_SUBARR,IniSerUUID] := Encrypt( ::SerialProtect() )
Código libre que alguien dejo en el foro:

Code: Select all  Expand view  RUN

//-------------------------------------------------------------------------- \\
//     Identificador de PC del Usuario
//
METHOD SerialProtect() CLASS TMGSesamo
local oLoc := CreateObject( "wbemScripting.SwbemLocator" )
local oSrv := oLoc:ConnectServer(,"root\cimv2")
local aDrives := oSrv:ExecQuery( "SELECT * FROM Win32_ComputerSystemProduct" )
local oDrive, ;
      aData   := {}, ;
      cSerial := "", ;
      nLen    , ;
      nAT

   for each oDrive in aDrives
      aAdd( aData, oDrive:UUID )
      //? ALLTRIM((oDrive:Name)) Nombre de Placa madre
   next
   nLen:= Len( aData )

   For nAt := 1 to nLen
      cSerial += Upper( AllTrim( cStr( aData[nAt] ) ) )
   next nAt

   return( cSerial )
// Fin
 

O ea esto uso, mediante un Dialog de Instalación, al momento de instalarse el soft legal

Que lo disfrutes!
Saludos

[Pedro]

Bueno, gracias a todos, empezaré a ordenar las ideas y a ver que aclaramos.

[FranciscoA]

Hola Pedro.
Una pequeña sugerencia: No concentres la seguridad en una sola function o procedimiento. Así es fácil "by-pasear" con un jmp. También podrías limitar el número de registros en tus tablas, hacer comparaciones de cadenas por el nombre del cliente, y del programa, borrar "algo" cuando se vence el demo, etc. Cada una de estas en funciones diferentes, y en partes diferentes de tu software, usar timers.
Solo son ideas.
Saludos.

[Joaquim Ferrer]

Los sistemas de protección nunca son 100% fiables como comentais, por eso utilizo una técnica que no guarda ningun fichero, ni registro ni nada, simplemente, hago que el usuario le sea excesivamente molesto poder seguir utilizando el programa en version demo.
Existe una directiva ansi del preprocesador de C llamada __DATE__, que es la fecha de compilación del exe.

Code: Select all  Expand view  RUN

#define BUILD_DATE  substr(__DATE__,7,2) +"-"+ substr(__DATE__,5,2) +"-"+ substr(__DATE__,1,4)
 

Luego en el programa o sistema que queramos implementar, necesitamos que TODAS las ventanas (define window) se definan en una misma función. Si se trabaja con metodología orientada al objeto,
mucho mejor, ya que por ejemplo, si clientes, articulos, facturas, etc, heredan de una clase programa, en dicha clase se puede implementar el metodo general para la apertura de la ventana SDI o MDI para todas las hijas.
Como ejemplo, parte del codigo de activación para cada ventana

Code: Select all  Expand view  RUN

METHOD Activate() CLASS TProgram

 _date()
 
  DEFINE WINDOW ::oWnd MDI TITLE ::cName
....
 

De esta forma lo que se pretende es que cada ventana de cualquier mantenimiento o proceso, necesariamente pase primero por la funcion _date(), que va a comprobar la fecha actual del sistema
con la fecha de compilación + los dias de la demo y si es superior, abortar la ejecución.
¿ Que pasa si el usuario se da cuenta y cambia la fecha del sistema antes de entrar en el programa y una vez dentro la vuelve a cambiar ?
Pues que quizá podrá abrir alguna ventana, pero a la siguiente, el programa lo volverá a echar. Si el programa tiene un apartado de facturación, se le hará tedioso ir cambiando de fecha cada vez.
En muchos apartados de contabilidad o facturación, los programas suelen tomar la fecha del sistema (apuntes,facturas,albaranes,etc) si el usuario utiliza una fecha distinta a la real, para poder
acceder al programa, tendrá que introducir manualmente un montón de fechas y se le hará bastante duro y si es a final de año, con el nuevo ejercicio ya se le hará mas dificil.

Code: Select all  Expand view  RUN

function _date()
 local dDate := date()
  if dDate > ctod(BUILD_DATE) + 60  // 60 dias de prueba
     ? "La version demo ha expirado"
     QUIT
  endif  
return( dDate )
 

Por si te sirve la idea, el tema es hacerlo difícil ya que muchos usuarios no pensaran en cambiar la fecha al sistema e incluso alguno se pierda en el registro de windows buscando la desprotección.
De todas formas, hoy en dia casi es mejor que usen tu programa sin ninguna protección, y cuanta más gente mejor y ya sabes, windows no hubiera llegado a lo que es si no se hubiera dejado copiar

[Antonio Linares]

Totalmente de acuerdo con la observación de Joaquim

La táctica de Word para vencer a WordPerfect fué no poner protección de copia, mientras que WordPerfect la tenia

[lucasdebeltran]

Claro, pero nosotros (al menos en la empresa en la que trabajo) no somos, ni de lejos, Microsoft .

[Pedro]

Estimado Joaquim, sin menospreciar lo que has escrito, que me parece de una lógica aplastante, me gustaría que me digas cómo resolver el que alguien se baje tu programa demo, por ejemplo, 61 días después de su compilación, cuando tu has dado sólo 60 días de pruebas.
A menos que estés todos los días compilando y subiendo el programa a la web, tengo la sensación de que esa forma tuya nunca alcanzará el resultado previsto, debido a los días que pasen desde que compilaste y subiste el programa hasta que lo descargue el futuro usuario.
Otro ejemplo. Compilas el 30-05-2013 y subes el programa. Ofreces 90 días de prueba. Me bajo tu programa el 23-08-2013 lo pruebo, me gusta y quiero ver su comportamiento en 60 días con más datos. No podré verlo pues el 28-08-2013 habrá finalizado el plazo de los 90 días.
Estoy más de acuerdo con el tema de la fecha de instalación.
Tampoco deseo que la demo sea tan rígida que no se pueda hacer nada, (para ello dejo sólo las pantallas, rellenándolas automáticamente y así el usuario no puede hacer nada)
pero no hablamos de eso, si no de ponérselo un poco difícil al que quiere todo gratis de internet, máxime cuando puede tener una copia sin restricciones por poquísimo dinero.
Aunque ya sabemos lo que hay...lo gratis es gratis, lo demás hay que comprarlo, y eso cuesta dinero.

[cnavarro]

Pedro
Yo hace tiempo, lo que hacia era que en una base de datos "auxiliar" grababa la primera vez que se ejecutaba la fecha codificada
Ademas, esa base de datos ya quedaba con la fecha de modificacion en el SO
En la instalacion modificaba la fecha del ejecutable ( no encuentro como lo hacia )
Si borraban ejecutable y base de datos auxiliar siempre me quedaba la fecha y hora de ultima modificacion de resto de las bases de datos que se abrian y grababan y si era inferior a la de la base de datos y ejecutable, ya estaba el tema
El resto, lo que hacia era en mis rutinas de apertura y grabacion de bases de datos comparaba con esas fechas y valoraba la situacion.
En la version de prueba, no dejaba introducir mas de 20 o 30 registros en cada base de datos
Si encuentro el codigo que utilizaba te lo envio, aunque las rutinas de apertura, consulta y grabacion en mi caso eran unicas
Espero te pueda servir alguna de las ideas que te propongo.
Saludos