Para ilustrar el tema con ejemplos prácticos, nos hemos dado una vuelta por uno de los repositorios de mayor audiencia, la Torry's Page, y hemos seleccionado unos cuantos productos VCL (componentes o paquetes de componentes) shareware, compatibles con Delphi 4 o 5, que decían estar limitados con este tipo de protección.

Antes de continuar, recuerda en todo momento que este tutorial NO está pensado para enseñarte a robar, sino para ofrecerte otra cara más del mundo de las protecciones de software y, en el caso de que seas programador de este tipo de material, darte ideas para mejorar la codificación de tus protecciones en un futuro.

Los productos anteriormente citados han sido elegidos al azar, intentando coger un poco de todo para podernos hacer una idea más o menos fiable de cuál es el panorama actual en lo que se refiere a protecciones de este tipo.  Los hay buenos y los hay menos buenos, los hay muy caros y los hay muy baratos, y sus funciones varían desde la programación de aplicaciones multimedia hasta la transmisión de mensajes cortos.

Y un mensaje para los autores “afectados”.  Aunque haya algún que otro estúpido que opine lo contrario, soy de la opinión de que tutoriales como éste no sólo no perjudican a los autores de shareware, sino que en cualquier caso suponen una ayuda.  Si tu producto es bueno y competitivo no tienes nada que temer, aunque si no lo es, tal vez deberías estar ahora invvirtiendo el tiempo en mejorarlo en lugar de “perder” el tiempo leyendo este documento.

Y, por supuesto, otra nota para los lamers caza-cracks.  Aunque las protecciones de todos los productos mencionados están concienzudamente detalladas en este documento, no esperes encontrar ni un solo parche para ninguno de ellos, ni en un archivo adjunto a este texto ni en la sección de cracks de WKT.  Bastardos como vosotros son los que nos hacen la vida menos agradable a los +crackers honrados.

Sin más, empezamos.

Algo muy parecido obtenemos con el de Delphi 5:

Lo que aparece en estas capturas es, de izquierda a derecha, el icono, el handle, el título y el nombre de la clase, de cada ventana presente, visible o no visible, cuando el IDE está funcionado.  Sin fijarnos mucho, nos damos cuenta de que hay ventanas significativas comunes, y es precisamente su presencia la que utiliza el programador para saber si su componente está siendo utilizado desde dentro de Delphi o no, aunque no sea esta la manera más exacta de hacerlo, veremos más adelante el porqué.

Ilustraremos lo dicho anteriormente con algunos ejemplos ...

Aunque no hay nada en la documentación que lo diga notamos que, cuando ejecutamos el programa con Delphi arrancado, todo va perfecto.  Sin embargo, cuando no está Delphi presente, el programa nos muestra la siguiente ventana al arrancar:

Un vistazo al código desensamblado nos da lo siguiente:
 

No hace falta mucha imaginación para darse cuenta del papel que juega el flag apuntado por [5FBF00], ¿verdad?  Pero vamos a lo que nos interesa, cómo se produce el chequeo de la presencia de Delphi:
 

No nos podemos ir sin rematar la faena, y un parche elegante podría ser el siguiente:
 

Como siempre, el origen de la protección lo hallaremos en los archivos .DCU, localizándolo esta vez en el fichero dclib.dcu.

Nada más ejecutarlo (una vez apagado Delphi) aparece la siguiente ventana:

Nos tiramos a por un “crackeo muerto” y,  tras unos minutos de paciente espera,  W32Dasm nos regala un fichero de 35 Mb del cual rápidamente extraemos esta hermosura:
 

Bueno, sobran los comentarios, ¿no?   Busca cuatro de las ventanas de presencia obligada cuando el IDE de Delphi 4 está arrancado, y si no encuentra alguna de ellas, interrumpe la ejecución del programa.

Buscamos un parche elegante, por ejemplo:
 

Lo probamos y la demo corre perfectamente.  Sin embargo, nuestro trabajo no termina aquí, debemos localizar el código de chequeo en el fichero *.DCU de turno, para que el compilador nos proporcione ejecutables parcheados cada vez que compilemos.

