- En el Space Quest II 2.0D/2.0F 720KB Disk 1 de Sierra On-Line había quedado código fuente del intérprete AGI que no aparecía en la lista de archivos, un caso en el que un error al preparar el disco maestro se replicó tal cual en discos comerciales
- En el FAT de DOS, al borrar archivos no se eliminan los datos, solo se marcan los sectores como no usados, por lo que si se usa como maestro un disco sin formatear, los datos previos pueden terminar replicándose en todas las copias
- En el área “free” de 402,432 bytes de Disk 1, en lugar del valor de relleno de formato 0xF6, quedaron fuentes en C/ensamblador, y al extraerlas se confirmaron 93 archivos, más de 15,000 líneas y alrededor del 70% del código fuente del intérprete AGI
- Es posible que el equipo de duplicación FormMaster, al copiar todos los sectores del disco byte por byte en vez de hacerlo a nivel de archivos, también haya propagado a discos para clientes y tiendas datos borrados que no figuraban en la lista real de archivos
- Este error, ocurrido en marzo de 1988 al final de la era AGI, permaneció oculto hasta que NewRisingSun realizó el primer hallazgo conocido en octubre de 2016, y 36 años después se convirtió en material de arqueología digital para examinar la implementación AGI de Sierra
Huellas que no se veían en la lista de archivos
- Los disquetes de 720KB de Space Quest II versión 2.0D y 2.0F no tienen nada especial a simple vista, y su lista de archivos también parece la de un disco común de juego de Sierra
- En el directorio de 2.0D no hay archivos extra sospechosos, y los principales archivos de datos como PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0 y VOL.1 fueron creados el 14 de marzo de 1988
- Los archivos
.OVLtienen fecha del 15 de marzo de 1988, y el código del intérprete AGI lleva marca de tiempo del 18 de marzo de 1988, dejando rastro de que en las oficinas de Sierra la preparación de Space Quest II 2.0D se extendió durante una semana - El espacio usado del disco es de 302,918 bytes, y el espacio “free” aparece como 402,432 bytes, por lo que el espacio vacío era mayor que el ocupado
El área no usada revelada con un editor hexadecimal
- En DOS, los sectores no usados de un disquete recién formateado normalmente se rellenan con el valor de formato 0xF6
- El Disk 2 de Space Quest II 2.0D tenía sus sectores no usados llenos de 0xF6, pero en el Disk 1 no había ni un solo sector no usado rellenado con 0xF6
- En Disk 1, la secuencia continua más larga de bytes 0xF6 era de apenas 2 bytes, y aunque más de la mitad del espacio figuraba como “free”, en realidad seguían quedando datos anteriores
- En el área marcada como no usada había texto que parecía código fuente en C, lo que sugiere con fuerza que ese disco se había usado para otra cosa antes de servir como maestro de Space Quest II Disk 1
- En el sistema de archivos FAT de DOS, borrar un archivo no elimina realmente los datos, sino que marca los sectores como reutilizables, así que si un archivo nuevo no los sobrescribe, el contenido anterior permanece intacto
El código fuente del intérprete AGI que quedó ahí
- Al extraer el texto ASCII del área no usada, se identificaron funciones en C como
DisplayStatusLineyStatusLineOn DisplayStatusLinees código que muestra una línea de texto con el puntaje actual y el estado on/off del sonido, y está vinculado con la barra blanca de estado en la parte superior de la pantalla de Space Quest II- Este código no pertenece a los datos del juego, sino al propio intérprete AGI de Sierra
- En los sectores no usados había una gran cantidad de código fuente, y como estaba almacenado en sectores contiguos, fue relativamente fácil extraerlo y separarlo por archivo
- En la parte superior de cada archivo había comentarios con el nombre del archivo fuente, lo que facilitó encontrar los puntos de corte, y el resultado de la separación fue de 93 archivos en total
- 75 archivos fuente en C
- 16 archivos fuente en ensamblador
- 2 archivos DOS BAT
- El código completo supera las 15,000 líneas, y la mayoría de los archivos estaba en forma completa
- Este disco contenía alrededor del 70% del código fuente del intérprete AGI de Sierra On-Line, incluyendo comentarios e historial de cambios
Historial de cambios y rastros de desarrolladores
- En la cabecera de comentarios de algunos archivos fuente se incluye un Change History
- La cabecera de
ANIMATE.Ccontiene el nombre del archivo fuente, una breve descripción que indica que “procesa un ciclo de animación en un adventure game”, e información comocompile: MWC MWCparece referirse al compilador en C de Mark Williams, muy usado en esa época- El historial de cambios incluye fecha, hora, iniciales de quien hizo el cambio y descripción del cambio
- Entre esas iniciales, JAS corresponde a Jeff Stephenson, quien trabajó principalmente en el código del intérprete AGI, y DCI a Chris Iden
- También aparece Robert Heitman, pero su enfoque principal estaba en herramientas gráficas como Picture Editor y View Editor, mientras que Jeff Stephenson y Chris Iden se encargaban sobre todo del código del intérprete
El mapa de memoria de AGI.EXE y el cálculo del 70%
- Además de los 93 archivos fuente, el Space Quest II 2.0D 720KB Disk 1 también contenía más de 2,000 líneas del mapa de memoria del ejecutable AGI.EXE
- En los juegos AGI publicados, el ejecutable del intérprete se llama simplemente
AGIy no puede ejecutarse directamente, pero durante el desarrollo se usaba un intérprete directamente ejecutable con extensión.EXE - Alguien en Sierra generó el 7 de octubre de 1987 el mapa de memoria de AGI.EXE, es decir, del intérprete AGI
- Esa fecha coincide con el hecho de que el comentario más reciente en el historial de cambios del código fuente es de septiembre de 1987
- El mapa de memoria ofrece una lista relativamente completa de los módulos y archivos fuente que componen el intérprete AGI
- En el mapa de memoria aparecen 98 archivos fuente distintos, y de ellos 71 archivos existen en forma completa en el disco de SQ2
- Con base en esa proporción, se calcula que el disco de Space Quest II contenía alrededor del 70% del código fuente del intérprete AGI
- Algunos módulos solo incluían archivos de cabecera en C, por lo que no se tomaron en cuenta en ese cálculo
AGI como propiedad intelectual de Sierra
- Sierra On-Line atravesó una etapa comercial difícil hacia el lanzamiento de King’s Quest en 1984, y Ken Williams tuvo que despedir a unas 100 personas, reduciendo la plantilla de alrededor de 130 a cerca de 30
- Después, el éxito del sistema de juegos de aventura AGI y de los juegos construidos sobre él ayudó a cambiar la situación de la empresa
- A finales de 1984, King’s Quest entró al top 20 de ventas de software de juegos para computadora y se mantuvo en esa lista durante cerca de medio año, hasta el lanzamiento de King’s Quest II
- También ayudó el acuerdo con Tandy Radio Shack para vender versiones Tandy de los juegos en tiendas Radio Shack
- De 1985 a 1988, los juegos AGI siguieron siendo superventas, y el intérprete AGI era una importante fuente de ingresos y una propiedad intelectual clave para Sierra On-Line
- Que el 70% del código fuente del intérprete AGI se copiara en masa y llegara a decenas o cientos de miles de clientes fue un gran error desde la perspectiva de Sierra
Las consecuencias de omitir el formateo del disco maestro
- Cuando Sierra preparaba el lanzamiento de un juego nuevo, creaba un disco maestro de production copy para usarlo con el equipo de duplicación de discos FormMaster
- FormMaster no copiaba solo los archivos del disco maestro, sino todos los sectores del disco byte por byte, sin importar si estaban en uso o no
- En el Disk 1 de Space Quest II 2.0D y 2.0F, por este método también se copiaron 402,432 bytes que no estaban en uso como archivos reales
- En el proceso de preparación del disco maestro, era necesario formatear por completo el disco antes de copiar los archivos del juego, y Sierra sí realizó correctamente ese paso en la mayoría de sus discos maestros originales
- En el Disk 1 de Space Quest II 2.0D, parece que alguien omitió ese paso de formateo, y el mismo disco se reutilizó también para 2.0F
- Como resultado, es posible que decenas de miles de discos de SQ2 enviados a clientes y tiendas llevaran oculto el 70% del código fuente del intérprete AGI
Un caso de arqueología digital conocido recién en 2016
- Casi con certeza, este incidente fue un error no intencional, y parece que ni Sierra, ni la competencia, ni los clientes se dieron cuenta en ese momento
- El primer hallazgo conocido lo hizo el usuario en línea NewRisingSun en octubre de 2016
- También es importante que esto ocurriera al final de la era AGI
- En marzo de 1988, Sierra ya había desarrollado el sistema de juegos de aventura SCI
- Estaba por lanzar King’s Quest IV, el primer juego en usar SCI
- Si el código fuente del intérprete AGI se hubiera podido revelar por error uno o dos años antes, podría haber sido un problema mucho mayor
- El código fuente extraído del intérprete AGI está subido en este repositorio de GitHub
- La implementación AGILE, un intérprete AGI basado en web, originalmente recibió cierta ayuda de partes del código fuente AGI original
1 comentarios
Opiniones en Hacker News
La versión para DOS de 1989 de Double Dragon II: The Revenge se distribuyó en 2 disquetes, y en uno de ellos venía el código fuente completo en forma de archivo comprimido eliminado.
No aparecía con el comando
DIR, pero se podía recuperar fácilmente: https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)Es gracioso que, incluso en una época en la que literalmente cada byte costaba dinero, haya bastantes casos en los que las entradas FAT de la gente terminaron grabadas en cartuchos.
https://forums.nesdev.org/viewtopic.php?t=17324
Supongo que habrán finalizado el juego, creado algún tipo de disco maestro y luego lo mandaron a la planta de producción masiva; entonces me pregunto cómo un archivo comprimido eliminado terminó en el máster. Tal vez lo copiaron por error y lo borraron antes del lanzamiento.
El primero también fue Spacewar! para DOS, en esa misma computadora. Si no recuerdo mal, cuando llegabas al jefe el juego se colgaba, así que nunca pude terminar Double Dragon II, pero es un buen recuerdo.
Últimamente he estado haciendo mucha ingeniería inversa de ROMs de sintetizadores.
La ROM del Yamaha DX9 tenía fragmentos de la tabla de símbolos del firmware dentro del espacio vacío que quedaba en el binario[0], y también había un bloque grande de código 6303 que probablemente venía del sistema de desarrollo. Encontrar cosas así por casualidad se siente realmente increíble. Me metí tanto en este tema que me sentí como un arqueólogo de software asomándose un poco al pasado, y caí en un agujero de conejo tratando de averiguar qué herramientas de desarrollo usaba Yamaha. No encontré nada concluyente, pero leer documentación de herramientas de desarrollo de la época me hizo valorar más los flujos de trabajo modernos.
0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...
Hice mucho análisis de E/S sin procesar y de sectores de disco sin procesar con una BeBox, y BeOS tenía buenas herramientas para hackear sistemas de archivos. Con eso desarrollé un controlador de sistema de archivos para Windows, que funcionaba lo bastante bien como para recibir el apoyo de Yamaha. Si algún día te dan ganas de hacer ingeniería inversa de la ROM de Yamaha para el A-sampler, contáctame. Me interesa mucho esta área. El trabajo con el DX9/DX7 también es excelente y, como usuario de ambos sintetizadores desde su lanzamiento, me resulta realmente fascinante.
Este juego tuvo un peso tan intenso en mi infancia que, al pensarlo ahora después de tanto tiempo, más bien se siente como un sueño.
Si intento imaginar tener en mi vida actual el mismo tipo de conexión con algún juego, se siente imposible. Todo a mi alrededor se siente simplemente como juegos, series o cosas, pero Space Quest 2, 3 y 4 están entrelazados como una parte fundamental de mi ADN.
Los juegos de Sierra de esa época eran realmente especiales. En particular jugué mucho Police Quest II, LSL III y Hero's Quest en un periodo parecido. Había algo mágico en los juegos de Sierra con texto y gráficos EGA; para mí estaban justo en el punto adecuado de conexión emocional y creativa entre Infocom y las versiones VGA posteriores de apuntar y hacer clic.
Space Quest también está entrelazado con una de mis historias favoritas de la internet temprana. En la época en que los sitios web estaban alojados principalmente en Geocities y por universitarios aburridos, existía un sitio de fans de Space Quest, y le mandé un correo al administrador de uno de los sitios grandes de SQ para decirle que me gustaban los juegos y el sitio. Tendría unos 14 años en ese entonces, y él respondió que podía mandarme los juegos originales por unos 40 dólares. Eran todos los originales, con sus cajas y disquetes. Como era alrededor de 1997, me daba algo de preocupación mandarle 40 dólares a un desconocido al otro lado del país y esperar que de verdad los enviara, pero sí lo hizo. Unas semanas después llegaron todos los juegos tal como los había descrito, y me puse feliz. De la noche a la mañana me convertí en un verdadero creyente, y ese recuerdo sigue siendo como el núcleo solar de optimismo al que aún me aferro. Jess, si estás por ahí, fuiste real. Ojalá nos volvamos a encontrar algún día.
Mi papá trabajaba en una acería y era amigo del encargado de computadoras de ahí, quien le dio una copia de SQ2 para que la probáramos en casa. Jugué ese juego como loco, pero como era bastante chico, muchas partes me confundían. Cuando me quedaba realmente trabado, le pedía a mi papá que le preguntara a ese encargado de computadoras cómo pasar cierta parte, y creo que él, en vez de darme la respuesta directa, me daba pistas amablemente. Han pasado unos 35 años, pero todavía recuerdo con bastante detalle sueños que tuve relacionados con ese juego. De verdad me marcó mucho.
SQ I lo jugué mucho más tarde, y SQ III no me llegó con tanta fuerza. Los demás ya ni siquiera eran juegos EGA con entrada de texto. SQ II me trae muchos recuerdos, y también aprendí bastante inglés con él. Recuerdo la satisfacción de descubrir que podía hacer que Roger Wilco hiciera “rub berries”.
Este fue el primer juego de ese tipo que probé, y me tuvo enganchado durante semanas cuando tenía unos diez años.
No creo que el motor AGI tuviera una salsa secreta tan especial como para que un competidor pudiera beneficiarse de una filtración.
Puede haber otros ejemplos, pero Hugo's House of Horrors fue, unos años después, un juego estilo AGI hecho por una sola persona. Más allá de la novedad inicial de ser una aventura gráfica, los juegos de Sierra funcionaron bien porque se invertía un esfuerzo enorme en hacer los gráficos y escribir el juego en sí. No digo que la tecnología no importara, pero su peso en el resultado final era más bien pequeño.
Aprender y crear software funcional era muchísimo más difícil que hoy, y había muy poco sobre lo cual apoyarse. En MS-DOS casi no había open source significativo, y mucho menos motores de juegos open source. En ese contexto, si el código fuente de AGI se hubiera filtrado ampliamente, al menos podría haber tenido bastante valor como plano que mostraba exactamente cómo se hacían algunos de los juegos de PC más populares de la época.
Sobre todo si no contiene secretos que un hacker pueda explotar, como claves o backdoors. El código filtrado, obviamente, no viene con una licencia, así que si quieres evitar demandas no puedes reutilizarlo tal cual en tu propio producto. Al final tienes que leerlo, entender las técnicas y aplicarlas a tu propio trabajo sin que huela a infracción de copyright, lo cual suele ser más difícil que hacerlo desde cero. Aunque haya casos favorables, también me pregunto con qué frecuencia eso se traduce en una ventaja competitiva real. Los desarrolladores a menudo escriben código nuevo incluso cuando existe open source bien documentado y con licencias permisivas. Leer código muchas veces es más difícil que escribirlo, e incluso simplemente volver a compilarlo puede ser complicado. Podría facilitar un poco la clonación, pero los juegos normalmente se crackeaban y distribuían en cuestión de días, y puede que el código de protección anticopia ni siquiera estuviera incluido en el fuente.
Probablemente había varios órdenes de magnitud menos personas capaces de hablar esos lenguajes, y todavía menos capaces de construir algo coherente con ellos.
Hoy está bajando rápidamente, así que lo que uno encuentra ahora no tiene tanta fuerza para formar los pesos internos como en aquella época.
Me encantan los comentarios de historial de cambios.
Muestran un nivel alto de cuidado y artesanía de una época muy anterior a que las herramientas de control de versiones hicieran visible ese tipo de cosas con claridad. Sinceramente, incluso después de CVS/SVN/Git, para mucha gente eso siguió sin estar claro. Este artículo también me recuerda al famoso texto “No Silver Bullet”[1] de 1986, que predecía que el software seguiría siendo, en gran medida, como entonces: programadores escribiendo trabajosamente una instrucción tras otra. El hecho de que el código del motor de juego y los comentarios del artículo original se parezcan a algo que yo podría haber escrito hoy, casi 40 años después, me parece que sigue respaldando esa predicción.
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
La versión de Famicom de Air Fortress tiene una cantidad absurdamente grande de cosas que terminaron en la ROM sin querer.
Incluye código ASM sin compilar, listados de directorios de MS-DOS, cadenas de uno de los EXE usados para construir el juego y más. El cartucho japonés era de 128+128 KB. Más tarde, al hacer la versión estadounidense para NES, descubrieron que la mayor parte de los 128 KB de datos gráficos eran gráficos duplicados o sin usar, y que los gráficos únicos reales ocupaban unos 36 KB. Quitaron la imagen de un planeta de uno de los finales para reducir los gráficos a 32 KB, y lo lanzaron en un cartucho de 128+32 KB en vez de uno de 128+128 KB.
Fuente: https://tcrf.net/Air_Fortress
Este tipo de cosas pasaba muy seguido en la práctica.
The Cutting Room Floor enumera alrededor de 500 casos, desde juegos que traen un poco de código incluido por accidente hasta otros que traen la mayor parte.
https://tcrf.net/Category:Games_with_uncompiled_source_code
Me pregunto si yo llegaría a la misma conclusión. En los discos de King's Quest III ocurrió lo mismo y, de hecho, parece haber pasado casi al mismo tiempo que el caso de Space Quest II.
Mi parte favorita es que, aparentemente, nadie descubrió el código fuente en el disco durante toda una generación.
“Sorprendentemente, parece que ni Sierra, ni sus competidores, ni sus clientes se dieron cuenta de que esto había ocurrido, y solo se descubrió décadas después. El primer hallazgo conocido fue en octubre de 2016 por el usuario en línea NewRisingSun”. También me vienen a la mente los avances recientes en Tetris y Super Mario Bros. Cuando jugaba estos juegos de niño, pensaba que décadas después quedarían como reliquias olvidadas, imposibles siquiera de ejecutar salvo para los aficionados más dedicados. Pero Internet y los emuladores les dieron nueva vida a esos primeros juegos y a la computación temprana.
Seguramente hubo personas que descubrieron los archivos borrados, pero antes de que Internet se volviera común es muy probable que no se difundiera ni quedara registrado ampliamente.
Al crear imágenes de estos discos, alguien pudo haber encontrado datos que quedaron en el espacio libre.
Entre 1987 y 1993 preparé unas nueve discos maestros para dos apps de Mac.
Siempre usaba disquetes nuevos y tenía una larga lista de verificación para asegurarme de que el disco fuera el correcto. Por suerte, todos salieron bien, y algunos en particular se usaron para fabricar 100.000 discos. Me alegra que ya nadie tenga que hacer esto.
He visto capas así: base, agregar herramientas, agregar código fuente, compilar, borrar código fuente, borrar herramientas adicionales, lanzar. Situaciones del tipo: “¿Por qué la imagen de Docker es tan grande? Bueno, el almacenamiento es barato...”. También hay soluciones sencillas como las compilaciones multietapa ( https://docs.docker.com/build/building/multi-stage/ ). Pero si no sabes que la vista actual de una imagen de Docker incluye todas las capas anteriores, a veces ocurren errores.
En la época en que los artefactos de release se armaban a mano, a menudo se incluían restos que no estaban destinados a publicarse.
Cosas como contenido recortado[1] o símbolos de depuración[2]. Cuando encontré por casualidad símbolos de depuración ocultos dentro del archivo de datos de una versión demo de un videojuego que estaba haciendo ingeniería inversa, fue inesperado, pero de enorme ayuda. Hoy, gracias a CI/CD, builds automatizados y otras prácticas modernas de desarrollo, probablemente esto ocurra menos.
[1] https://tcrf.net
[2] https://www.retroreversing.com/games/symbols
Si no hay errores, nadie revisa miles de líneas de salida de consola. Aunque el paquete final de release incluya demasiado contenido innecesario, es probable que las pruebas pasen. Así que mi intuición va más bien en la dirección contraria: podría ocurrir con más frecuencia, o al menos CI/CD podría hacer que esto pase más fácilmente que con builds manuales. También puede haber otros factores.