Vamos a contaros una de esas Microhistorias que tanto nos gustan donde esta vez se mezcla hacking, programadores extremos (ahora veréis por qué) y el viaje a la Luna. El programa Apolo fue un hito tecnológico único, que provocó el avance de la Ciencia en varios campos como la química, aeronáutica, medicina y por supuesto también la Informática. Esta es una de esas historias no tan conocida que nos hacen ver que hubo también otros héroes aparte de los astronautas que se jugaron la vida por la Humanidad. Recuerda que puedes encontrar historias como esta en nuestro libro “Microhistorias: Anéctodas y Curiosidades de la Informática”:
Después del desafortunado incidente en la misión del Apolo 13, poco más de un año después (acordaros del famoso “Houston, tenemos un problema”), EEUU no podía volver a permitirse otro fallo o el resto de la misión sería cancelada (aún quedaban al menos cuatro o cinco viajes más programados). De hecho, después del fracaso del Apolo 13 (en el que afortunadamente los astronautas pudieron volver sanos y salvos), esta misión del Apolo 14 estuvo a punto de ser cancelada.
Afortunadamente, al final obtuvo luz verde y el cohete Saturno V despegó desde el Centro Espacial Kennedy el 31 de enero de 1971. Los astronautas elegidos para esta misión fueron Alan B. Shephard, Edgar D. Mitchell y Stuart A. Roosa.
Aunque el lanzamiento y viaje a la Luna del Apolo 14 se ejecutó sin problemas, escasamente a tres horas del alunizaje, el equipo de control de tierra recibió de la cabina del módulo lunar la señal de que la secuencia de abortar se había activado. Después que los astronautas (Alan Shepard y Edgar Mitchell, que eran los que iban en el módulo de descenso o LM bautizado como “Antares”) confirmaron que ellos no habían pulsado el botón de abortar misión, control en tierra les pidió a estos que dieran un “golpecito” (así, tal y como suena) al panel donde se encontraba el indicador de dicha acción de abortar.
Cuando lo hicieron, la señal se apagó, pero poco más tarde volvió a aparecer. Estaba claro que había algún tipo de problema con el indicador, probablemente un mal contacto provocado por algún trocito de metal desprendido de alguna parte por culpa de las vibraciones de la nave.
El objetivo del botón de abortar tenía como objetivo desprender el LM en caso de que algo fuera mal durante el alunizaje. Pulsando éste, se activaría una secuencia que mandaría la nave de nuevo a una órbita segura, obviamente abortando el alunizaje. En esta fase del viaje no tenía ningún efecto, pero si dicha señal se activara de forma automática durante la fase de descenso, mandaría la nave de nuevo a la órbita lunar, sin que la tripulación pudiera hacer nada.
Es decir, si el software del módulo lunar detectaba durante esa fase que se este indicador se había activado, se procedería a abortar la misión. Los astronautas estarían a salvo, pero la misión fracasaría, y esto como ya hemos comentado antes, era algo que la NASA no se podría permitir después del fracaso del Apolo XIII.
Había que hacer algo con ese indicador, ya que había muchas probabilidades que éste se activara accidentalmente durante la fase de alunizaje y abortara la misión sin haber realmente un problema real. Era la 1:00 am cuando a Don Eyles le notificaron del problema en su oficina, cerca de la habitación donde se estaba monitorizando la misión. Eyles era uno de los ingenieros que había trabajado en el software del módulo lunar en el equipo de Margaret Hamilton.
De hecho, había escrito la mayoría del código del alunizaje, incluyendo aquel que monitorizaba el indicador de abortar por lo tanto era el más apropiado para solucionar el problema. Para ello, tenía que encontrar la manera que el software del módulo lunar ignorara dicha señal durante la crítica fase de alunizaje. Así, tal y como suena con todo el riesgo que esto conlleva.
Fue entonces cuando Don Eyles junto a Bruce McCoy, que era quién le había dado la noticia a Eyles y también era ingeniero de software de la misión, fueron a una habitación cercana donde tenían el listado del código fuente exacto que se ejecutaba en el módulo lunar. En esos tiempos no existían Github ni StackOverflow :) así que la única fuente de información era una copia del código fuente impreso en papel, el cual era una mezcla de código máquina y ensamblador. Cogieron un lápiz y papel, se pusieron las gafas y comenzaron a repasar el código a toda prisa, era una tarea contrarreloj.
Entonces, a Don Eyles se lo ocurrió que, para poder solucionar el problema lo mejor era hacer creer al módulo lunar que el proceso para abortar ya estaba activo. Técnicamente era engañar a su propio software para que ignorara las señales que enviaba este indicador. Aunque parecía una locura, si esta acción se realizaba en el momento preciso, el impacto sería mínimo y no pondría en riesgo a la misión.
Es decir, el motor todavía se encendería a tiempo para el alunizaje y los astronautas, en caso de emergencia, podrían activarlo de forma manual. Esto de “hacer creer…” en el mundo del hacking se conoce como una técnica de engaño (en inglés, “deception”) la cual tiene como base la ingeniería social, pero también es utilizada para engañar en el mundo de la informática. Nuestro amigo Kevin Mitnick tiene todo un libro dedicado a ello.
Por ejemplo, algo parecido fue lo que usó Stuxnet para hacer creer a los sistemas que monitorizaban los centrifugadores de gas usados para la creación de uranio, que todo marchaba bien, mientras que otra parte del espécimen se encargaba de atacarlos causando su mal funcionamiento. De hecho, el objetivo era acelerar estas centrifugadoras a velocidades por encima de la permitida hasta que terminaban dejando de funcionar, y en alguna ocasión parece que incluso llegaron a explotar.
Figura 8: Vídeo de Don Eyles explicando el código fuente del código lunar
Después de crear el programa para realizar este bypass y realizar un par de intentos en el simulador que tenían en tierra, a tan sólo 10 minutos de quedarse sin tiempo, ya tenían listo el código que engañaría al ordenador del módulo lunar. Este finalmente fue aprobado y se preparó para ser enviado por radio a la tripulación.
El resultado final aún requeriría que los astronautas ejecutaran un procedimiento en el terminal DSKY - Display/Keyboard de abordo, que resultaría en escribir las instrucciones en el teclado del DSKY, el cual constaba 61 pulsaciones, y además de ello, también tendrían que realizar un par de pasos más, esta vez manuales con otros instrumentos para terminar el proceso.
Vamos a detenernos un momento en este punto para repasar la situación extrema a la que se enfrenta Eyles y su equipo. Imaginaros la gran la cantidad de vectores de error que podían suceder en cualquier momento y las consecuencias desastrosas que podrían acarrear. Primero tuvo que programar todo el código sin un sólo fallo en tiempo récord para poder tenerlo a tiempo antes de la ventana de alunizaje (lo consiguió a sólo 10 minutos de no haber vuelta atrás, tal y como hemos comentado antes).
Después, había que enviarlo por radio al módulo lunar para que un astronauta (en este caso Allan Shepard) lo tecleara a mano, comando por comando sin cometer tampoco ningún error en las pulsaciones. Cada pulsación del teclado tendría que ser muy precisa, ya que estaban programando directamente en la memoria del ordenador de abordo durante una misión real. Un error, y las consecuencias podrían ser desastrosas.
Afortunadamente, Alan Shepard no cometió ningún error en las pulsaciones, el código funcionó perfectamente y no hubo ningún error el proceso manual. Así que finalmente, el 5 de febrero de 1971 a las 9:18 UTC el módulo Antares alunizó sin problemas en la zona de Fra Mauro en la Luna para continuar con la misión. El 9 de febrero finalmente la tripulación amerizó sana y salva a las 21:00 UTC terminado con éxito la misión del Apolo 14. Don Eyles continuó trabajando en la NASA durante varios años más contribuyendo a que el resto de las misiones Apolo fuera un éxito total.
Y esto es todo, así que la próxima vez que te sientas bajo presión cuando estés programando, piensa en lo que tuvo que pasar el bueno de Eyles ;)
Happy Hacking Hackers!!!
Autores:
Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.
Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.
 |
