¿La ingeniería inversa necesita un modelo más grande?

Qué cambiaron los modelos más capaces

Desde agosto de 2026, he estado explorando cuánta ingeniería inversa puede realizar un agente con acceso a un programa y una forma de comprobar su funcionamiento. La mayor parte de mi experiencia proviene de la reconstrucción de juegos, especialmente Touhou. A medida que he ido cambiando de modelo, los repositorios han ido manteniendo un registro de lo que cada sesión logró recuperar.

Gran parte de ese trabajo apunta a una reconstrucción exacta: compilamos la fuente mantenida bajo una cadena de herramientas histórica con versiones fijas y comprobamos si reproduce la función de destino. Cuando un modelo posterior tiene éxito donde el trabajo anterior se estancó, los cambios en las fuentes muestran qué hizo posible ese progreso.

Los valores temporales debían seguir siendo válidos al mismo tiempo

Gran parte de la lógica de la función de ataque TH09 ya había sido reconstruida, pero el compilador aún almacenaba resultados temporales de manera diferente al original. El problema restante era cuánto tiempo necesitaban esos resultados para permanecer vivos y cuándo se podía reutilizar su almacenamiento.

Un registro de sesión GPT-6-Sol informó esta discrepancia después de probar varias disposiciones de código fuente ordinarias. Cuando GPT-6.1-Sol examinó el problema nuevamente, propuso una hipótesis útil sobre la vida útil de estas variables temporales.

La función produjo resultados temporales y los copió en posiciones de animación. En C++, un resultado temporal permanece vivo hasta que finaliza la expresión que lo utiliza. Agrupar las operaciones reales en una expresión mantuvo esos resultados vivos juntos, por lo que el compilador ya no pudo reutilizar el mismo almacenamiento para todos ellos.

Un resultado aún compartía almacenamiento con un valor utilizado más adelante para comprobaciones de colisiones. Darle a ese valor su propia vida útil resolvió la superposición restante. Después de varios experimentos específicos, una recompilación limpia del código fuente confirmó que la función completa coincidía.

Me interesa saber cómo el descubrimiento y las pruebas se apoyaron mutuamente. La hipótesis sobre la vida temporal de los objetos dio al agente de IA una nueva dirección. Los comentarios del compilador le ayudaron a refinar esa hipótesis hasta convertirla en una disposición de código fuente que coincidiera.

Un gráfico de flujo de control diferente

Una segunda función TH09 muestra por qué esa nueva dirección puede ser importante. Aquí el obstáculo fue cómo varias ramas compartieron su trabajo final. El trabajo anterior de GPT-6.1-Sol consiguió que partes de la función coincidieran, pero las ramas aún se unían de manera diferente al original.

GPT-6-Astra cambió el gráfico de flujo de control circundante. Los caminos principales conducían ahora a una actualización final compartida y al regreso. En esa estructura fuente, el compilador combinó las ramas de la misma manera que el original. La función completa coincidió y una verificación de reconstrucción separada lo confirmó.

Cambiar la representación abrió un espacio de búsqueda más productivo. Ambos casos me dan una razón para tomar en serio la capacidad del modelo general: un agente puede seguir probando variaciones locales durante mucho tiempo antes de encontrar una mejor manera de expresar el trabajo circundante.

Las sesiones posteriores también heredaron el código anterior y los intentos fallidos documentados. Esa experiencia acumulada formaba parte de su ventaja. El historial permite examinar los hallazgos y sus comprobaciones; una comparación controlada ayudaría a separar el efecto del modelo del de la experiencia que recibió.

Esto es lo que hace que la pregunta me resulte interesante. Algunos avances se produjeron al encontrar una nueva representación. Gran parte del trabajo restante implicó probar diferentes disposiciones de código fuente con un compilador familiar. ¿Cuánto de esto requiere una amplia capacidad de razonamiento? ¿Cuánto podría aprender un modelo trabajando repetidamente con ese compilador y código?

¿Por qué podría funcionar bien un modelo de IA especializado?

Touhou nos da una razón concreta para esperar que esa experiencia ayude. Gran parte del código del juego proviene del mismo autor, ZUN, por lo que los hábitos recurrentes son una suposición inicial razonable. Los repositorios respaldan esto con ejemplos útiles: bucles relacionados y arreglos de ayuda han proporcionado hipótesis en todos los juegos.

Esos patrones fuente se vuelven más específicos cuando incluimos el compilador. Bajo una versión particular y un conjunto de opciones, pequeños cambios en la fuente pueden producir diferencias repetibles en el código de máquina. Algunas de esas diferencias son sorprendentemente oscuras.