Tras buscar un poco lo encontramos en el interior del fichero lmdclass.dcu.  Lo parcheamos de la misma forma que antes, recompilamos NewMegaDemo.dpr y probamos el nuevo ejecutable.  Ni rastro de la protección.  Probamos compilando un par de ejemplos más, y todo parece correcto.

Una vez fuera de Delphi, ejecutamos el ejemplo y obtenemos el siguiente mensaje:

(Sí, yo también me he fijado, se le habrá pasado actualizar aquí el número de versión.)
 

Echamos mano una vez más de nuestro inseparable W32Dasm para obtener rápidamente el siguiente trozo de código:
 

Una vez más, pensar en un parche elegante es lo único que nos ofrece la protección, ¿qué tal éste?:
 

¿Y el código original?  Pues esta vez le ha tocado comérselo al fichero ExportDS.dcu.

El único código que necesitamos escribir es una línea en el evento OnClick del botón:
 

Lo compilamos y ya estamos listos para “trabajar”.  Una vez Delphi terminado, ejecutamos nuestro ejemplo y obtenemos la siguiente ventana:

Siguiendo nuestro método habitual, echamos una ojeada al código desensamblado y obtenemos lo siguiente:
 

Supongo que, a estas alturas de la película sobra cualquier comentario.  Nuestro parche habitual para quedarnos satisfechos, por ejemplo, el siguiente:
 

Y, para terminar, esta vez no hay duda ninguna respecto a la localización del código original, ya que sólo existe un archivo DCU en donde buscar ;-).

que tras la compilación, se convierte en una monstruosidad llamada SALevels.exe, de 756.736 bytes.

Tras la primera ejecución, nos encontramos con el siguiente mensaje:

Un par de minutos después, ya somos capaces de encontrar la siguiente preciosidad:
 

Esto está empezando a resultar aburrido, ¿no?   Probamos un parche cualquiera (elegir el parche es lo más “excitante” que nos permiten protecciones como ésta),  por ejemplo:
 

Y, por si alguien siente aún alguna curiosidad, el código de chequeo original se encuentra en el fichero usersstd.dcu.

Salimos de Delphi y al ejecutar nuestro recién compilado ejemplo, obtenemos el siguiente mensaje:

y tras ésta, un mensaje de excepción del sistema que, cuando menos, nos causa una mala sensación.  Tras urgar entre el código desensamblado, obtenemos lo siguiente:
 

Sin comentarios, ¿no?  Intentemos uno de nuestro parches favoritos:
 

Y, como siempre, el origen de la protección lo buscamos en el interior de los archivos .DCU, siendo esta vez dos los ficheros en los que encontramos idéntico código:  Kpzipobj.dcu y VCLUnZip.dcu.

Probamos el parche, todo perfecto, parece que nuestro trabajo ha terminado.

Tras cerrar Delphi, ejecutamos el ejemplo.  Sin embargo, al contrario de lo que esperábamos, nos encontramos que el programa arranca de forma normal, sin ventanas de mensajes ni ningún otro rastro de protección.  Tras “jugar” un rato con el ejemplo y probarlo de arriba abajo, nos invade el aburrimiento al no ver nada “raro”, y nos largamos.  Aquí ocurre algo extraño, y sólo se nos ocurren las siguientes explicaciones:

1. Woll2Woll, en un alarde de valentía, se ha arriesgado con una estrategia peligrosa, la de meter miedo a clientes estúpidos con protecciones inexistentes.  (Y estúpidos, con todas las letras, tienen que ser si no prueban algo tan sencillo como ejecutar sus pruebas fuera de Delphi, ¿o me equivoco?).
2. La protección está oculta, y no aparece así sin más en cuanto ejecutamos cualquier cosa.
3. El equipo de Woll2Woll encargado de preparar este paquete en concreto se ha colado y ha metido una versión desprotegida.