| Figura 1: Don Eyles, el programador que utilizó el arte del engaño para hackear el Apolo 14 y salvar la misión |
Después del desafortunado incidente en la misión del Apolo 13, poco más de un año después (acordaros del famoso “Houston, tenemos un problema”), EEUU no podía volver a permitirse otro fallo o el resto de la misión sería cancelada (aún quedaban al menos cuatro o cinco viajes más programados). De hecho, después del fracaso del Apolo 13 (en el que afortunadamente los astronautas pudieron volver sanos y salvos), esta misión del Apolo 14 estuvo a punto de ser cancelada.
 |
| Figura 2: Libro Microhistorias: Anécdotas y curiosidades de la historia de la informática (y los hackers) de 0xWord |
Afortunadamente, al final obtuvo luz verde y el cohete Saturno V despegó desde el Centro Espacial Kennedy el 31 de enero de 1971. Los astronautas elegidos para esta misión fueron Alan B. Shephard, Edgar D. Mitchell y Stuart A. Roosa.
 |
| Figura 3: Tripulación del Apolo 14, de Izquierda a Derecha, Roosa, Shepard y Mitchel |
Aunque el lanzamiento y viaje a la Luna del Apolo 14 se ejecutó sin problemas, escasamente a tres horas del alunizaje, el equipo de control de tierra recibió de la cabina del módulo lunar la señal de que la secuencia de abortar se había activado. Después que los astronautas (Alan Shepard y Edgar Mitchell, que eran los que iban en el módulo de descenso o LM bautizado como “Antares”) confirmaron que ellos no habían pulsado el botón de abortar misión, control en tierra les pidió a estos que dieran un “golpecito” (así, tal y como suena) al panel donde se encontraba el indicador de dicha acción de abortar.
Cuando lo hicieron, la señal se apagó, pero poco más tarde volvió a aparecer. Estaba claro que había algún tipo de problema con el indicador, probablemente un mal contacto provocado por algún trocito de metal desprendido de alguna parte por culpa de las vibraciones de la nave.
 |
