Desde mis inicios, hasta la época del shareware, es decir, cuando podía dedicarle tiempo (y mucho) a lo que realmente me llamaba la atención, había determinadas tareas que me encantanban.

En aquel momento no me lo había planteado, pero tenían mucho que ver con la programación de sistemas y la seguridad. Quizás por ser aspectos poco documentados y conocidos, que potenciaban la imaginación y el buscarse la vida de cada uno, el caso es que eran divertidos de poner en práctica.

Eran tiempos de ordenadores de 8 bits, o de DOS, plataformas que te dejaban gran libertad a la hora de hacer lo que quisieras. Ahora por ejemplo hay muchísima más información y herramientas, pero es prácticamente imposible para un principiante desarrollar algo que se parezca a una protección anticopia.

Protección anticopia, desprotección y copiones
A nivel usuario, ya en los tiempos del Spectrum, era de las primeras cosas que se aprendía. Algunos juegos podían copiarse, y otros no. Aquello me maravillaba, pero era incapaz de imaginarme como funcionaban. Pasó algún tiempo hasta que ya con el PC, y el vetusto GW-BASIC, hice una aproximación que a día de hoy resultaría trivial en base a archivos ocultos.

Unos años más tarde, desarrollaría mi primera protección anticopia seria. Nunca llegué a saber como de eficaz sería, porque no la incluí en ningún desarrollo, pero el concepto me parece ahora bastante actual. Básicamente obtenía características hardware del equipo, y las estampaba en el ejecutable, de manera que quedaba vinculado a la máquina donde se había instalado.

Sí que avancé algo más en las técnicas anti-depuración, desde Antidebug Library (ADLIB), que se hizo relativamente popular gracias a GARBO y SAC, hasta SCHECK, que sencillamente estampaba un checksum del ejecutable en la cabecera MZ, que era comprobado en cada arranque para detectar modificaciones.

Por supuesto en aquella época ya era capaz de entender las protecciones del mercado, e incluso era capaz de saltarme las más sencillas, a la vez que descubría multitud de herramientas existentes.

Compresión y descompresión de datos
Ya he contado alguna vez como descubrí RLE sin saber que ya existía ni que tenía ese nombre. En el Spectrum me pareció evidente poder comprimir datos en Basic, usando este sencillo algoritmo, y en vez de guardar “AAAAA” lo que guardaba era “5 As”.

De nuevo con el PC, me quedé alucinado, primero con el polémico PKARC, que era rapidísimo, y después PKZIP, del que siendo casi tan veloz comprimía bastante más. me hice evangelista de PKZIP, en una época en que la mayoría usaban LHARC o ARJ, y fui realizando diferentes benchamarks con herramientas poco conocidas. Hasta que llegó Ultra Compressor, y después RAR. Resulta curioso ver como ZIP, acabó siendo el formato más difundido, y como ahora, los esfuerzos se centran en mejorar su grado de compresión, a pesar de haber mejores opciones.

Después de implementaciones mejoradas y mucho más rápidas de RLE, decidí que no tenía nada que hacer contra estos formatos en cuanto eficiencia, así que hice BLINK, que consiguió ser uno de los compresores/descompresores más rápidos del mercado.

Sin embargo, lo que me dejó verdaderamente descolocado, fueron los compresores de ejecutables. Cuando vi LZEXE, no podía creérmelo. La idea era sencilla, aplicar los mismos conceptos, pero con descompresión en memoria. Claro que hacerlo, era relativamente fácil con archivos COM, pero con EXEs tenía su intríngulis.

Opté por encadenar diferentes herramientas de este tipo, a las que un programa tipo LZALT les modificaba la cabecera para dificultar su descompresión malintencionada.

Cifrado de datos y comprobación
Igual que con RLE, descubrí los checksum de manera intuitiva al copiar listados de “código máquina” en Microhobby. Era un buen sistema para evitar que modificaran tus cadenas en listados Basic, así que apliqué y desarrollé diferentes alternativas de checksum.

Y también “inventé” el cifrado de Julio César, ya veis, aquellas notas misteriosas donde en vez de A poníamos B, y en vez de B poníamos C, programadas en Turbo Basic. Claro que las mejoraría con claves variables que simplemente modificaban la correlación de símbolos. Pero claro, cuando leí sobre el encriptado XOR, que era mucho más seguro y veloz que el mío, o CRC, me quedé alucinado.

Parece mentira que ahora confiemos tanto en las comprobaciones con MD5, o SHA1, que no dejan de ser mejoras de la clásica suma de comprobación.

Antivirus y virus
Cuando al principio del PC intercambiábamos disquetes, y vi mi primer virus, el Viernes 13, no hubiera imaginado que aquello fuera posible. Empecé a coleccionar virus, y a probar antivirus detectando mis colecciones con ellos, como se hace ahora mismo.

Creé algunas firmas de detección para McAfee y TBAV cuando aquello estaba abierto a los usuarios.

A partir de ahí, cree un par de programitas para detectar mis propias creaciones, así como las que hacían otros. Eran tiempos de Virus Creation Laboratory, y sus derivados. Por supuesto, obtener una firma, e incluirla en tu programa para la detección, era relativamente sencillo, pero desinfectarlo, era bastante más laborioso, incluso conociendo de primera mano lo que hacía. Inclusive crear una heurística que detectase cierto patrones, era algo interesante, como EXEINFO, que además de firmas, determinaba el potencial comportamiento del programa en base a los servicios DOS que usaba (interrucpciones).

No llegué nunca a intuir como podía implementarse una limpieza heurística, o incluso data-driven, supongo que el paso previo del análisis de comportamiento actual.

Gráficos
¿A qué niño lo le gustan los gráficos? ¿Y quién no se planteó nunca desarrollar sus propios juegos? Ocurre que no era una tarea tan fácil, sin bien la idea podía resultar sencilla, acababan siendo programas gigantescos, que más pronto que tarde se topaban con las limitaciones de las funciones gráficas en los lenguajes de programación. Eran lentaaaaas.

Eso no impedía que comenzaras tus juegos arcade que luego resultaban injugables, o que te curraras unos entornos gráficos de padre y señor mío, pero que luego no proveían de funcionalidad.

No se trataba que los lenguajes no fueran eficientes, que también, sino que esas primitivas, no estaban pensadas para el rendimiento. Por fortuna, en los “ratos libres” de la Universidad, pude ver con Turbo Pascal como funcionaba el acceso a bajo nivel al hardware, y eso abrió muchas puertas.

Hasta que al final, llegaría Glib y Outlaw.