Tras meditarlo medio segundo, descartamos desde ya la explicación (a).  Nadie (o casi nadie ;-) puede ser tan necio como para decir que su producto está protegido y luego venderlo desprotegido, y mucho menos “insultar” de esa forma a posibles futuros clientes llamándolos imbéciles a la cara.

La explicación (c) no es tan descabellada como pudiera parecer.  Sin embargo, no podemos descartar la opción (b) sin haber al menos indagado un poco, ¿verdad que no?

Estrategias a seguir, por orden según nos van viniendo a la cabeza:

1. Desensamblar “Demo1stClass.exe” y buscar llamadas a FindWindow o FindWindowEx.
2. Estudiar si el programa carga en algún momento DLL’s o módulos de algún tipo que no hayamos detectado a simple vista tras la instalación.
3. Estudiar si en algún momento de su ejecución el programa crea timers o threads, en los que puedan camuflarse bombas de tiempo y/o chequeos de IDE.

Si tras estudiar todo esto, los ejemplos que compilemos siguen funcionando bien, consideraremos el tema cerrado hasta nuevo aviso.  Todo tiene un límite, y tenemos mucho trabajo que hacer aún ;-).

Intentamos el desensamblado con W32Dasm, pero algo extraño ocurre, ya que el desensamblador se queda colgado sin terminar siquiera de cargar el ejecutable.  ¿La configuración de mi sistema? ¿tal vez trucos anti-W32Dasm?  Probaremos con IDA antes de llegar a conclusiones precipitadas.

Tras un par de minutos, obtenemos un fichero de 43 Mb con nuestro protagonista desensamblado.  Ni una sóla llamada a “FindWindow”, al menos explícitas que podamos detectar a simple vista.  Tampoco hay rastro de cadenas del tipo “Delphi” o “C++Builder”.  Guardamos el listado por si lo necesitamos más tarde, pero no perdemos más tiempo y vamos a por nuestro siguiente paso, buscar DLL’s.

Arrancamos el ejemplo y con ayuda de nuestra herramienta favorita obtenemos un listado de las DLL’s que el ejecutable carga de forma estática junto con él.  Obtenemos lo siguiente:

Dejando aparte las librerías del sistema (*.drv, *.dll) detectamos módulos de extensión .BPL.  Los archivos BPL, también llamados “paquetes” o runtime packages, no son más que DLL’s en cuyo interior se encuentra encapsulado código compilado relativo a componentes VCL de Delphi/C++Builder.  En la mayor parte de los casos, los programadores de Delphi compilan sus programas con la opción por defecto de “compilar sin paquetes”.  De esta forma, el ejecutable generado contiene en su interior todo el código necesario para desarrollar las funcionalidades ofrecidas de cualquier componente VCL que utilice.  Sin embargo, hay ocasiones (más de las que algunos piensan) en las que es conveniente cambiar la opción por defecto por la de “compilar con paquetes”.  Así, obtenemos ejecutables de dimensiones menores, además de disfrutar de ventajas adicionales,  pero no es éste el lugar ni el momento de extendernos, continuemos ...

Todos los “paquetes” cargados son paquetes VCL de los que se incluyen con Delphi 5. ¿Todos? No, no todos, y me imagino que sabemos cuál no lo es:  FirstClassTrial_d5.bpl.  Pocas dudas nos quedan ya, puesto que este hecho nos confirma que la segunda limitación descrita en la documentación tampoco se cumple:
 

No sólo podemos ejecutar el ejemplo de forma, al menos aparentemente, normal, sino que además lo podemos hacer sea cual sea el modo de compilación (con o sin paquetes) seleccionado.  No vamos a perder más tiempo, ya que todo apunta a nuestra tercera posible explicación, se han colado y parece que disponemos de una versión sin restricciones.

Tras salir de Delphi, ejecutamos el ejemplo y obtenemos el siguiente mensaje:

Como es habitual, indagamos entre el código desensamblado buscando las clásicas llamadas a FindWindow/FindWindowEx, sin embargo, ¡no encontramos nada!  Esto se pone interesante (por fin ;-), aunque son ya casi las 3 de la mañana y hay que madrugar ...
 

