Viernes 13: el virus que se saltó su propio día de mala suerte

Hoy es viernes 13. Estas semanas he estado viendo Crystal Lake, la serie de la saga de Jason, así que tenía la fecha en la cabeza. Pero el viernes 13 que me interesa a mí no lleva máscara de hockey. Lleva 1.813 bytes.

En el resto del mundo se le conoce como Jerusalem, por la universidad donde lo destaparon. Aquí se le llamó Viernes 13, lo cual tiene su mérito en un país donde el día temido siempre ha sido el martes.

Es un virus de MS-DOS de 1987, y lo interesante no es lo que rompía. Fuera de su fecha seguía infectando programas, y un error de programación hizo que se delatara antes de que llegara el día.

Lo que hacía, según el día

Se quedaba residente en memoria y, a partir de ahí, se pegaba a cada .COM o .EXE que ejecutabas, salvo COMMAND.COM. Su lógica, en una versión de andar por casa, era esta:

si hoy es viernes, el día es 13 y el año no es 1987:
    borra el programa que te han pedido ejecutar
si no:
    infecta el programa que te han pedido ejecutar

Las crónicas de la época hablaban de que borraría todos los archivos almacenados. Virus Bulletin, la revista del sector, era más concreta, y la cosa es casi más perversa: con el virus en memoria, cada programa que intentabas abrir ese día desaparecía. Cuanto más intentabas averiguar qué pasaba, más perdías.

Fíjate en la tercera condición. Según contó al New York Times Yuval Rakavy, el estudiante de la Universidad Hebrea que lo desmontó, el virus estaba programado para ignorar el 13 de noviembre de 1987, que fue viernes. Por qué, solo lo sabe quien lo escribió, pero Virus Bulletin lo interpretaba así en 1990: parece que el autor quería darle tiempo a propagarse. Saltarse aquel viernes le daba medio año más, porque en 1988 solo hubo uno: el 13 de mayo.

Esa es la gracia de una bomba lógica. Mientras no llega su fecha, el código está ahí, se ejecuta cada vez, y la rama que borra archivos no se recorre nunca.

Lo delató un fallo

A finales de diciembre de 1987, un amigo le pidió a Rakavy que mirase por qué su PC no funcionaba bien. Lo que encontró tenía dos síntomas, y no todos dieron el mismo peso a cada uno.

El primero era la lentitud. A la media hora, el ordenador caía a una quinta parte de su velocidad y aparecía un recuadro negro en pantalla. Yisrael Radai, de la misma universidad, le dijo a Associated Press que ese fue el primer error del autor, porque permitió ver un patrón.

El profesor Shmuel Peleg dio otra versión en el New York Times: lo que de verdad llamó la atención fue un error del propio virus. La comprobación que tenía que evitar infectar dos veces el mismo programa fallaba, y lo infectaba otra vez.

«Programas que en teoría no se habían modificado estaban creciendo. Teníamos programas infectados 300 y 400 veces».

A un .COM le añadía 1.813 bytes y no volvía a tocarlo: tanto se asociaba a esa cifra que en algunos catálogos el virus se llamaba directamente 1813. Pero un .EXE se reinfectaba cada vez que lo ejecutabas, y engordaba otros 1.808 bytes, hasta que no cabía. Un virus que tenía que aguantar hasta mayo se estaba anunciando solo en el tamaño de los archivos.

Pocos meses después, Ping Pong se escondería en el único sitio del disco donde el sistema prometía no mirar. Un programa que crece a la vista, en cambio, no se esconde en ninguna parte.

Un año después, el gusano de Morris tropezó con la misma piedra por otro camino: allí la reinfección estaba programada, una de cada siete veces, y fue lo que paró las máquinas. La comprobación de «¿ya estoy aquí?», que parece un detalle, decidió dos de las historias más conocidas de aquellos años.

Quién y por qué

No lo sé, y no he encontrado a nadie que lo haya demostrado.

El New York Times lo presentó entonces como una aparente protesta política, porque el 13 de mayo de 1988 era la víspera de los cuarenta años de la independencia de Israel. Es una conjetura de 1988 que se ha seguido repitiendo con más seguridad de la que tenía. Lo que el código dice es otra cosa: que se dispara en todos los viernes 13 salvo los de 1987, no en una fecha concreta.

Lo que sí consta es cómo llegó el día señalado. Amos Shapir escribió ese mismo día en RISKS Digest, el foro donde se discutían estas cosas, que dudaba de que causara mucho daño, precisamente por ese fallo:

«Cualquier disco que no se haya desinfectado a estas alturas se habrá quedado sin espacio».

La bomba llegó a su fecha con la víctima ya avisada. En el mismo número de aquel foro se comentaba otro susto de aquel viernes 13: el rumor de una bomba de tiempo en las estaciones de Sun, que corrió por la red y resultó no existir. Hace 38 años ya teníamos las dos cosas: el virus de verdad y el aviso falso.

Desde aquel mayo ha habido 67 viernes 13, contando el de hoy. El siguiente será en agosto de 2027.

Lo que sigue valiendo

Nadie va a meterte hoy un virus de MS-DOS. Pero las dos ideas se han quedado.

Hasta que llega la fecha, o la simulas, esa rama del código no se ha ejecutado nunca. Una bomba lógica es la versión con mala intención de algo que todos tenemos sin ninguna:

• El proceso que corre «el día 31» y que en febrero no se entera.
• El cálculo que solo se tuerce el 29 de febrero.
• La tarea programada en una hora que el cambio de hora se come o repite.
• El certificado, la licencia o la clave que caducan un día que nadie apuntó.
• El if que alguien puso para una campaña de 2023 y ahí sigue.

Pasan todas las pruebas de cualquier otro día, porque cualquier otro día esa rama no se recorre. La solución es poco épica: que la fecha sea algo que le pasas al código, no algo que el código mira por su cuenta, para poder probar con el reloj en el día que te dé miedo.

Lo que no debe cambiar, vigílalo. A Jerusalem no lo cazó un antivirus, porque casi no había. Lo cazó gente que se preguntó por qué iba lento un ordenador y por qué crecía un archivo que no tenía por qué crecer. Hoy se hace con una huella de los archivos y una comparación programada, y sirve para el núcleo de un WordPress igual que servía entonces para un .EXE. Es de las comprobaciones más baratas que existen.

Feliz viernes 13

Tres cosas para hoy:

1. Busca las fechas escritas a mano en tu código, y los «si es fin de mes» o «si es el día tal». Son pocas y merece la pena leerlas.
2. Prueba una con el reloj cambiado. El 29 de febrero, o el domingo en que cambia la hora.
3. Elige qué archivos no deberían cambiar nunca en tu servidor y haz que algo te avise si cambian.

(Y si hoy un programa no te abre, no es Jerusalem. Pero haz como Rakavy y míralo antes de darle otra vez.)

La ilustración de la cabecera y la de la vista previa al compartir este artículo están generadas con IA.