Difrutemos de otra entrega más de un candidato a aquello de los memes irrealizables que nunca quisieron ser, pero que lo tendrían que haber sido sin lugar a dudas. Un vídeo que se está haciendo viral a marchas forzadas: ‘Beating Tetris‘. Divertido y altamente geek a parte iguales; es la forma correcta de ganar al ‘Tetris’.

A pesar del hecho de que Donkey Kong se lanzó por primera vez para máquinas recreativas en el año 1981, ha sido portado, versionado, desensamblado y desmenuzado hasta la saciedad, y aunque parezca mentira, el título original de Nintendo sigue mostrándonos secretos que guardaba celosamente ocultos; en este caso, en forma de música y efectos sonoros.

Un usuario de la wiki The Cutting Room Floor, y después de escarbar a través de las líneas de código originales, ha encontrado tres piezas de música y dos efectos de sonido que nunca fueron accesibles al gran público (aunque, parece ser, que algunos aparecieron en versiones posteriores del videojuego).

Una de estas musiquillas es una toma alternativa de la melodía que se reproduce al rescatar a Pauline.

Escucha el tema alternativo del rescate de Pauline.

Por su parte, y con respecto a los efectos sonoros, se ha encontrado la voz de Pauline gritando Help! y otro recorte confuso donde no se escucha de forma segura lo que exactamente está diciendo la muchacha.

Escucha a Pauline gritando Help!.

Puedes escuchar todos los archivos de audio desde la propia web.

Nada de esto va a alterar dramáticamente nuestra experiencia con Donkey Kong. No estamos hablando de nuevos niveles o comentarios del desarrollador, pero es fascinante, aun siendo unos archivos triviales en sí mismos, el tiempo que han estado latentes hasta que alguien los ha encontrado.

El 26 de septiembre del año 2014, un contratista del mundo de las telecomunicaciones llamado Brian Howard despertó temprano y se dirigió al Chicago Center, un centro de control de tráfico aéreo en Aurora (Illinois) donde había trabajado durante ocho años. Había decidido suicidarse y, como gesto de su última voluntad, planeó llevarse un pedazo del sistema del control de tráfico aéreo de Estados Unidos con él.

Las grabaciones confirmaron que Brian Howard entró en el Chicago Center a las 5:06 de la mañana y bajó al sótano, donde provocó un incendio en el compartimento de electrónica. Seguidamente se cortó el cuello. Los servicios médicos salvaron la vida de Howard, pero los sistemas del Chicago Center, que en ese momento controlaba el tráfico aéreo por encima de 10.000 pies y en un área de 91.000 kilómetros cuadrados, se apagaron.

Las aerolíneas cancelaron 6.600 vuelos; el tráfico aéreo se interrumpió durante 17 días. Howard había querido causar problemas, pero no había previsto una catástrofe de tal magnitud. Había publicado un mensaje en su cuenta de Facebook diciendo que el sabotaje «no tendría un alto costo para el sistema de control del espacio aéreo, pues todas las comunicaciones deberían cambiar a la ubicación alternativa«. Se equivocaba. Nadie sabe de qué lugar alternativo estaba Howard hablando, porque no existe tal cosa. Howard había trabajado en el centro durante casi una década, e incluso él no conocía eso.

En cualquier momento dado, alrededor de 7.000 aviones sobrevuelan los Estados Unidos. Durante los últimos 40 años, el mismo sistema informático ha controlado todo este tráfico de gran altitud, es una reliquia de la década de 1970 conocida como Host. El núcleo del sistema es anterior a la llegada del GPS, por lo que Host utiliza radares terrestres punto a punto. Cada día, miles de viajeros aéreos ponen sus teléfonos inteligentes con GPS en «modo avión», mientras que sus vuelos son guiados por una tecnología que es anterior al ‘Speak & Spell‘ de Texas Instruments.

Si ahora mismo estás leyendo esto a 30.000 pies de altura, relájate, Host es todavía seguro en términos de conducir aviones de un punto A a un punto B, pero es increíblemente ineficiente. Puede manejar una cantidad limitada de tráfico, y los controladores no pueden ver nada fuera de su propio espacio aéreo; cuando un avión se traslada a un espacio aéreo contiguo, se desvanece en su radar.

La FAA (Federal Aviation Administration) estadounidense sabe todo esto perfectamente. Durante once años, la agencia ha ido migrando hacia un conjunto de actualizaciones conocidas como NextGen. En su núcleo porta un nuevo sistema informático que reemplazará a Host y permitirá que cualquier controlador, en cualquier lugar, pueda ver cualquier avión en el espacio aéreo estadounidense. En teoría, esto permitiría a un centro de control aéreo asumir el mando de otro con sólo tocar una tecla, como Howard parecía creer que ya era posible.

