Cuando varios hackers usaron los ordenadores del programa nuclear iraní para poner música de AC/DC

AC/DC
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 😉 .
La verdad sobre el «RANDOMIZE
de la muerte» de los Inves Spectrum +

Inves Spectrum +
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.

Advertencia en MicroHobby
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.
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 comandosBORDER
. Después de algunas investigaciones, hemos descubierto que pokeando una dirección ROM cuyo byte menos significativo sea254
, se bloquea cualquier dato de entrada en la ULA del equipo. Para ser más precisos: si hacemos unPOKE
de un valorV
a direcciones254
,510
,766
[…],16382
(es decir,N * 256 + 254
), con un rango de valoresN
que vaya de0
a63
, ese valorV
actúa como una máscaraAND
para todos los datos posteriores dirigidos a la ULA. Esto significa que siV
es0
, independientemente del valor emitido por el procesador, la ULA ve0
en su bus de datos. Para recuperar el funcionamiento normal, hay que pokear255
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é.
Si la aleatoriedad es una lotería, ¿por qué no usar la lotería para la aleatoriedad?

Aleatoriedad con lotería
Un grupo de expertos criptógrafos franceses ha asegurado que las loterías públicas son la semilla perfecta para la criptografía de curva elíptica, una variante de la criptografía asimétrica o de clave pública basada en las matemáticas de las curvas elípticas.
Este grupo, perteneciente a la empresa CryptoExperts, junto con ingenieros del Laboratoire de Mathematiques de Versailles (de la Universidad París-Saclay) llama, en broma, al esquema la «curva del millón de dólares«. Según ellos señalan, y de lo que se hacen eco en el blog británico The Register, proponen una solución definitiva (y divertida) para el problema de generar aleatoriedad pública y verificable de una manera intachable o reprobable.
El problema que están intentando resolver es que todas las curvas elípticas deberían funcionar, de alguna manera, como germen o semilla de dicha aleatoriedad, y la experiencia nos ha demostrado que esos mecanismos «de germinación» pueden ser peligrosamente opacos y esotéricos. Después de todo, nos da qué pensar cómo el algoritmo Dual_EC_DRBG que la NSA controlaba pudo sobrevivir tanto tiempo como generador de bits aleatorios antes de que se descubriera que no servía absolutamente para nada.
En este modelo de la curva del millón de dólares, como se detalla en el documento oficial del grupo, los expertos explican que las loterías públicas tienen dos características muy atractivas para los números aleatorios: son fáciles de verificar (ya que todo el mundo sabe los resultados), pero bastante difíciles de manipular.
La explicación para expertos se fundamenta en que este método permite construir lo que ellos laman un generador de números aleatorios públicamente comprobable, del cual se extrae una semilla que se utiliza para crear una instancia e inicializar un generador aleatorio Blum Blum Shub. A continuación, se usa la secuencia binaria producida por este generador como una entrada para una función de filtrado que da salida de forma determinista a una serie de parámetros de seguridad, uniformemente distribuidos a partir de flujos de bits uniformes.
Como ellos mismos comentan, otras posibles fuentes de aleatoriedad verificable a menudo dependen de una tercera parte de confianza en algún lugar de la cadena, algo que no es necesario si la fuente de la semilla es de conocimiento público, como los números ganadores de una lotería.
A través de GitHub podemos descargar toda la documentación y el código fuente de este imponente algoritmo, perfectamente explicado por medio de varios ejemplos en Python 3.
[Retropapelote de la semana] El ZX81 llega a Francia
El abril de 1982 aparece encartado entre las revistas y publicaciones especializadas francesas este anuncio del Sinclair ZX81, la versión mejorada del ZX80 y el hermano pequeño del futuro Sinclair ZX Spectrum. «El fenómeno Sinclair«, titulaba el papelote, apuntando que se habían vendido ya 250.000 unidades en todo el mundo. Era la oportunidad de oro de los usuarios galos.
Por sólo 985 francos de los de hace treinta y tantos años podíamos conseguir nuestro flamante microordenador, impuestos y gastos de envío incluidos, y el manual de usuario de regalo.
Aquel ZX81 venía del Reino Unido con su procesador de 8 bits Z80A de Zilog (grande donde los haya habido y donde los hay aún) a 3,5 MHz, con 1 kilobyte de RAM, 8 kilobytes de ROM y aquel horroroso teclado sensible al tacto. Eso sí, por 650 francos más podíamos comprar una extensión de memoria que lo hacía llegar a unos 16 vertiginosos kB de capacidad. El resto de funciones de programación que trae especificadas el panfleto (bucles FOR-NEXT
, RANDOMIZE
, funciones matemáticas…) nos hace parecer que estamos frente a la publicidad de una calculadora gigante.
Un gran retropapelote con su cuponcito recortable para la compra por correo que tan común era en aquella época.
«El guión de un videojuego es tan importante como el de una película porno»

