La revolución industrial en ingeniería inversa.

Qué cambió en agosto de 2026

Antes de este trabajo, había hecho mucha ingeniería inversa manual. Inspeccionaba una función hasta que tenía una explicación, luego probaba esa explicación con el programa. Llegar más lejos significaba dedicar más tiempo a la siguiente función. También significaba mantener una imagen cada vez más grande en mi cabeza.

La mayor parte de mi trabajo de RE es en juegos. Los reconstruyo para que su comportamiento pueda entenderse y eventualmente llevarse a un puerto de software o un mod. Esa es la experiencia detrás de este artículo. El método puede ser útil en otros lugares, pero cada campo necesita establecer qué puede verificar con una referencia confiable.

En agosto de 2026, comencé a explorar seriamente la realidad aumentada impulsada por agentes. Quería ver hasta dónde podía llegar un agente con acceso al programa y las herramientas de desarrollo ordinarias. La reconstrucción de Touhou me dio un proyecto sustancial en el que averiguarlo.

El progreso inicial fue sorprendente. Una investigación podría seguir avanzando sin que yo eligiera cada paso individual. Una comparación fallida podría enviar al agente a otra persona que llama. Podría escribir un pequeño diagnóstico y usar el resultado para decidir qué probar a continuación. Darle esa libertad marcó la diferencia: pude dedicar más atención a la dirección del proyecto y a si sus controles eran confiables.

El ritmo llamó mi atención primero. Entonces comencé a preguntarme qué sobreviviría más allá del proyecto actual. ¿Se beneficiaría el próximo juego de todo lo que acabábamos de aprender?

TH08: construyendo sobre el trabajo humano

TH08 , Noche Imperecedera, comenzó como una continuación de Reconstrucción de GensokyoClub. Su fuente pública me dio una base sustancial. Vino con el conocimiento de la construcción y una historia de contribuciones que conservé en la continuación.

El historial importado finaliza en el punto de control público del 10 de agosto. Mi continuación independiente comenzó el 13 de agosto. Para el 19 de agosto, el libro mayor registró la fuente de las 1.107 funciones de juego identificadas.

Un puerto de reconstrucción Linux jugable se comprometió el 24 de agosto, aproximadamente once días después de que comenzara la continuación. Siguió una edición web. La versión nativa Linux de 64 bits llegó el 30 de agosto.

Lo que me llamó la atención fue que el trabajo había llegado a un programa que la gente podía ejecutar. Llegar allí requería seguir problemas más allá de una función individual. Incluso cuando dos funciones parecían correctas de forma aislada, accidentalmente podían usar copias separadas de estado que deberían haberse compartido.

Esto hizo que las verificaciones de referencias fueran fundamentales para el trabajo. Yo los llamo referencias de verificación (oráculos). Una comparación de código puede decirnos si una función reconstruida reproduce las instrucciones originales. Una verificación en tiempo de ejecución puede indicarnos si una ruta ejercitada alcanza el estado esperado. El agente propone una explicación y la prueba; un desajuste le da algo específico para investigar.

Una coincidencia exacta con la constante incorrecta

Una referencia de verificación (oracle)es un software que alguien escribió. TH08 me dio un claro recordatorio de cuánto puede depender de ese software.

En septiembre, un error reportado por un puerto de conmutador descendente condujo de nuevo a la recopilación automática de elementos. La fuente reconstruida verificó la potencia del jugador contra 0.0. El original usado 128.0, el umbral de potencia máxima.

La potencia normal no es negativa, por lo que la comprobación de potencia reconstruida siempre se cumplió de manera efectiva. Por encima de la línea de recolección, el juego podría atraer elementos sin requerir la máxima potencia. Las otras excepciones en la condición eran correctas. Esta constante cambió el comportamiento.

Sin embargo, la función ya había pasado la comparación exacta.

Una reconstrucción puede colocar una constante en una dirección diferente. La herramienta de comparación explicó eso ajustando las direcciones en las instrucciones compiladas antes de compararlas con las originales. Pero nunca verificó el valor de coma flotante almacenado en la dirección a la que se hace referencia.

