Nanolathe: ingeniería inversa clean-room, explicada

⏱️ Lectura: 14 min

Un equipo de desarrolladores lanzó un motor que revive Total Annihilation, el clásico RTS de 1997, sin haber visto una sola línea del código original. Nanolathe, publicado bajo licencia MIT, reconstruye el juego completo mediante ingeniería inversa clean-room: documentaron el comportamiento del binario, anotaron cada formato de archivo y escribieron un motor nuevo desde esa documentación.

📑 En este artículo

1. TL;DR
2. ¿Qué es la ingeniería inversa clean-room?
3. Por qué importa
4. Cómo funciona en detalle
5. Ejemplos prácticos
   1. El BIOS que inició la práctica
   2. ReactOS y el núcleo de Windows
   3. Nanolathe y Total Annihilation
6. Cómo empezar
7. Casos de uso reales
8. Errores comunes y buenas prácticas
9. Comparación con otras formas de revivir software viejo
10. Profundizando
11. Preguntas frecuentes
    1. ¿Qué es la ingeniería inversa clean-room y por qué Nanolathe la usó?
    2. ¿Necesito tener Total Annihilation para jugar con el motor de Nanolathe?
    3. ¿El motor de Nanolathe corre en Linux y Mac, o solo en Windows?
    4. ¿El diseño de sala limpia es legal en cualquier país?
    5. ¿Se puede jugar Nanolathe en multijugador con amigos?
    6. ¿Qué significa la reconstrucción de formatos propietarios que hizo Nanolathe?
12. Referencias
    1. 📚 Artículos relacionados

La técnica no es tan nueva como parece: Phoenix Technologies la usó para clonar la BIOS de IBM en 1984, y hoy mantiene viva a ReactOS. Lo que cambia con Nanolathe es la escala, aplicada a un motor de juego completo con renderizador y red propios, no solo a un chip.

TL;DR

• El diseño de sala limpia separa a quien documenta el binario de quien escribe el código nuevo, sin excepciones.
• La licencia MIT de Nanolathe cubre el motor, no los archivos del juego, que siguen siendo del estudio original.
• Las texturas del renderizador moderno se sintetizan en 64×64 a partir de los tiles originales de 32×32 píxeles.
• Jugar la demo del navegador no exige instalar nada: alcanza con Chrome, Edge o Safari de escritorio.
• Reimplementar un formato propietario exige documentar el comportamiento observado, nunca copiar el código que lo produce.

¿Qué es la ingeniería inversa clean-room?

La ingeniería inversa clean-room es un método de desarrollo de software en el que un equipo documenta el comportamiento de un programa ajeno sin tocar su código, y un segundo equipo, aislado del primero, escribe una implementación nueva a partir de esa documentación.

La separación entre ambos equipos es lo que sostiene legalmente el método. Si alguien que vio el código original participa en la escritura del software nuevo, el resultado deja de poder defenderse como desarrollo independiente. Por eso quienes practican el diseño de sala limpia documentan por escrito cada decisión, cada prueba y cada fuente consultada, de forma que pueda demostrarse que el equipo que escribió el código final nunca tuvo acceso al original.

Esa documentación no es un resumen informal: es una especificación técnica completa, suficiente para que un tercero pueda construir un programa equivalente sin haber visto jamás el binario que la originó.

Por qué importa

Para un desarrollador, este método resuelve un problema que ni el código abierto ni la piratería resuelven: cómo mantener viva una pieza de software cuyo dueño ya no la soporta, sin infringir derechos sobre el código que la hace funcionar. Nanolathe no redistribuye los archivos de Total Annihilation: le pide al jugador que aporte los suyos, comprados en GOG, Steam o en los CD originales, y solo aporta el motor que los interpreta.

La misma lógica sostuvo, en 1984, la defensa de Phoenix Technologies ante la acusación de haber copiado la BIOS de IBM. Phoenix nunca tuvo acceso al código fuente de IBM: documentó el comportamiento observado de la BIOS original y escribió una implementación propia desde esa documentación. Ese precedente convirtió a la reconstrucción de formatos propietarios en una defensa legal reconocida, la misma que hoy sostiene a ReactOS.

También importa para la preservación digital. Muchos juegos y programas de los noventa no corren en hardware moderno y sus dueños no van a relanzarlos. Clonar su comportamiento con documentación verificable es, por ahora, la única vía legal para que esas obras sigan siendo jugables dentro de veinte años.

Cómo funciona en detalle

El proceso de diseño de sala limpia se organiza en fases que rara vez se saltan, porque saltarlas invalida la defensa legal completa.