Esta tecnología es problemática y costosa, pero esa no es la mayor de las complicaciones. El problema principal es que NextGen es un proyecto de la FAA. La agencia es, principalmente, un órgano regulador, es la responsable de mantener la seguridad del espacio aéreo nacional y, además, también se encarga de operar el control del tráfico aéreo, un conflicto inherente que causa grandes problemas a la hora de completar las actualizaciones. Modernización, una lucha de cualquier agencia federal, es prácticamente la antítesis de la cultura operativa de la FAA, que es adversa al riesgo metódico y burocrático. A esto se suma que la FAA es la única consumidora del producto, por lo que no existen presiones por parte de los mercados.

La primera fase de NextGen es reemplazar Host con el nuevo sistema informático, la base para todas las futuras actualizaciones. La FAA pretendía terminar el trabajo para la pasada primavera, cinco años más tarde de lo previsto y, por lo menos, 500 millones de dólares por encima del presupuesto original.

La compañía Lockheed Martin comenzó a desarrollar el software en el año 2002, y la FAA proyectó que la transición desde Host estaría completa a finales de 2010. En 2007, el sistema actualizado se utilizaba sólo a través de pruebas internas, pero una vez instalado, era espantosamente inestable y contenía cientos de bugs. Por ejemplo, a veces vinculaba aviones a los datos de vuelo de una aeronave equivocada; otras veces los aviones desaparecían por completo de las pantallas de los controladores.

Recientemente, en abril de 2014, el sistema se vino abajo en Los Angeles Center cuando un jet militar U-2 entró en su espacio aéreo. El avión espía cruzó a 60.000 pies, el doble de la altitud de los aviones comerciales, y su plan de vuelo provocó un fallo de software que sobrecargó la sistema y lo tumbó.

En el sector privado, las empresas de tecnología se mueven rápido y actualizan sistemas sin poner en riesgo nuestra seguridad. Pero cuando el gobierno actualiza sus tecnologías, las regulaciones y la burocracia interceden antes de escribir una sola línea de código. El proceso de contratación pública está atada a mil reglas y normas, y la nueva tecnología en cuestión tiene que ajustarse a esas normas, si son o no son eficientes ni siquiera es relevante.

Y en esas estamos.

Entre 2009 y 2010 el programa nuclear de Irán fue blanco de un ataque cibernético devastador. Un virus conocido como Stuxnet y colado por un grupo de hackers, según los informes desarrollados por los gobiernos estadounidense e israelí, tomó el control de las instalaciones nucleares en todo el país, causando que miles de máquinas se estropearan. Pero, al parecer, no satisfechos con paralizar los esfuerzos nucleares de Irán, quisieron demostrar su poder de otra manera. Para ello, y siempre según los informes citados, secuestraron estaciones de trabajo de la red iraní y las utilizaron para poner, a todo volumen, música del grupo australiano AC/DC.

Y debieron de poner la música muy, muy alta. En su intervención en la conferencia de seguridad Black Hat, el experto en seguridad informática Mikko Hyppönen recordó el correo electrónico que recibió de un científico iraní en el momento de los ataques de Stuxnet. El contenido se detalla a continuación.

«Había también algo de música tocando al azar en muchas de las estaciones de trabajo durante la noche con el volumen al máximo. Creo que era la banda estadounidense AC-DC Thunderstruck. Todo era muy extraño y sucedió muy rápido. Los atacantes también han logrado ganar acceso root a la máquina por la que entraron y eliminaron todos los logs».

Por supuesto, Thunderstruck es una canción de 1990 del álbum The Razor Edge, no un sufijo del nombre de la banda australiana (que no estadounidense). Pero ese científico puede ser perdonado por sus altos desconocimientos musicales, y es que bajo las leyes de censura del país, sólo la música floclórica de Irán, la música clásica o la música pop son admitidas allí.

Desde el ataque de Stuxnet, el presidente Obama ha advertido contra el uso de armas cibernéticas para atacar a otros países, por temor a que pueda ser reutilizado su código fuente y se convierta en un ataque inverso contra Estados Unidos. Hasta el momento, el presidente no ha comentado sobre los peligros de la implementación de canciones de AC/DC en estos ataques 😉 .

En 1986, Amstrad compra la compañía Sinclair después del descalabro de ésta a cuenta de las malas ventas del QL y del fiasco del C5 en Inglaterra. Hasta aquel momento, la empresa española Investrónica (filial de El Corte Inglés) distribuía los productos de Sinclair en España, sin embargo, la distribuidora oficial de Amstrad era Indescomp, que pasaría a realizar dicho cometido desde entonces. Investrónica, pues, que tenía experiencia en la fabricación local de microordenadores Sinclair (el ZX Spectrum +128, concretamente), decidió utilizar ese bagaje tecnológico para crear su propio clon de un ZX Spectrum 48K, el conocido aquí como Inves Spectrum +, ordenador que venía con el teclado y el software traducido al castellano.