Rhianna Pratchett
Es lo que dijo el gurú de los videojuegos John Carmack, programador estadounidense y cofundador de id Software. La frase exacta fue «la historia en un juego es como la historia en una película porno; se supone que tiene que estar ahí, pero no es importante». Este hombre no podría estar más equivocado.
El pasado 13 de febrero, los diversos gremios de escritores y guionistas estadounidenses daban a conocer su veredicto en el concurso anual que premia los mejores guiones en áreas como el cine, la televisión, los nuevos medios, videojuegos, radio, noticias, animación y otras categorías varias en dos ceremonias simultáneas en Los Ángeles y en Nueva York. Allí se encontraba Rhianna Pratchett, periodista, diseñadora narrativa y una de las mejores guionistas de videojuegos que existen hoy en el mundo. Y estaba allí, precisamente, para recoger su premio como coautora del gran guión del juego ‘Rise of the Tomb Raider‘, título recientemente aparecido y que se ha llevado todos los honores de estas asociaciones de escritores.
En 33 años jugando a videojuegos (ella tiene ahora 40), Pratchett ha podido comprobar que el verdadero valor de una historia atraviesa su propio arco creativo. Precisamente sobre este arco creativo y narrativo habló la escritora en el evento videojueguil D.I.C.E. Summit de Las Vegas. Decía que contar una historia es visto hoy día como un sello distintivo de juegos tent-pole (como dicen los americanos), es decir, un juego que es muy lucrativo para el estudio y que puede soportar él mismo los resultados financieros. Ejemplos de ello podrían ser ‘The Last of Us‘ (Naughty Dog, 2013) o ‘BioShock Infinite‘ (Irrational Games, 2013).

‘Rise of the Tomb Raider’
Ella viene de familia creativa, no en vano su padre era el recientemente fallecido Terry Pratchett, escritor británico de fantasía y ciencia ficción, conocido sobre todo por las obras de la serie ‘Mundodisco’. Rhianna comenzó su carrera en el mundo del periodismo de videojuegos. Posteriormente cambió a la escritura de guiones para juegos, comenzando con ‘Beyond Divinity‘ (Larian Studios, 2004), un juego de rol ambientado en un mundo de fantasía. Su carrera despegó cuando escribió la historia de ‘Heavenly Sword‘ (Ninja Theory, 2007), un juego distribuido por Sony que protagoniza Nariko, una heroína maldita con ansias de venganza.
Más tarde trabajó en ‘Overlord‘ (Triumph Studios, 2007) y ‘Mirror’s Edge‘ (Electronic Arts, 2009), para llevar después la dirección de guión del nuevo ‘Tomb Raider‘ aparecido 2013 y de su secuela ‘Rise of the Tomb Raider’ de 2015, ambos de la desarrolladora Crystal Dynamics. Esta chica también escribe libros de cómics (‘Mirror’s Edge’ para DC Comics y ‘Tomb Raider’ para Dark Horse, sobre todo) y guiones para el cine y la televisión.
Los escritores profesionales solían ser una rareza en el mundo de los videojuegos cuando ella empezó, pero se hicieron populares en el momento en que Hollywood comenzó tocar con sus manos la industria del ocio digital. Sin embargo, los resultados no siempre han sido tan buenos; los juegos basados en películas no tienen muy buena reputación, y los jugadores reaccionan mal a títulos con demasiada cinemática. «Hollywood no hizo las cosas demasiado bien», dice Pratchett, «aquellos videojuegos no estaban presentando la historia y el viaje de un personaje como algo importante; esa fue parte de la razón del éxito de ‘Tomb Raider'».

Rhianna Pratchett
Pero los escritores no pueden controlar todo en los juegos que guionizan, pues son sólo una parte de la jerarquía de las personas que diseñan el conjunto, y también tienen que lidiar con el resto y con las restricciones y las reglas especiales. «Debemos reconocer nuestra propia singularidad y el poder que tenemos para transmitir una historia a las audiencias de los juegos. Así mismo, necesitamos formar a nuestros propios escritores para que se especialicen en videojuegos, fomentado todo ello por nuestra propia industria».
En estos momentos, Pratchett está trabajando para la Warner Bros. y tiene varios proyectos de cine y una serie de televisión entre manos. «Para contar mejores historias, todos debemos ser mejores contadores de historias«, comentó.