Una mini-sesión de Soft-ICE y localizamos rápidamente el código de chequeo:
 

Un poco largo, pero muy ameno ;-). 

Vamos a ver si analizamos de forma rápida lo que el programador ha hecho aquí, incluyendo alguna curiosidad:

1. Todos los nombres de las clases de ventana a buscar están encriptados.
2. La función FindWindowA no aparece de forma explícita, sino que es llamada calculando su dirección de rutina mediante llamada a la función del API GetProcAddress.
3. Por supuesto, lo mismo ocurre con GetProcAddress.  Aquí está una de las curiosidades, ya que para obtener la dirección de GetProcAddress se ejecuta explícitamente la propia GetProcAddress, aunque el nombre de la rutina necesario como parámetro también esté encriptado.
4. Para obtener las direcciones de GetProcAddress y FindWindowA, es necesario conocer los handles de las DLL’s a las que pertenecen, KERNEL32.DLL y USER32.DLL, respectivamente.  Una vez más, los nombres de estas DLL’s también están encriptados.
5. Por lo demás, el sistema es el ya conocido, buscar una serie de ventanas determinadas para ver si el IDE de Delphi/C++Builder está presente.  Sin embargo, aquí va otra curiosidad, ya que una de las clases de ventana que chequea es TApplication, chequeo que devolverá siempre TRUE si el ejecutable ha sido creado con el IDE de Delphi/C++Builder.

Para terminar, un parche para quedarnos satisfechos e irnos contentos a dormir, éste por ejemplo:
 

Y, cómo no, no nos podemos ir sin localizar el código original, que encontraremos en esta ocasión dentro del fichero Agent.dcu.

Al intentar ejecutarlo sin Delphi arrancado nos aparece el siguiente mensaje:

Con ayuda de nuestro depurador favorito, y un bonito punto de ruptura en FindWindowA, localizamos el chequeo en toda su plenitud:
 

Momento de parchear y probar.  Como casi siempre, se nos presentan múltiples soluciones, ahí va una de las posibles:
 

Parcheamos adecuadamente MMDEMO32.EXE,  probamos una nueva ejecución y nos encontramos con la siguiente ventana:

que no es más que el cuadro de Acerca de habitual con un timer que retrasa la rehabilitación del botón de OK.  Al pulsar OK nos encontramos con una ventana de IDE not found como la del principio, y a continuación el programa termina.  Efectivamente, el chequeo anterior no era el único, y poco tardamos en encontrar el siguiente, muy parecido al anterior:
 
 

Como casi siempre, se nos presentan mútliples soluciones, ahí va una de las posibles:
 

Momento de parchear y probar, de nuevo.  Esta vez, el código no se encuentra en el ejecutable, ¿tal vez en alguna DLL utilizada por éste?  Buscamos en MMUTIL32.DLL, pero no hay rastro de nuestro código ...  ¿estamos tal vez ante código encriptado?

Colocamos puntos de ruptura para detectar en qué momento el programa escribe en la zona de memoria donde se encuentra nuestro código, y encontramos finalmente lo siguiente:
 

La rutina desencripta una zona de memoria que va desde ES:FF9618 hasta ES:FF9C43.  Ante semejante panorama se nos presentan dos alternativas:

1. Hacer un volcado de memoria del bloque de memoria desencriptado, sustituirlo por el original encriptado, y anular la llamada a la rutina de desencriptación anterior.
2. Con ayuda de nuestro compilador favorito escribir un pequeño programa que encripte y desencripte un bloque de memoria siguiendo el algoritmo anterior, y generar un bloque encriptado que, al ser desencriptado por la rutina original nos genere el código de chequeo #2 perfectamente parcheado.

Si observamos con un poco de detenimiento la rutina anterior, nos daremos cuenta de que la desencriptación no se realiza contra una tabla byte a byte ni nada parecido (lo que nos facilitaría sustanciosamente la labor) sino que para la desencriptación de cada byte se utiliza el valor del byte anterior encriptado.  Teniendo esto en cuenta, y aunque más entretenida, olvidaremos para otro día la segunda opción, y nos tiraremos a por la primera.
 