En TH095, por ejemplo, incluso el nombre de una variable local podría afectar dónde la almacenó VC7.1. Mover su declaración no resolvió el diseño del almacenamiento. Sin embargo, una función en segundo plano anterior había revelado un patrón de nombres que afectaba la elección del compilador. Eso sugirió una hipótesis más prometedora para reconstruir Supervisor::LoadDat.

La reutilización de ese patrón para la variable de tamaño de archivo produjo el diseño requerido sin agregar almacenamiento. Entonces coincidió la función completa.

Este es un detalle muy específico que un modelo de IA de propósito general puede no conocer cuando encuentra el problema por primera vez. Un modelo especializado para este compilador podría ver muchos de estos casos y aprender qué variaciones del código fuente vale la pena probar primero.

La oportunidad es especialmente clara en los problemas finales de emparejamiento en los que ya entendemos el comportamiento. Entonces nos preguntamos qué disposición ordinaria del código fuente convierte este compilador en las instrucciones observadas. La especialización podría ayudar al modelo a proponer esas formas de manera más eficiente, mientras que el objetivo aún determina qué hipótesis sobreviven.

Los patrones útiles deben conservar su contexto. TH08 utiliza una versión Visual C++ anterior a TH095 y TH09. TH04 utiliza un compilador diferente de la era DOS. Su reconstrucción del código del jugador necesitaba diferentes hipótesis sobre los patrones del código fuente y cómo el código compilado se vinculaba a un ejecutable. Tener el mismo autor nos da una expectativa inicial, pero cada objetivo nos dice si aplica. Un modelo especializado necesitaría distinguir estos contextos.

¿Dónde debería almacenarse esta experiencia?

Antes de decidir enseñar esos patrones mediante el entrenamiento de modelos, miraría el conocimiento que ya guardamos en el repositorio. En el ensayo anterior, escribí sobre cómo se convertiría en la memoria de trabajo del proyecto. Esa memoria incluye lecciones del compilador, junto con la fuente y los experimentos fallidos que los hicieron útiles.

Al recuperar ese registro, un agente puede comenzar con un resultado conocido e inspeccionar cómo llegamos a él. También puede evitar alternativas que ya han fracasado en el mismo contexto. El punto de partida mejora sin cambiar los parámetros entrenados del modelo.

Mientras reconstruía la función de TH09 para crear enemigos, una sesión GPT-6-Luna-max tomó una hipótesis del código fuente relacionado de TH08. Ese código anterior sugirió cómo organizar el bucle y manejar las fallas dentro de él. La propia evidencia de TH09 proporcionó los detalles específicos del juego. Las reconstrucciones de la fuente confirmaron que la función completa coincidía.

"El modelo no sabía esa peculiaridad del compilador" y "el modelo no podía usarlo" son problemas diferentes. La recuperación puede resolver el primero, pero convertir ese hecho en un candidato útil aún requiere trabajo. Y si el código fuente candidato falla, el modelo debe decidir qué significa el resultado para su próximo intento. Conocer el patrón relevante es sólo el comienzo de ese proceso.

Por esa razón, incluiría en cualquier comparación un modelo de IA de propósito general más pequeño con buena recuperación. Darle la misma biblioteca de experiencia nos ayudaría a identificar qué aporta la capacitación: mejor generación de candidatos, mejores decisiones después de la retroalimentación, o ambas.

Aprendiendo el próximo experimento útil

Esas decisiones después del feedback son las que más me gustaría estudiar. En la reconstrucción agente, el modelo propone una explicación y la compara con el programa. Incluso cuando el código fuente candidato falla, el resultado puede reducir las posibilidades restantes y sugerir un próximo experimento más útil.

Considere nuevamente el ejemplo de los resultados temporales. Su fuente final muestra el arreglo que funcionó, pero la ruta a esa fuente contiene más información. Cada uno de los siguientes experimentos ayudó a identificar lo que aún era necesario cambiar.

Experimentos seleccionados de la reconstrucción de la función de ataque anterior, agrupados según lo que nos enseñaron.

Un registro de capacitación que mantenga esta secuencia puede enseñar más que la fuente final por sí sola. Conecta cada cambio propuesto con un resultado observado y la siguiente decisión. Mantener variaciones ineficaces también es importante: le dicen a un agente posterior qué hipótesis ya han sido probadas en ese contexto.