• Observación externa: el equipo de análisis ejecuta el programa original y registra qué hace, nunca cómo lo hace por dentro.
• Documentación formal: cada byte de un formato de archivo o cada respuesta de una interfaz se anota en una especificación independiente del código.
• Muro de separación: ninguna persona que trabajó en la fase anterior participa en la siguiente, y en proyectos grandes ni siquiera pueden comunicarse durante el desarrollo.
• Implementación nueva: un segundo equipo, que solo vio la especificación, escribe el software desde cero, con sus propias decisiones de diseño interno.
• Verificación cruzada: se compara el comportamiento del software nuevo contra el original, nunca comparando el código fuente de ambos.

flowchart TD
A["Equipo de análisis"] --> B["Documentación y especificación"]
B --> C["Muro de separación legal"]
C --> D["Equipo de implementación limpia"]
D --> E["Software nuevo e independiente"]

En el caso de Nanolathe, ese trabajo recae sobre los formatos propios de Total Annihilation: los archivos HPI que empaquetan los recursos del juego, los modelos 3DO que definen la geometría de cada unidad y los scripts COB que controlan su comportamiento en combate. El propio sitio del proyecto resume esa etapa como leer los formatos del juego, estudiar el diseño del motor y seguir la evidencia detrás de su comportamiento, una descripción que encaja exactamente con el método de sala limpia aplicado a un juego de 1997.

La prueba de que el motor nuevo se comporta igual que el original no se basa en comparar código, sino en comparar resultados. El sitio de Nanolathe publicó una comparación entre su renderizador clásico y el moderno, generada con la build 617540c5 del 4 de octubre de 2026, donde la caché de tiles pasa de los 32×32 píxeles originales a tiles sintetizados de 64×64. Esa comparación, capturada a 960×640 sin recortes ni retoques, es el tipo de evidencia que sostiene una reconstrucción de formatos propietarios: no hace falta mostrar una línea de código para demostrar que el comportamiento es equivalente.

Ejemplos prácticos

El BIOS que inició la práctica

En 1984, Phoenix Technologies necesitaba un BIOS compatible con el IBM PC sin copiar el código de IBM. Contrató a ingenieros que nunca habían visto ese código, les entregó una especificación funcional escrita por otro equipo y dejó que reconstruyeran el comportamiento desde cero. El resultado permitió que decenas de fabricantes construyeran PCs compatibles sin pagar licencia a IBM, y fijó el estándar legal que toda reconstrucción posterior intenta seguir.

ReactOS y el núcleo de Windows

ReactOS documenta públicamente su política de desarrollo en sala limpia: cualquier colaborador que haya tenido acceso al código fuente de Windows queda inhabilitado para escribir código del proyecto. En cambio, puede participar en la documentación de comportamiento observado, que luego usa otro colaborador sin ese historial para programar la pieza equivalente.

Nanolathe y Total Annihilation

Nanolathe aplica la misma separación a un juego completo: no solo al motor gráfico, sino también a la física de combate, al sistema de scripts de las unidades y al código de red que sincroniza una partida multijugador. El código resultante es MIT, pero no incluye ni un solo recurso del juego original: ni modelos, ni sonidos, ni texturas, ni el ejecutable de 1997.

Cómo empezar

Si solo querés ver el resultado de este trabajo, no necesitás instalar nada ni poseer el juego original.

1. Abrí nanolathe.gg desde un navegador de escritorio: Chrome, Edge y Safari funcionan, aunque Firefox, móvil y tablet todavía no están verificados por el proyecto.
2. Elegí la opción para jugar la demo y cargá las tres misiones de la campaña de demostración original. Los archivos se descargan al vuelo y quedan en caché para la próxima visita.
3. Si ya tenés una copia de Total Annihilation (en GOG, Steam o en tus CD originales), instalá la beta nativa para Windows, Mac o Linux y apuntala a esos archivos: ahí se desbloquean skirmish, survival y la campaña completa, con cada partida grabada como replay.
4. Para jugar en línea, elegí la opción multijugador del menú principal, generá un código de partida y compartilo con otra persona: el anfitrión decide si la partida corre con reglas modernas o con las reglas clásicas de versiones anteriores.

El motor está bajo licencia MIT, así que el código se puede leer, modificar y redistribuir sin pedir permiso. Lo único que esa licencia no cubre son los archivos del juego original, que siguen siendo propiedad de su dueño.

Casos de uso reales

Los equipos de preservación de videojuegos recurren a este método cuando el dueño original de un título no tiene interés comercial en relanzarlo, pero tampoco cede los derechos: documentan el comportamiento, publican la especificación y dejan que la comunidad construya el motor, igual que ocurrió con Nanolathe y Total Annihilation.

Los equipos legales de software empresarial usan el diseño de sala limpia cuando necesitan interoperar con un formato de archivo propietario sin firmar un acuerdo de licencia. Es el mismo principio, aunque a otra escala, que permitió que servidores Unix hablaran el protocolo de archivos de Windows sin copiar código de Microsoft.

Y porque el código de Nanolathe es MIT, cualquier estudio pequeño o modder puede tomarlo como base para un juego nuevo con mecánicas propias, sin pedir permiso ni pagar regalías, siempre que no redistribuya los archivos originales de Total Annihilation junto con el motor.