Eso dejó un agujero en el cheque. Podría apuntar la instrucción reconstruida a la del original 128.0 mientras que la fuente todavía dijo 0.0. Los bytes de instrucción coincidieron. La fuente significaba algo diferente.

El Corrección del 2 de septiembre corrigió la fuente e hizo que la comparación verificara los bytes reales de la constante referenciada. A auditoría más amplia luego examinó 1.548 referencias constantes de coma flotante. Encontró otras doce referencias incorrectas en cinco funciones aceptadas.

La comparación ahora verifica cada una de esas constantes de coma flotante. Sus pruebas incluyen valores deliberadamente incorrectos para asegurarse de que sean rechazados. También tuvimos que revisar los resultados que habían pasado la verificación más débil.

La referencia de verificación (oracle) también necesitaba reconstrucción. Repararlo era parte de reparar el juego.

Eso importa cuando el equipo es principalmente una persona que trabaja con agentes. No puedo inspeccionar personalmente cada línea que producen, por lo que gran parte de mi confianza se basa en sus controles. El punto ciego de una referencia de verificación compartida (oracle) puede afectar muchas investigaciones antes de que me dé cuenta. Tengo que entender qué verifica realmente el verificador y probarlo con los casos que deberían fallar.

A medida que continuaba el trabajo, esas comprobaciones pasaron a formar parte del repositorio. También lo hicieron los motivos de los cambios de origen y las notas que permitían que una sesión posterior retomara donde se detuvo una anterior. El repositorio de código fuente se estaba convirtiendo en la memoria de trabajo del proyecto.

Un lote exitoso nos dio tanto el código recuperado como un mejor entorno para el siguiente lote.

Dos ideas diferentes de reconstrucción

GensokyoClub ' s LÉAME público explicita su desacuerdo con este tipo de trabajo. El aviso anuncia que se realizarán desarrollos adicionales de forma privada hasta su finalización. Un pasaje dice:

El aumento de estafadores (descompilaciones y puertos de IA) en este espacio que se aleja de nuestro trabajo pinta una mala imagen para futuros esfuerzos de descompilación…

El aviso también describe el costo psicológico para los mantenedores. Su política de contribución excluye las solicitudes de extracción producidas principalmente con IA. Han dedicado su tiempo libre a un trabajo difícil, y ese trabajo ayudó a que mi continuación fuera posible. Respeto el esfuerzo que hay detrás. El desacuerdo que quiero discutir es sobre cómo debe proceder la reconstrucción y cómo debe juzgarse una contribución.

En el flujo de trabajo manual que conocía, desarrollar una comprensión de una función y reconstruirla generalmente recaía en la misma persona. Un proyecto dependía en gran medida de la experiencia de esa persona. La confianza en el colaborador importaba porque gran parte del razonamiento ocurría mientras trabajaban.

Los proyectos existentes ya preservan el conocimiento en su fuente y crean herramientas. Lo que cambió para mí fue que un agente podía usar ese conocimiento para llevar a cabo la próxima investigación por su cuenta.

En mi continuación, decido el objetivo y el estándar para aceptar un resultado. El agente tiene amplia libertad para investigar. Su reconstrucción propuesta tiene que sobrevivir a los controles pertinentes. Quiero que otra persona pueda examinar por qué elegimos una implementación, incluso si un agente hizo la mayor parte del trabajo.

Esta puede ser una transición difícil. Años de trabajo cuidadoso pueden convertirse en la base para una continuación que avanza mucho más rápido. Eso plantea preguntas reales sobre el crédito. También cambia lo que los mantenedores necesitan saber antes de aceptar una contribución.

La analogía industrial me ayuda a pensar en esto. En un oficio, gran parte del proceso depende de la habilidad de la persona que lo lleva a cabo. La maquinaria cambia donde se necesita esa habilidad. Alguien todavía tiene que diseñar el proceso y reconocer cuándo su resultado es incorrecto. Diferentes comunidades pueden elegir cuánto de ese cambio quieren asumir.

Mi elección es continuar abiertamente, con el trabajo heredado acreditado y su historia preservada. Quiero que el nuevo trabajo sea revisable. Eso nos da una forma de preguntarnos hasta dónde puede llegar este enfoque y de aprender de lo que sale mal en el camino.