Me gustaría que el modelo aprendiera a utilizar la retroalimentación. Un resultado neutral es una razón para reconsiderar la variación; una discrepancia modificada puede indicar otra causa. Cuando las ediciones locales dejan de ser informativas, el agente debería poder revisar la representación de la fuente o inspeccionar la evidencia nuevamente.

Aprender a tomar esas decisiones requiere autonomía. A veces, el siguiente paso útil es inspeccionar a otra persona que llama en lugar de compilar otra edición. Una secuencia rígida de reescrituras requeridas eliminaría esa elección, junto con parte del comportamiento que queremos que aprenda el modelo.

Por qué la ingeniería inversa es interesante para el aprendizaje por refuerzo

La reconstrucción acotada nos brinda un entorno práctico para estudiar estas opciones. Una vez que se corrigen las versiones de destino y del compilador, muchos experimentos de origen producen comentarios rápidos y repetibles. El agente puede compilar un candidato, inspeccionar la discrepancia y utilizar esa observación para elegir el siguiente paso.

El aprendizaje por refuerzo podría entrenar ese proceso de toma de decisiones a través de la retroalimentación que recibe. Un candidato aceptado mediante un control definido nos da un resultado concreto, mientras que la secuencia de intentos nos permite observar cuánto trabajo ha sido necesario para alcanzarlo.

Ya existen investigaciones que respaldan esta dirección. LLM4Decompile estudia modelos especializados para la descompilación. AutoDecompiler entrena el refinamiento de varios turnos utilizando el compilador y los comentarios de ejecución. Sus estudios se centran en la recuperación funcional. Para este trabajo, los usaría como punto de partida para la tarea relacionada de encontrar una fuente que coincida con la salida de un compilador histórico.

Sin embargo, para alcanzar una tarea tan bien definida, es posible que primero necesitemos establecer qué recursos posee una función o diseñar una nueva forma de observar el comportamiento del programa durante su ejecución. En TH08, por ejemplo, una diferencia de colisión llevó a cómo el programa original manejaba los cálculos de punto flotante. Antes de que el agente pudiera probar una corrección útil, tenía que decidir qué medir.

Esto sugiere otra función para un modelo con amplias capacidades: ayudar a que el problema sea verificable en primer lugar. Una vez que exista esa verificación, podemos investigar hasta dónde puede llegar una política de búsqueda aprendida.

Cuando el verificador está equivocado

Al entrenar con una comprobación, su cobertura pasa a formar parte del entorno de aprendizaje. Llamo oracle a esa referencia o verificador. Aunque la respuesta sea repetible, debemos entender qué verifica realmente.

TH08 mostró cuánto se puede ocultar fuera de esa cobertura. Algunas funciones reconstruidas pasaron sus comparaciones exactas con constantes flotantes incorrectas. El comparador ajustó las direcciones reubicadas antes de verificar las instrucciones, pero verificó los valores detrás de esas direcciones solo cuando se habían registrado explícitamente para su verificación. Otras referencias literales podrían pasar sin que se examinen sus valores.

Para abordar esta brecha, una auditoría más amplia encontró constantes incorrectas en funciones que ya habían pasado la verificación. En un cálculo, el código fuente reconstruido agregó 1.0f, mientras que el original agregó 32.0f.

Un modelo recompensado por la comprobación anterior podría aprender a producir una reconstrucción incorrecta. No entrenamos un modelo RL usando ese verificador. El fallo que observamos estaba en la propia comprobación. Pero si lo usáramos como recompensa, el mismo punto ciego pasaría a formar parte del entorno de aprendizaje.

Una prueba funcional puede tener un punto ciego similar. La investigación que utilizó fuzzing diferencial en descompiladores LLM encontró diferencias de comportamiento fuera de las pruebas proporcionadas. Por lo tanto, debemos entender una prueba aprobatoria en términos de los casos en los que se aplica. De manera similar, una coincidencia de instrucciones debe entenderse en términos de los bytes y datos que verifica.

Antes de utilizar cualquier tipo de control de verificación como recompensa, lo probaría con resultados deliberadamente incorrectos. También mantendría la aceptación final separada del código fuente que el agente de IA puede editar. El modelo debe pasar la verificación reconstruyendo el programa correctamente. De lo contrario, simplemente copiar una matriz de bytes del destino podría engañar a un sistema de puntuación ingenuo sin recuperar el código fuente útil.

Mejorar al alumno y mejorar su verificador pertenecen al mismo problema de investigación. A medida que el alumno mejora en la optimización de los comentarios que le damos, comprender esos comentarios también se vuelve más importante.

Una comparación que vale la pena realizar