Errores comunes y buenas prácticas

• Contaminación del equipo: si una sola persona del equipo de implementación leyó alguna vez el código original, toda la defensa legal se cae, aunque esa persona no haya escrito una sola línea.
• Documentación incompleta: una especificación con huecos obliga al segundo equipo a adivinar, y adivinar mal produce bugs que no existen en el original.
• Mezclar activos con código: redistribuir los archivos del software original junto con el motor nuevo anula la separación legal entre ambos, aunque el código en sí sea propio.
• Subestimar el tiempo: documentar un formato binario completo toma, casi siempre, más tiempo que escribir el código que después lo interpreta.

⚠️ Ojo: redistribuir los archivos originales de Total Annihilation junto con el motor, aunque sea por error, convierte un proyecto MIT en una violación de derechos de autor. La separación entre motor y datos no es un detalle legal menor.

Comparación con otras formas de revivir software viejo

No todas las formas de resucitar un programa viejo implican el mismo riesgo legal ni el mismo nivel de fidelidad al original.

Profundizando

Lo que distingue a un proyecto de sala limpia serio de uno improvisado es la trazabilidad. Cada afirmación de la especificación tiene que poder rastrearse hasta una observación concreta: una captura de red, un volcado de memoria leído solo en modo lectura, una tabla de bytes anotada byte por byte. Sin esa trazabilidad, nadie puede probar después que el equipo de implementación no vio nunca el original.

flowchart LR
A["Archivos originales de Total Annihilation (HPI, 3DO, COB)"] --> B["Motor Nanolathe (MIT, código nuevo)"]
B --> C["Renderizador clásico o moderno"]
C --> D["Partida jugable en Windows, Mac, Linux o navegador"]

Ese esquema explica por qué Nanolathe puede ofrecer dos renderizadores (uno fiel al original de 1997 y otro con iluminación y resplandor modernos) sin tocar los datos del juego: ambos leen la misma especificación de formatos, solo cambia cómo se dibuja el resultado final en pantalla.

💭 Clave: la defensa legal del diseño de sala limpia no depende de la intención de quien escribe el código: depende de poder probar, con documentos, que nunca tuvo acceso al original.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: abrí la demo de Nanolathe en el navegador, fijate qué misión original carga primero y comparala con un video de la campaña clásica de 1997 para notar dónde cambia el renderizado moderno.

Preguntas frecuentes

¿Qué es la ingeniería inversa clean-room y por qué Nanolathe la usó?

Es el método que separa a quien documenta un programa ajeno de quien escribe el código nuevo, para que el resultado no derive legalmente del original. Nanolathe lo usó porque Total Annihilation no es software libre: sin esa separación, reconstruir sus formatos habría sido una copia no autorizada, no un desarrollo independiente.

¿Necesito tener Total Annihilation para jugar con el motor de Nanolathe?

No, para la demo del navegador: incluye las tres misiones del demo original, así que podés probarlo sin carpeta de juego. Para la experiencia completa necesitás tus propios archivos de una copia legítima, comprada en GOG, Steam o en los CD originales.

¿El motor de Nanolathe corre en Linux y Mac, o solo en Windows?

Corre de forma nativa en Windows, Mac y Linux, además del demo en navegador de escritorio con Chrome, Edge o Safari. Firefox, móvil y tablet todavía no están verificados por el proyecto.

¿El diseño de sala limpia es legal en cualquier país?

No de forma automática: depende de la legislación de cada país y de que el proceso esté bien documentado. El precedente más citado es el de Phoenix Technologies, que en 1984 defendió con éxito su BIOS clonada mostrando que nunca tuvo acceso al código de IBM.

¿Se puede jugar Nanolathe en multijugador con amigos?

Sí, tanto en el juego instalado como en Chrome o Edge de escritorio, y ambos pueden jugar entre sí. El modo skirmish admite entre 2 y 10 jugadores, y survival entre 2 y 3; cada partida queda grabada como replay.

¿Qué significa la reconstrucción de formatos propietarios que hizo Nanolathe?

Significa escribir, a partir de observar el comportamiento de un archivo binario, una especificación completa de su estructura sin haber leído nunca el código que lo generó. Esa especificación es lo que permitió escribir un motor nuevo capaz de leer los HPI, 3DO y COB originales de Total Annihilation.

Referencias

• Nanolathe: sitio oficial del proyecto, con la demo jugable, el registro de la build 617540c5 y las preguntas frecuentes sobre el beta nativo.
• Wikipedia: Clean room design: explicación general del método legal de ingeniería inversa documentada.
• Wikipedia: BIOS: historia de la reimplementación de la BIOS de IBM por Phoenix Technologies en 1984.
• ReactOS: proyecto de sistema operativo que documenta públicamente su política de desarrollo en sala limpia.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Juanjo Jaramillo en Unsplash