Cómo leer esta referencia

De qué trata

Cuando un compilador traduce un programa a código máquina, destruye información. Los nombres de las variables desaparecen. Los tipos se disuelven en anchuras de registro. Las fronteras entre estructuras de datos se convierten en aritmética de punteros. Los bucles se desenrollan, las funciones se integran (inlining), las expresiones comunes se calculan una sola vez y se reutilizan, y las condiciones que el compilador supo demostrar siempre ciertas simplemente dejan de existir.

La ingeniería inversa es el intento de deshacer esa destrucción. Y no es un intento arbitrario: el que quiere recuperar la información perdida tiene que razonar sobre el mismo objeto —el comportamiento posible del programa— y con las mismas herramientas con las que el compilador razonó para destruirla. Un decompilador que reconstruye un for a partir de una maraña de saltos condicionales está aplicando análisis de dominadores. Uno que deduce que un registro contiene un puntero a una estructura de 24 bytes está haciendo análisis de tipos y de punteros. Uno que decide que tres instrucciones del binario son código muerto introducido por un ofuscador está haciendo dead code elimination sobre forma SSA.

Ésa es la tesis: el análisis estático de programas es la teoría de la ingeniería inversa, aunque casi nunca se presente así. La literatura de análisis estático habla de compiladores y de verificación; la de ingeniería inversa habla de formatos de fichero, desensambladores y trucos de anti-depuración. El puente entre ambos mundos se cruza a diario en la práctica —Ghidra, Hex-Rays, angr, BAP y Binary Ninja están construidos sobre esta teoría— pero rara vez se escribe. Aquí se escribe.

Qué no cubre

No es un manual de Ghidra ni de IDA. No enseña a leer ensamblador x86 ni ARM, ni a analizar formatos de fichero, ni a saltarse protecciones. Da por supuesto que el lector ya sabe leer un desensamblado y quiere entender qué hace la herramienta que se lo genera —y qué puede y qué no puede hacer.

Cómo está escrita

Está escrita por capas, para que sirva a dos lectores distintos sin obligar a ninguno a leer lo que no necesita.

• El cuerpo del texto va primero a la intuición: qué problema se resuelve, con qué idea, y por qué funciona. Se puede leer entero sin conocimientos previos de teoría de retículos ni de semántica formal.

• Los recuadros Formalización contienen las definiciones precisas, los teoremas y las demostraciones. Se pueden saltar en una primera lectura sin perder el hilo: nada del cuerpo depende de ellos. Vuelva a ellos cuando quiera implementar algo y necesite saber exactamente qué garantiza.

• Los recuadros En ingeniería inversa conectan lo anterior con lo que hacen las herramientas reales: qué representación usa cada decompilador, dónde falla y por qué.

Los itinerarios que tienen sentido:

• Si viene de la ingeniería inversa y quiere entender su decompilador: capítulos «1», «3», «4», «12», «13», «18», «19» y «24». Es el camino más corto de la motivación al pipeline completo.
• Si quiere implementar analizadores: capítulos «4» a «11» en orden, luego 15 y 7. Ahí está toda la maquinaria operativa.
• Si busca los fundamentos: capítulos «5», «21» y los apéndices «A» y «B», con los recuadros de formalización.
• Como referencia: cada capítulo es razonablemente autónomo y termina con una sección de lecturas que apunta a dónde seguir. El apéndice «E» reúne la bibliografía completa.

El nivel declarado en la cabecera de cada documento —Fundamentos, Operativo o Avanzado— corresponde a estos tres itinerarios.

Convenciones

Idioma. El cuerpo va en castellano. Los tecnicismos van en inglés, que es como el lector se los va a encontrar en la literatura, en los menús de las herramientas y en el código; la primera vez que aparece uno se escribe en cursiva con la traducción al lado, y a partir de ahí se usa el término inglés a secas. Todo el código, el pseudocódigo, los identificadores y los nombres de algoritmos están en inglés.

Diagramas. Los grafos de flujo de control, árboles de dominadores y diagramas de Hasse van en arte ASCII dentro de bloques monoespaciados. Es deliberado: se leen igual en pantalla, en papel y en cualquier fuente.

Notación matemática. Se usa notación de conjuntos y retículos estándar, una sola para todo el material. El apéndice «D» es un índice completo de símbolos. Los más frecuentes:

Pseudocódigo. Usa := para la asignación, for each x in X do, indentación por bloques, y no declara tipos salvo cuando importan.