Fuente: GensokyoClub ' s Aviso léame, revisado el 10 de octubre de 2026, y su política de contribuciones. La cita es un extracto abreviado. TH08 ' s créditos y procedencia registre el límite de continuación.

TH095: la experiencia comienza a agravarse

TH095 , Dispara la bala, hizo que el valor de esa experiencia fuera mucho más fácil de ver. Su repositorio comenzó el 29 de agosto con cero funciones de juego confirmadas en el libro mayor. Todavía teníamos que aprender el juego. Pero ya sabíamos mucho más sobre cómo comenzar una reconstrucción y cómo mantenerla en marcha.

Para el 7 de septiembre, las 697 funciones de juego identificadas tenían fuente. Para el 8 de septiembre, 696 habían sido aceptadas como comparaciones exactas. Todo el programa enlazado el 9 de septiembre. La reconstrucción del Windows i386 se marcó como jugable el 10 de septiembre, aproximadamente doce días después de la inicialización.

Encontré esto más emocionante que la velocidad del primer proyecto. Un objetivo nuevo podría beneficiarse del trabajo realizado en otro juego. La experiencia ya estaba presente en las herramientas y en la forma en que se organizó el proyecto.

Por ejemplo, TH08 nos había enseñado a prestar atención al programa ensamblado temprano. Si varias funciones recuperadas dependen del mismo estado, sus comparaciones aisladas dejan abierta una pregunta importante. Necesitamos verlos trabajar juntos. Esa lección ayudó a dar forma a la forma en que abordamos la compilación de todo el programa de TH095.

Una lección que se queda en mi cabeza es útil mientras estoy allí. Una vez que se convierte en una verificación de que se puede ejecutar otra sesión, puede seguir ayudándome después de que haya seguido adelante. El siguiente agente puede usar el resultado sin repetir la investigación que lo condujo.

El error constante de coma flotante también pertenece a esa memoria. Explica por qué verificar una referencia también requiere verificar los datos detrás de ella. Mantener esa corrección con el código ayuda a que los proyectos posteriores eviten heredar el punto ciego del cheque anterior.

El método se convierte en parte del material de partida para el próximo juego. Podemos dedicar más esfuerzo del próximo proyecto a lo que realmente es nuevo sobre su objetivo.

El mismo beneficio está disponible para las personas que se unan más tarde. Pueden inspeccionar una decisión y volver a ejecutar su verificación antes de continuar con el trabajo. No tienen que reconstruir todo el historial del proyecto para descubrir por qué la fuente se ve de la manera en que lo hace.

TH04: el flujo de trabajo sobrevive a una arquitectura diferente

TH04 , Lotus Land Story, llevó este trabajo a la era PC-98 DOS. El objetivo ahora era un entorno de 16 bits con cuatro programas cooperantes. Comprender su comportamiento de hardware requirió evidencia diferente de los juegos Windows. Existentes Trabajo ReC98 también nos dio valiosos conocimientos y material de origen aquí.

La reconstrucción de DOS ahora está funcionando. En mis pruebas manuales, jugué rutas normales completas a través de sus finales y verifiqué las salvaciones. El trabajo actual es un puerto nativo de 64 bits. Establecer una versión de DOS que funcione primero le da a ese puerto una referencia.

La arquitectura cambió lo que necesitábamos investigar. También cambió el compilador y el tiempo de ejecución con los que verificamos nuestro trabajo. Pero el agente aún podría seguir una pregunta hasta un resultado y dejar que ese resultado guíe el próximo experimento.

Considere la transición del juego a un final. Necesitamos saber qué estado cruza esa frontera y qué programa es responsable de ello. Eso es algo que podemos investigar contra el producto DOS. Una vez que las pruebas y los controles estén disponibles, un agente puede resolver la pregunta de la misma manera que lo hizo con un título Windows.

Es por eso que TH04 es importante para el argumento. Un cambio sustancial en la plataforma no nos obligó a empezar de nuevo con una nueva forma de trabajar. La arquitectura definió el problema; el flujo de trabajo aún nos dio una forma de resolverlo.

