Como seguramente sabes, una aplicación se llama “shareware” cuando se permite probarla antes de comprarla. El interesado puede instalarla en su computadora y durante un tiempo “x” (por ejemplo: 30 días) o una cantidad de ejecuciones predeterminadas (por ejemplo: 25 ejecuciones) puede usarla, generalmente sin más limitaciones.

La ventaja para el desarrollador es que muchas personas pueden evaluar su aplicación y por lo tanto la cantidad de ventas potenciales se incrementa muchísimo. La ventaja para el usuario es que puede probar la aplicación antes de comprarla y gastará su dinero solamente si está convencido de que le será útil.

En Firebird tenemos la posibilidad de hacer nuestras bases de datos “shareware”, o sea que podrán conectarse a ellas durante “x” días o durante “n” veces.

Veamos los dos casos:

Caso 1. Shareware que puede usarse durante “x” días

Aquí, el usuario puede intentar un truco para evitar que llegue la fecha de vencimiento: cambiarle la fecha a su computadora.

Por ejemplo, un usuario “astuto” podría hacer lo siguiente: instala hoy la aplicación y como sabe  que vencerá a los 30 días, mañana le cambia la fecha a su computadora para que sea igual a la de hoy, ejecuta la aplicación “shareware” y cuando finaliza pone la fecha correcta en su computadora. En otras palabras, si instaló la aplicación el 23 de enero de 2014 entonces siempre antes de ejecutar la aplicación le cambia la fecha a la computadora para que se muestre 23 de enero de 2014. Cuando terminó de ejecutar la aplicación “shareware” le pone a su computadora la fecha correcta. De esta manera podría ejecutar la aplicación “shareware” no durante 30 días como está estipulado sino durante muchos años.

Caso 2. Shareware que puede usarse “n” veces

Aquí, el usuario puede intentar otro truco para ejecutar la aplicación “shareware” indefinidamente: copiar el archivo original.

Un usuario “astuto” puede mirar las fechas de los archivos que instaló la aplicación “shareware” para detectar si la fecha de alguno de esos archivos va cambiando, de ser así, ese puede ser el archivo donde se guardan la cantidad de ejecuciones. Supongamos que descubrió que la fecha del archivo DATOS.TXT cambia cada vez que se ejecuta la aplicación “shareware”. Entonces renombra a DATOS.TXT y copia el archivo DATOS.TXT original, por ejemplo el que descargó de Internet. Como en el archivo DATOS.TXT original la cantidad de ejecuciones es cero, cada vez que copie el archivo original DATOS.TXT el contador de ejecuciones volverá a cero y podrá utilizar la aplicación “shareware” todas las veces que quiera.

¿Cómo evitar los trucos de los usuarios?

En primer lugar hay que aclarar que si el programa .EXE puede ser decompilado entonces ninguna protección será buena porque luego de la decompilación podrán ver el código fuente y desactivar cualquier protección, por más elaborada que sea.

El código fuente de cualquier aplicación puede ser visto en Assembler así que ante un muy buen programador en Assembler nada se puede hacer. Te desprotegerá sí o sí tu aplicación. Una muestra tangible es que se puede “piratear” Windows, Office, y muchas otras aplicaciones populares las cuales los desarrolladores tratan de proteger al máximo pero nunca pueden tener éxito contra los buenos programadores de Assembler.

Pero si la aplicación que desarrollaste no es el gran “boom” entonces es probable que nadie se tome demasiado trabajo en intentar desactivarle las protecciones y por lo tanto tendrás una protección razonable ante la grandísima mayoría de los usuarios.

Bases de datos “shareware” de Firebird

Gracias a una muy buena característica del Firebird podemos hacer aplicaciones “shareware”. Como hemos visto antes, la protección no será infalible pero sí detendrá a la gran mayoría de los usuarios tramposos.

Esta característica es que los triggers y los stored procedures se guardan de dos formas dentro de la Base de Datos: como código fuente y como código compilado. Y si se borra el código fuente no hay problema, porque el Firebird utiliza el código compilado para la ejecución.

Es muy elemental (creo que eres muy inteligente y no debería decirte esto) que guardes el código fuente por si alguna vez necesitas modificarlo, lo cual seguro que ocurrirá más tarde o más temprano. O sea, las Base de Datos que se instalan en las computadoras de tus usuarios solamente tienen código compilado, no tienen código fuente. En cambio la Base de Datos que tienes en tu propia computadora tiene ambos: el código fuente y el código compilado.

Supongo que ya te imaginarás lo que se debe hacer: escribir la protección en un trigger (preferentemente) o en un stored procedure, compilar, copiar la Base de Datos, a la Base de Datos copiada borrarle los códigos fuentes, y esa Base de Datos que no tiene los códigos fuente instalar en las computadoras de los usuarios.

En el siguiente artículo mostraré una técnica para conseguir tener bases de datos “shareware”, hasta aquí solamente es la explicación teórica.

Artículos relacionados:

Como proteger los stored procedures, triggers y relaciones

El índice del blog Firebird21