Saltando y Asegurando los Periodos de prueba en el Software
Una gran mayoría del software pago (shareware) que encontramos para nuestros equipos, utilizan como parte de su estrategia de mercadeo versiones de prueba para sus productos, con con ellas podemos ver su funcionamiento por un periodo de tiempo determinado antes que decidamos comprarlo, muchas veces estas versiones de prueba cuenta con todas las funcionalidades del software pero con alguna limitante como el tiempo que podemos usarlo o el numero de veces que podemos ejecutarlo.
Hoy hablaremos de los periodos de prueba, cómo podemos evadirlos y como desarrollarlos adecuadamente, para que cumplan con la función para la que fueron programados, algo muy necesario ya que es común ver como los desarrolladores usan por ejemplo la fecha del sistema operativo como dato confiable en sus códigos y con base en ella realizan las respectivas limitaciones de sus productos, esto es una mala practica ya que la fecha del sistema es fácilmente modificable por el usuario, por lo tanto no podemos confiar solamente en ella, veamos por que...
Saltando los Periodos de prueba en el Software
Supongamos que tenemos un producto XYZ y queremos que nuestros posibles clientes lo prueben solo por 8 días y luego tengan que comprarlo para poder utilizarlo, lo instalamos hoy 20/12/2010 y si todo sale como el desarrollador lo pensó el software dejaría de funcionar el 28/12/2010... pero siempre como desarrolladores debemos pensar que el usuario es malo, si tenemos siempre presente ese pensamiento podremos mejorar ampliamente la seguridad de nuestros desarrollos, validando toda la información que ingresa o que puede modificar, ahora imaginemos que antes de instalar nuestra versión de prueba, el usuario cambia la fecha del sistema al 21/12/2012 (ya que si se acaba el mundo, no necesitara mas nuestro software jejejeje), el sistema validara como fecha en la que termina el periodo de prueba el 28/12/2012, cierra el programa, pone de nuevo la fecha actual en el sistema y que pasa?... si el sistema esta mal implementado (como sucede con la mayoría de productos que he probado) nos dará un periodo de prueba por 733 días, en vez de los 8 que teníamos pensado.
De este problema no se salva ningún sistema operativo, encontrando fallos en software tan famoso y polémico como Smurfs' Village de CAPCOM para iOS, un juego tipo "FarmVille" inspirado en los Pitufos, que es gratuito pero su modelo de negocio es que compremos pituficerezas (smurfberry), para evitar largas esperas en el crecimiento de nuestras cosechas y construcción de edificios, como podrán imaginarse haciendo uso de la multitarea, podemos ir a las preferencias de nuestro iPhone, iPod Touch o iPad y cambiar la fecha del sistema para que la espera de horas o días, se reduzca a unos cuantos segundos. Pasando de esto...
A esto en solo unos minutos...
Lo mismo pasa con Camtasia para Mac OS, si adelantamos la fecha del sistema en la instalación de Camtasia, lo iniciamos y luego volvemos a poner la fecha actual, pasa algo como esto...
Windows tampoco se salva de este problema, existiendo incluso software que permite automatizar el procedimiento para que cuando se inicie un programa especifico, se cambie la fecha del sistema solo para este programa, sin cambios aparentes para el resto de programas, una de las herramientas utilizadas para realizar esta función es Cracklock, que desde hace mas de 10 años y según su descripción, permite eliminar el virus "30th day" que te impide utilizar el software después de pasado X tiempo (guiño 😉 guiño).
Otros desarrolladores hacen uso del registro en windows, archivos en mac o una combinación de ambos, para limitar por ejemplo el numero de veces que se puede ejecutar antes de comprar un software, esto puede ser un poco mas tedioso de identificar, pero igual podemos utilizar herramientas como RegeMon, FileMon o la reciente integración de estos 2 ProcessMon, para intentar saber donde esta guardando esta información el software y deducir que tipo de protección utilizado para el periodo de prueba.
Monitor de Procesos, Archivos y Registro
En alguna ocasión vi como un software contable, utilizaba la fecha de creación de su ejecutable para validar su periodo de prueba, bastaba con usar la famosa herramienta antiforense Timestomp, para cambiar esta fecha y modificar a nuestro favor el tiempo que duraba este periodo de prueba.
Si empiezas a experimentar con esto de los periodos de prueba o las limitaciones del software por tiempo, seguramente te puedes encontrar con aplicaciones en las que te sea muy complejo descubrir como realizar sus validaciones, pero no todo esta perdido, para estas situaciones podrías utilizar herramientas como SandBoxie que te permite ejecutar el software dentro de una caja de arena, utilizarlo y al cerrarlo, la caja de arena será limpiada haciendo que el software quede "detenido en el tiempo", ejecutandose siempre como si fuera la primera vez...
Asegurando los Periodos de prueba en el Software
Ya vimos algunos de los métodos utilizados para saltar los sistemas de protección del software, ahora veamos la otra cara de la moneda, dando algunos consejos a los desarrolladores para que los periodos de prueba que utilicen en sus productos, cumplan adecuadamente su tarea.
- No introduzcas todas las funcionalidades del software en tu periodo de prueba o por lo menos limítalas.
Es uno de los errores mas comunes cometidos por los desarrolladores, la idea de un periodo de prueba es darle una pequeña muestra de tu software al posible cliente, si con la versión de prueba pueden resolver su problema.. para que te van a comprar el producto?, si limitas las funcionalidades del software, recuerda que debes anunciarle al posible cliente que esta limitante quedará eliminada tan pronto compre el producto. - Valida la fecha con servidores externos.
Como puedes ver la fecha del sistema es fácilmente modificable, si es posible valida la fecha actual con un servidor externo, para que tu software no se ejecute mas tiempo del necesario para motivar al cliente de comprar el producto... ese es el motivo de los periodos de prueba ¿no?.. el inconveniente es que necesitarían una conexión a internet pero ¿quien no la tiene en estos días?. - Combina las Validaciones
Si puedes combinar las fuentes donde sacas la información para validar tus aplicaciones, registro, archivos, servidores externos, hazlo. - Impide la ejecución en Maquinas Virtuales
Esta es una decisión que podría afectar a clientes verídicos, pero puedes impedir que tu aplicación se ejecute en maquinas virtuales y cajas de arena, anunciando que la versión de prueba no permite esta función, pero con la versión completa no tendrán ese problema.
Compartenos la medida de aseguramiento agregarias a la lista? o un metodo que has utilizado para saltar alguna de ellas...