Para el puerto de 64 bits, ahora podemos examinar la nueva implementación con el comportamiento ya recuperado en DOS. El conocimiento de la reconstrucción le da al puerto algo sobre lo que construir.

Estado del proyecto al 10 de octubre de 2026: Reconstrucción de DOS y pruebas manuales · puerto de 64 bits. El puerto permanece en desarrollo.

Del código exacto al código legible

Una vez que una reconstrucción funciona, quiero que alguien más pueda entenderla.

Para mí, el ensamblaje y las compensaciones brutas pueden parecer viejos amigos. Me doy cuenta de que esta es una definición un poco inusual de "legible."La mayoría de la gente preferiría seguir la lógica del juego sin tener en mente el diseño de la memoria del ejecutable.

Ahí es donde reconstrucción semántica entra. Un campo recuperado aún puede conocerse principalmente por su desplazamiento. Seguimos cómo lo usa el juego hasta que podamos explicar su función. Entonces podemos darle un nombre significativo y un tipo que se ajuste a la evidencia. Mantenemos el razonamiento con la fuente para que la siguiente persona pueda ver de dónde vino esa interpretación.

Esto se vuelve especialmente importante para un puerto de software. Una dirección absoluta me dice dónde vivía algo en el antiguo ejecutable. Le da a una implementación de 64 bits poca ayuda para decidir qué objeto debería poseer ese estado. Para mover el comportamiento de manera segura, necesitamos recuperar la relación detrás del antiguo acceso a la memoria.

El orden que uso ahora es:

1. Recupere una línea de base exacta. Compila las piezas reconstruidas con el compilador histórico. Compare el código y los datos relevantes con el ejecutable original. Registre las diferencias no resueltas para que la siguiente fase tenga un punto de partida claro.
2. Compílalo y reprodúcelo en la plataforma original. Vincule esas piezas al programa real utilizando la arquitectura y el compilador originales. Ejercita rutas de juego importantes. Aquí es donde podemos encontrar problemas con el estado compartido o la inicialización que una comparación de funciones aisladas pasó por alto.
3. Reconstruye la semántica contra ambas referencias. Tome una parte coherente del juego a la vez y establezca qué significa su fuente recuperada. Mejore su representación al tiempo que conserva las comparaciones exactas y la construcción histórica jugable.
4. Haz el puerto moderno. Mueva el comportamiento establecido al nuevo entorno, como una compilación nativa de 64 bits. El juego de plataformas original reconstruido sigue siendo una referencia para comparar cómo se comporta el puerto.

La construcción jugable de la segunda etapa se convierte en un segunda referencia de verificación (oracle) durante la tercera. La primera referencia de verificación (oracle) verifica si nuestra fuente modificada aún reproduce el código y los datos originales relevantes. El segundo verifica que el programa reconstruido aún se construya y se comporte correctamente a lo largo de las rutas que ejercitamos.

Detectan diferentes errores. Un cambio de tipo puede alterar las instrucciones generadas. Un cambio de propietario puede dejar dos partes del juego usando diferentes copias de estado. Mantener ambos controles disponibles le da al agente una falla concreta para investigar antes de llevar a cabo una refactorización adicional.

Un nombre necesita evidencia propia. Una comparación exacta no puede decirnos si un campo realmente significa "tiempo de invulnerabilidad"."Tenemos que establecer eso a partir de cómo el juego lo escribe y lo usa. Si el significado sigue siendo incierto, un nombre neutral es más útil para el próximo lector que una suposición segura.

Aprendimos este orden a través de los proyectos. TH08 ya tenía puertos reproducibles antes de algunas de sus auditorías históricas posteriores de la plataforma. Eso hizo que ciertos defectos fueran más difíciles de ver. El Flujo de trabajo actual de la fábrica coloca la compilación de la plataforma original en primer lugar, de modo que el trabajo semántico pueda usarla como referencia antes de que comience la migración.

La reconstrucción exacta nos da una referencia. La reconstrucción semántica hace utilizable el conocimiento recuperado. Entonces, un puerto puede basarse en ambos.

Qué hace que esto sea un cambio industrial