Con ayuda de la excelente utilidad IceDump hacemos un volcado de la zona de memoria afectada tras la encriptación, con la intención de sustituirla físicamente por su equivalente encriptada.

Y hacemos lo propio tras la desencriptación:

Ahora buscamos el bloque encriptado (lo encontramos en MMUTIL32.DLL) y lo sustituimos por el desencriptado parcheado:

quedando la DLL así:

y, en concreto, la parte que ahora nos interesa, nuestro parche:

Ahora nos queda localizar la llamada a la rutina de desencriptación para anularla.  Una vez más, encontramos el código correspondiente en MMUTIL32.DLL:
 

Parcheamos adecuadamente MMUTIL32.DLL con una de las múltiples soluciones:
 

Ya estamos listos para probar nuestro segundo parche.  Una vez más, la misma ventana de About que antes, y es que, efectivamente, existe un tercer chequeo de existencia de IDE de Delphi.  Un nuevo punto de ruptura en FindWindowA y obtenemos el código del tercer chequeo:
 

Como casi siempre, se nos presentan mútliples soluciones, ahí va una de las posibles:
 

Esta vez tenemos suerte, ya que, aunque el código de este tercer chequeo estaba también encriptado, los programadores han sido tan amables de desencriptarlo de una sóla vez junto con el chequeo #2, de forma que lo encontramos perfectamente legible en MMUTIL32.DLL.  No nos queda más que ejecutar nuevamente y probar nuestro tercer parche.

El programa funciona perfectamente.  Probamos con un par de ejemplos cualesquiera y vemos que, aunque hayamos susituído la MMUTIL32.DLL original por la nuestra, aún es necesario parchear cada ejecutable producido para saltar el chequeo #1.

Parémonos un poco a pensar, intentando ponernos en el lugar del programador, y preguntémonos ¿dónde podríamos incluir nuestro código de chequeo para que cualquier ejecutable compilado con alguno de mis componentes lo incluya al arrancar?  Las respuestas pueden ser variadas, dependiendo de los conocimientos que posea el programador, del tiempo de que disponga, de lo vago que sea o de su grado de implicación con el producto.  La primera solución que suele venir a la cabeza es la de incluir todo el chequeo en la sección de inicialización de una unidad compartida, algo así como:
 

e incluir luego el uso de esta unidad en cada unidad correspondiente a un componente:
 

Con este uses garantizamos la ejecución del código de chequeo al comienzo de cada programa.

Nos bastan unos segundos para echar un vistazo a los ficheros *.DCU (pequeño recordatorio:  el compilador genera un fichero *.DCU con código compilado por cada fichero fuente *.PAS, el linkador se encargará de “copiar” de cada *.DCU el código necesario y ubicarlo en el ejecutable final) incluídos con el producto y nos encontramos con uno que, cuando menos, despierta nuestra sospechas:
 

Tentador, ¿no?.  Está pidiendo a gritos que le echemos una ojeada y busquemos en su interior el código del chequeo #1:
 

Efectivamente, dentro de MMUtils.dcu hay un código de chequeo idéntico a nuestro chequeo #1.  Probamos el mismo parche, sólo que esta vez lo hacemos sobre el *.DCU y no sobre el ejecutable. Compilamos un par de ejemplos más cualesquiera y, tras ejecutarlos,  nos damos cuenta de que estábamos en lo cierto.
 

Sin embargo, ¿qué hay del chequeo de 30 días del que se habla en el acuerdo de licencia?
 

Un vistazo al código desensamblado de MMUTIL32.DLL nos proporciona esta hermosura:
 

Si la función devuelve 0, nuestro período de evaluación ha terminado, y los programas nos muestran una ventana como la siguiente al arrancar:

Lo cierto es que, aunque durante nuestras pruebas nunca hayamos conseguido hacer que esta función devuelva 0, más nos valdría parchearla, por si las moscas.  Una solución rápida y “económica” podría ser la siguiente:
 

Sin más, un saludo y hasta la próxima, agur.