Este clon adoleció de numerosas incompatibilidades, principalmente debido a esa ROM traducida no totalmente estándar. Entre aquellas características extrañas del Inves Spectrum +, hubo una que podemos considerar como única en la historia de los ordenadores de Sinclair y de sus clones: el Inves Spectrum + era, presumiblemente, el primer y único clon de Spectrum que podía dañarse de forma permanente mediante la utilización de determinadas instrucciones de software. ¿Cómo dice, joven? Lo que oyes.

La propia revista MicroHobby, en la página 32 de su número 156, advertía del rumor aparecido y aseguraba que, aunque no habían tenido ocasión de comprobarlo, las dos siguientes instrucciones en BASIC podía dañar físicamente el ordenador:

BORDER 5
RANDOMIZE USR 4665

Lo gracioso del asunto es que, en la época, nadie parece que realizara la prueba para comprobarlo, ni los propios redactores de MicroHobby. Y es que el producto de aquello podía resultar en que el dichoso aparato se estropeara de por vida, y aquello daba miedito. El Inves Spectrum + es hoy día un ordenador bastante raro y codiciado, pues sólo se comercializó en España, así que dudo mucho que si alguien se hace con uno se atreva a probar el conocido como «RANDOMIZE de la muerte». O sí.

La imagen siguiente se corresponde con la advertencia en MicroHobby aprovechando la pregunta de un lector.

Pasaron los años, y la leyenda urbana se mantuvo en el tiempo. Sin embargo, en el año 2003 apareció un emulador de máquinas Sinclair, el ZXSpectr para MS-DOS, que presumía de ser el único que emulaba al de Investrónica (aunque hoy día ya no es así). El propio autor del emulador, César Hernández Baño, se encargó de demostrar que todo aquello del «RANDOMIZE de la muerte» no era más que una fábula tecnológica. César evidenció que no había nada de malo en ese RANDOMIZE USR. De hecho no tenía sentido que una llamada a la ROM (aunque fuera en medio de una instrucción) pudiera tener ese efecto tan devastador.

Ni que decir tiene que en la máquina real pasó exactamente lo mismo que en el emulador. No hubo daños a la máquina, ni temporales ni permanentes. Al hacer el RANDOMIZE USR 4665, la máquina vuelve inmediatamente al BASIC con el mensaje de inicio y el borde celeste. Al pulsar ENTER, el sistema devuelve el mensaje C NO EXISTE EN BASIC, 0:1. Al pulsar ENTER de nuevo, la zona de edición (las líneas inferiores de pantalla donde se escriben los comandos BASIC) se llenan de basura, con sentencias, números y otros caracteres ininteligibles. En este punto, el intérprete de BASIC se comporta de forma inestable y la única forma de salir es con un reseteo total del equipo.

Todo lo anterior lo vemos en el siguiente vídeo, creado por el mismo César.

Si se realiza esta sencilla prueba con la ROM original de Sinclair, el resultado es idéntico, sólo que cambia el texto de los mensajes que aparecen.

En otro documento más técnico, César Hernández Bañó describía el problema de la siguiente manera:

Si hacemos un POKE a ciertas direcciones ROM (sí, direcciones ROM), el borde no responde a nuevos comandos BORDER. Después de algunas investigaciones, hemos descubierto que pokeando una dirección ROM cuyo byte menos significativo sea 254, se bloquea cualquier dato de entrada en la ULA del equipo. Para ser más precisos: si hacemos un POKE de un valor V a direcciones 254, 510, 766 […], 16382 (es decir, N * 256 + 254), con un rango de valores N que vaya de 0 a 63, ese valor V actúa como una máscara AND para todos los datos posteriores dirigidos a la ULA. Esto significa que si V es 0, independientemente del valor emitido por el procesador, la ULA ve 0 en su bus de datos. Para recuperar el funcionamiento normal, hay que pokear 255 a todas las direcciones ROM.

Esta situación se prolongó en el tiempo mientras había suministro de energía en el Inves Spectrum +. Un reseteo del equipo o un RANDOMIZE USR 0 no restauraban la ULA a su estado original. Sólo después de desconectar de corriente y volver a conectar, las cosas volvieron a la normalidad.

Por lo tanto, quedó demostrado que el «RANDOMIZE de la muerte» nunca fue real. Sin embargo, hoy día muchos lo siguen comentando como cierto; es lo que tienen las leyendas urbanas, que regresan periódicamente y nadie sabe por qué.