Estos proyectos cambiaron donde dediqué mi atención. Una vez que los agentes pudieron llevar adelante gran parte de una investigación, mejorar su entorno de trabajo se convirtió en una de las cosas más útiles que pude hacer. Una herramienta mejor podría ayudar con cada función posterior que la necesitara.

La autonomía importa aquí. El siguiente paso útil a menudo se aclara solo después de un experimento fallido. Un agente necesita suficiente libertad para seguir ese resultado en algún lugar inesperado. Si tiene que esperar a que prescriba cada paso, gran parte del trabajo permanece atado a mi atención.

Espero que el agente haga hipótesis equivocadas. Lo que importa es si podemos probarlos y aprender del resultado. Una verificación fallida debería ayudarlo a comprender el error lo suficientemente bien como para intentarlo de nuevo. Todavía tengo que decidir si la evidencia acumulada respalda un hito del proyecto.

REA le da al agente acceso a herramientas de análisis. Una pregunta sobre la persona que llama a una función puede llevar directamente a inspeccionar a esa persona que llama. El proyecto de reconstrucción proporciona el compilador y sus propias comprobaciones de referencia. El agente puede usarlos para probar la fuente que propone y ver dónde se sostiene su explicación.

El error TH08 muestra por qué esas comprobaciones merecen su propia atención de ingeniería. Cuando se usa la misma comparación en cientos de funciones, una brecha en ella puede extenderse mucho más allá de un error en una implementación. Probar el verificador mejora la retroalimentación disponible para todo ese trabajo posterior.

La analogía industrial tiene un ejemplo histórico útil aquí. Boulton y Watt introdujeron un indicador de máquina de vapor en 1796 para ayudar a ajustar las válvulas del motor. Una versión de registro trazó la presión a través de la carrera del pistón. Hizo que el comportamiento interno del motor estuviera disponible para su inspección. Nuestras herramientas de comparación tienen un propósito similar: nos permiten examinar qué está haciendo la maquinaria mientras la mejoramos.

Estamos en las primeras etapas de este cambio industrial. Gran parte de la infraestructura aún es inmadura. Los agentes pueden moverse más rápido de lo que nuestras verificaciones fueron diseñadas para soportar, por lo que el proceso debe desarrollarse junto con ellos. Cuando encontramos un defecto en una herramienta compartida, tenemos que repararlo y revisar los resultados afectados. El próximo proyecto puede heredar una herramienta más sólida.

También hay un límite práctico para cualquier conversación. Terminará antes de que se termine una gran reconstrucción. El repositorio de código fuente tiene que hacer posible que continúe otra sesión sin perder el motivo de la última decisión.

El Fábrica de Reconstrucción de Touhou surgió de esa necesidad. Brinda a los proyectos una forma compartida de llevar adelante sus controles y lecciones. Trabajar en un juego puede mejorar las condiciones iniciales de otro.

Eso es lo que hace que la analogía industrial tenga sentido para mí. La experiencia comienza a formar parte de herramientas que otros pueden usar. Mejorar esas herramientas cambia cuánto puede hacer la próxima persona, o el próximo agente.

Los proyectos que ahora podemos considerar

El ritmo importa porque cambia la decisión de comenzar. Un juego podría ser fascinante para la ingeniería inversa y aún así exigir más de mi propia atención de la que podría prestarle de manera realista. Muchos proyectos se quedarían en ideas.

Ahora puedo ver una manera de mantener ese proyecto en marcha a través de repetidas investigaciones. Obtener una reconstrucción funcional hace que un puerto de software sea más práctico. Recuperar semántica legible hace que sea más fácil para otra persona explorar un mod. El esfuerzo realizado para comprender el juego puede seguir dando sus frutos después de que se ejecute la primera versión.

Ahora miro un programa desconocido y pregunto: ¿qué acceso, retroalimentación y conocimiento acumulado le permitirían a un agente trabajar en esto de manera confiable?

Esa pregunta me hace considerar proyectos que antes habría dejado solos. Cada uno puede mejorar la forma en que nos acercamos al siguiente. Quiero seguir explorando hasta dónde nos puede llevar eso.

Más artículos · Explore una investigación sobre TH04