Con esas comprobaciones implementadas, comenzaría la comparación en una familia de tareas fija VC7.1. Primero, establecería líneas de base para un modelo de IA de propósito general sólido y uno más pequeño. Agregar conocimiento del repositorio al modelo más pequeño mostraría qué cambios en la recuperación. A partir de ahí, la especialización supervisada y una versión capacitada con RL nos permitirían examinar qué agrega la capacitación.

Para que esas comparaciones sean informativas, cada modelo recibiría la misma evidencia y herramientas objetivo. Para las comparaciones específicas de la capacitación, también mantendría fijo el modelo base y el conocimiento disponible. Las pruebas repetidas ayudarían a distinguir una estrategia de búsqueda confiable de una solución candidata que tiene éxito por casualidad.

Luego separaría dos condiciones iniciales: reconstruir una función a partir de sus instrucciones y cerrar las últimas diferencias en la fuente mantenida. Un modelo de IA especializado podría ser excelente en la segunda tarea, mientras que un modelo de IA de propósito general hace gran parte del trabajo necesario para alcanzarla. Medirlos por separado revelaría esa división del trabajo.

Ambas tareas necesitan ejemplos de prueba excluidos del entrenamiento y la recuperación. Los juegos Touhou relacionados comparten el código del motor. Excluir un juego del entrenamiento aún podría dejar funciones casi idénticas en el conjunto de entrenamiento. En cambio, excluiría grupos enteros de código fuente relacionado y mantendría sus respuestas verificadas fuera de los datos de entrenamiento y de la biblioteca de recuperación.

Para estos ejemplos, el resultado serían coincidencias completas y verificadas de forma independiente. La igualdad de presupuestos para las propuestas de los candidatos o los intentos de compilación ayudaría a comparar la calidad de la búsqueda. Medir el tiempo y el costo total, incluida la compilación, mostraría si esa calidad produce un flujo de trabajo eficiente. Los costos de capacitación deben medirse por separado.

Ambas medidas importan. Una propuesta barata puede generar un flujo de trabajo costoso si genera más compilaciones que no proporcionan información útil. Por el contrario, un modelo más lento puede resultar más económico si encuentra antes un experimento útil. La comparación debe incluir estos costos.

Contar los resultados aceptados también ayuda a interpretar los avances intermedios. Un candidato para guardar repeticiones de TH09 parecía prometedor porque la función compilada tenía el tamaño esperado, pero la comparación completa aún encontró diferencias importantes. La forma en que el compilador ordena las instrucciones puede hacer que un candidato parezca más cercano sin resolver el problema de fondo. Estos diagnósticos orientan el siguiente experimento; antes de premiar una mayor cercanía, la contrastaría con la comprobación completa de aceptación.

Me interesaría conocer el patrón de estos resultados. Si un modelo de IA especializado funciona bien dentro de una familia de compiladores familiar, ¿esa ventaja sobrevive a un cambio en la cadena de herramientas? Y una vez que ambos modelos de IA tengan una buena recuperación, ¿cuánto aporta aún el entrenamiento? Las respuestas nos ayudarían a decidir dónde es más útil cada tipo de modelo.

¿Qué tipo de agente de IA sugiere esto?

Si los modelos resultan útiles en diferentes etapas, un acuerdo útil podría ser un agente amplio con acceso a un modelo de IA especializado. Una vez que una tarea se convierte en una búsqueda familiar del compilador, podría solicitar candidatos al modelo de IA especializado. Si los resultados dejan de tener sentido, el agente más amplio podría volver a la evidencia objetivo o investigar la medición en sí.

En ese arreglo, la especialización se convierte en una herramienta que el agente puede elegir a medida que se desarrolla la investigación. El agente conserva la libertad de cambiar la dirección que hizo posibles los avances anteriores.

Esto se deriva naturalmente del cambio industrial que describí en el ensayo anterior. Poder realizar muchos más experimentos cambia la forma en que organizamos el trabajo. También nos da una razón para preguntar qué decisiones requieren un juicio amplio y cuáles mejoran a través de experiencias repetidas con un oficio en particular.

Por ahora, el modelo general más potente se ha ganado su lugar en mi flujo de trabajo al resolver problemas que había dejado pendientes. Esos éxitos me llevan a examinar el proceso: ¿cuánto dependía de la amplitud del modelo y cuánto podría asumir uno entrenado específicamente para esta clase de reconstrucción?

Los repositorios nos brindan una forma de probar la pregunta. Me gustaría usar ese registro para realizar la comparación y ver qué aprendemos.