| Figura 4: Detalle del botón y el indicador de abortar misión del LM |
El objetivo del botón de abortar tenía como objetivo desprender el LM en caso de que algo fuera mal durante el alunizaje. Pulsando éste, se activaría una secuencia que mandaría la nave de nuevo a una órbita segura, obviamente abortando el alunizaje. En esta fase del viaje no tenía ningún efecto, pero si dicha señal se activara de forma automática durante la fase de descenso, mandaría la nave de nuevo a la órbita lunar, sin que la tripulación pudiera hacer nada.
Es decir, si el software del módulo lunar detectaba durante esa fase que se este indicador se había activado, se procedería a abortar la misión. Los astronautas estarían a salvo, pero la misión fracasaría, y esto como ya hemos comentado antes, era algo que la NASA no se podría permitir después del fracaso del Apolo XIII.
 |
| Figura 5: Esquema del módulo lunar |
Había que hacer algo con ese indicador, ya que había muchas probabilidades que éste se activara accidentalmente durante la fase de alunizaje y abortara la misión sin haber realmente un problema real. Era la 1:00 am cuando a Don Eyles le notificaron del problema en su oficina, cerca de la habitación donde se estaba monitorizando la misión. Eyles era uno de los ingenieros que había trabajado en el software del módulo lunar en el equipo de Margaret Hamilton.
De hecho, había escrito la mayoría del código del alunizaje, incluyendo aquel que monitorizaba el indicador de abortar por lo tanto era el más apropiado para solucionar el problema. Para ello, tenía que encontrar la manera que el software del módulo lunar ignorara dicha señal durante la crítica fase de alunizaje. Así, tal y como suena con todo el riesgo que esto conlleva.
Fue entonces cuando Don Eyles junto a Bruce McCoy, que era quién le había dado la noticia a Eyles y también era ingeniero de software de la misión, fueron a una habitación cercana donde tenían el listado del código fuente exacto que se ejecutaba en el módulo lunar. En esos tiempos no existían Github ni StackOverflow :) así que la única fuente de información era una copia del código fuente impreso en papel, el cual era una mezcla de código máquina y ensamblador. Cogieron un lápiz y papel, se pusieron las gafas y comenzaron a repasar el código a toda prisa, era una tarea contrarreloj.
 |
