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.
compresión en zip fue genial, rar mejor y ahora en 7z pues mucho mejor, lástima que que no estén tan extendidos.
Es el problema desde siempre. Los mejores algoritmos de compresión, siempre han sido menos populares.
si 🙁
Muy interesante Guti, me asombra el nivel de profundidad que has llegado a alcanzar en materia como los virus y, sobre todo, la compresión
Con eso de las utilidades de compresión tengo yo una manía en Windows, y mira que lo uso bien poco. En su momento, eran muy útiles, valga la rebuznancia, porque los discos duros eran pequeños y caros, los disquetes enanos desde el punto de vista de hoy, las conexiones por módem lentas y las tarifas telefónicas una ruina. Comprimir era una necesidad. Durante años recuerdo que la primera utilidad que se instalaba en un Windows recién instalado era el WinZip. Un día a M$ se le ocurre una idea buena y razonable (hecho más raro que el paso del cometa Halley) e integra en el explorador de archivos un ZIP vestido de faralae.
Y entonces, a la gente se le ocurre que para bajar un ná el tamaño de los archivos, muchas veces menos de un 10%, hay que usar RAR que ni viene con el sistema, ni es gratuito. Es como si de pronto la gente se pusiera a cambiar las tuercas de las ruedas del coche por unas que necesitan una llave no estándar.
En Linux es distinto porque la mayoría de compresores van «de serie», y en algunos casos el ahorro es importante, como en los fuentes del kernel, donde la diferencia entre bz2 y xz es notable.
Puede parecer curioso, pero hoy en día la mayor utilidad que le doy al compresor es para enviar un grupo de archivos en tar.xz, asegurándome así que o se extrae todo bien o no se extrae nada.
Manías que tiene uno…. 🙂
Muy interesante Guti, me asombra el nivel de profundidad que has llegado a alcanzar en materia como los virus y, sobre todo, la compresión
————
Si, todo un master el sr. tenemos mucho que aprenderle aun jejeje
Muchas gracias nelbu. Sabes perfectamente que cuando algo te apasiona, no escatimas en esfuerzos y dedicación, y al final acabas, sino siendo un maestrillo, si que al menos un buen conocedor del tema.
Tu argumento tiene mucho sentido zx81, aunque dirigido únicamente al usuario final. Piensa por contra un servidor de cualquier tipo, que envía contenidos, ya sea web, ZIPS, MP3, o lo que sea.
En ese caso, una pequeña ganancia en compresión, aunque éste proceso sea más costoso en términos de uso de CPU, resulta muy beneficioso, máxime, si la parte de descompresión por parte de los usuario (clientes), sigue siendo rápida. Es uno de los objetivos de zopfli de Google por ejemplo, o de FileOptimizer.
Por supuesto, en tiempos del Spectrum, con pantallas que ocupaban en RAW 6 Kb, era una técnica de uso obligatorio.
Paciencia Manuel, que nadie nace sabiendo. Es cuestión de perseverancia y tiempo, y poco a poco se va aprendiendo y mejorando.