| Figura 6: Los 5 graduados del MIT delante del código que escribieron para solucionar el problema del Apolo 14. De pie: Samuel Drake y Bruce McCoy. Sentados: Lawrence Berman, Peter Volante y Don Eyles. |
Entonces, a Don Eyles se lo ocurrió que, para poder solucionar el problema lo mejor era hacer creer al módulo lunar que el proceso para abortar ya estaba activo. Técnicamente era engañar a su propio software para que ignorara las señales que enviaba este indicador. Aunque parecía una locura, si esta acción se realizaba en el momento preciso, el impacto sería mínimo y no pondría en riesgo a la misión.
Es decir, el motor todavía se encendería a tiempo para el alunizaje y los astronautas, en caso de emergencia, podrían activarlo de forma manual. Esto de “hacer creer…” en el mundo del hacking se conoce como una técnica de engaño (en inglés, “deception”) la cual tiene como base la ingeniería social, pero también es utilizada para engañar en el mundo de la informática. Nuestro amigo Kevin Mitnick tiene todo un libro dedicado a ello.
 |
| Figura 7: The Art of Deception de Kevin Mitnick |
Por ejemplo, algo parecido fue lo que usó Stuxnet para hacer creer a los sistemas que monitorizaban los centrifugadores de gas usados para la creación de uranio, que todo marchaba bien, mientras que otra parte del espécimen se encargaba de atacarlos causando su mal funcionamiento. De hecho, el objetivo era acelerar estas centrifugadoras a velocidades por encima de la permitida hasta que terminaban dejando de funcionar, y en alguna ocasión parece que incluso llegaron a explotar.
Figura 8: Vídeo de Don Eyles explicando el código fuente del código lunar
Después de crear el programa para realizar este bypass y realizar un par de intentos en el simulador que tenían en tierra, a tan sólo 10 minutos de quedarse sin tiempo, ya tenían listo el código que engañaría al ordenador del módulo lunar. Este finalmente fue aprobado y se preparó para ser enviado por radio a la tripulación.
El resultado final aún requeriría que los astronautas ejecutaran un procedimiento en el terminal DSKY - Display/Keyboard de abordo, que resultaría en escribir las instrucciones en el teclado del DSKY, el cual constaba 61 pulsaciones, y además de ello, también tendrían que realizar un par de pasos más, esta vez manuales con otros instrumentos para terminar el proceso.
 |
| Figura 9: DSKY |
Vamos a detenernos un momento en este punto para repasar la situación extrema a la que se enfrenta Eyles y su equipo. Imaginaros la gran la cantidad de vectores de error que podían suceder en cualquier momento y las consecuencias desastrosas que podrían acarrear. Primero tuvo que programar todo el código sin un sólo fallo en tiempo récord para poder tenerlo a tiempo antes de la ventana de alunizaje (lo consiguió a sólo 10 minutos de no haber vuelta atrás, tal y como hemos comentado antes).
Después, había que enviarlo por radio al módulo lunar para que un astronauta (en este caso Allan Shepard) lo tecleara a mano, comando por comando sin cometer tampoco ningún error en las pulsaciones. Cada pulsación del teclado tendría que ser muy precisa, ya que estaban programando directamente en la memoria del ordenador de abordo durante una misión real. Un error, y las consecuencias podrían ser desastrosas.
 |
| Figura 10: Parte del código fuente del Módulo de Alunizaje escrito por Don Eyles |
Afortunadamente, Alan Shepard no cometió ningún error en las pulsaciones, el código funcionó perfectamente y no hubo ningún error el proceso manual. Así que finalmente, el 5 de febrero de 1971 a las 9:18 UTC el módulo Antares alunizó sin problemas en la zona de Fra Mauro en la Luna para continuar con la misión. El 9 de febrero finalmente la tripulación amerizó sana y salva a las 21:00 UTC terminado con éxito la misión del Apolo 14. Don Eyles continuó trabajando en la NASA durante varios años más contribuyendo a que el resto de las misiones Apolo fuera un éxito total.
Y esto es todo, así que la próxima vez que te sientas bajo presión cuando estés programando, piensa en lo que tuvo que pasar el bueno de Eyles ;)
Happy Hacking Hackers!!!
Autores:
Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.
 |
| Contactar con Fran Ramírez en MyPublicInbox |
Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.
 |
| Contactar con Rafael Troncoso en MyPublicInbox |
Excelente artículo, gracias !
ResponderEliminar