Descompilador

La primera fase de descompilación carga y analiza el código máquina de entrada o el formato de archivo binario del programa en lenguaje intermedio . Debe ser capaz de descubrir información básica sobre el programa de entrada, como la arquitectura (Pentium, PowerPC, etc.) y el punto de entrada. En muchos casos, debe ser capaz de encontrar el equivalente de la función de un programa en C , que es el inicio del código escrito por el usuario . Esto excluye el código de inicialización en tiempo de ejecución , que no debe descompilarse si es posible. Si están disponibles, también se cargan las tablas de símbolos y los datos de depuración. El front-end puede identificar las bibliotecas utilizadas, incluso si están enlazadas con el código, lo que proporcionará interfaces de biblioteca. Si puede determinar el compilador o compiladores utilizados, puede proporcionar información útil para identificar patrones de código. ^{[ 1 ]}main

La siguiente fase lógica es el desensamblaje de las instrucciones del código máquina en una representación intermedia independiente de la máquina (IR). Por ejemplo, la instrucción de la máquina Pentium.

mov eax , [ ebx + 0x04 ]

podría traducirse al IR

eax : = m [ ebx + 4 ] ;

Las secuencias de código máquina idiomáticas son secuencias de código cuya semántica combinada no resulta inmediatamente evidente a partir de la semántica individual de las instrucciones. Ya sea como parte de la fase de desensamblaje o como parte de análisis posteriores, estas secuencias idiomáticas deben traducirse a una representación intermedia (IR) equivalente conocida. Por ejemplo, el código ensamblador x86 :

cdq eax ; edx se establece en la extensión de signo≠edi,edi +(tex)push xor eax , edx sub eax , edx

podría traducirse a

eax := abs(eax);

Algunas secuencias idiomáticas son independientes de la máquina; otras implican solo una instrucción. Por ejemplo, borra el registro (lo pone a cero). Esto se puede implementar con una regla de simplificación independiente de la máquina, como .xoreax,eaxeaxa = 0

En general, conviene retrasar la detección de secuencias idiomáticas, si es posible, a etapas posteriores menos afectadas por el orden de las instrucciones. Por ejemplo, la fase de planificación de instrucciones de un compilador puede insertar otras instrucciones en una secuencia idiomática o modificar el orden de las instrucciones dentro de la secuencia. Un proceso de comparación de patrones en la fase de desensamblaje probablemente no reconocería el patrón modificado. Las fases posteriores agrupan las expresiones de instrucciones en expresiones más complejas y las modifican a una forma canónica (estandarizada), lo que aumenta la probabilidad de que incluso la secuencia idiomática modificada coincida con un patrón de nivel superior más adelante en la descompilación.

Es particularmente importante reconocer las convenciones del compilador para llamadas a subrutinas , manejo de excepciones y sentencias switch . Algunos lenguajes también ofrecen un amplio soporte para cadenas o números enteros largos .

Se pueden aplicar varios análisis de programas al IR. En particular, la propagación de expresiones combina la semántica de varias instrucciones en expresiones más complejas. Por ejemplo,

mov eax ,[ ebx + 0x04 ] add eax ,[ ebx + 0x08 ] sub [ ebx + 0x0C ], eax

podría resultar en la siguiente IR después de la propagación de la expresión:

m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);

La expresión resultante se asemeja más a un lenguaje de alto nivel y, además, ha eliminado el uso del registro de máquina eax. Análisis posteriores podrían eliminar dicho ebxregistro.

Los lugares donde se definen y utilizan los contenidos de los registros deben rastrearse mediante análisis de flujo de datos . El mismo análisis puede aplicarse a las ubicaciones utilizadas para variables temporales y datos locales. A continuación, se puede generar un nombre diferente para cada conjunto conectado de definiciones y usos de valores. Es posible que la misma ubicación de variable local se haya utilizado para más de una variable en diferentes partes del programa original. Peor aún, el análisis de flujo de datos puede identificar una ruta por la cual un valor puede fluir entre dos usos de este tipo, aunque esto nunca ocurra ni tenga relevancia en la realidad. En casos extremos, esto puede llevar a la necesidad de definir una ubicación como una unión de tipos. El descompilador puede permitir al usuario romper explícitamente estas dependencias no naturales, lo que dará como resultado un código más claro. Esto, por supuesto, significa que una variable se utiliza potencialmente sin estar inicializada, lo que indica un problema en el programa original.

Un buen descompilador de código máquina realizará un análisis de tipos. En este análisis, la forma en que se utilizan los registros o las ubicaciones de memoria impone restricciones sobre el tipo posible de la ubicación. Por ejemplo, una andinstrucción implica que el operando es un entero; los programas no utilizan dicha operación con valores de punto flotante (excepto en código de biblioteca especial) ni con punteros . Una addinstrucción da como resultado tres restricciones, ya que los operandos pueden ser enteros, o uno entero y un puntero (con resultados enteros y punteros respectivamente; la tercera restricción proviene del orden de los dos operandos cuando los tipos son diferentes). ^{[ 2 ]}

Se pueden reconocer diversas expresiones de alto nivel que activan el reconocimiento de estructuras o matrices. Sin embargo, resulta difícil distinguir muchas de las posibilidades debido a la libertad que ofrece el código máquina, e incluso algunos lenguajes de alto nivel como C, con las conversiones de tipo y la aritmética de punteros.

El ejemplo de la sección anterior podría dar como resultado el siguiente código de alto nivel:

struct T1 { int v0004 ; int v0008 ; int v000C ; }; struct T1 * ebx ; ebx -> v000C -= ebx -> v0004 + ebx -> v0008 ;

La penúltima fase de descompilación implica la estructuración del IR en construcciones de nivel superior, como whilebucles y if/then/elsesentencias condicionales. Por ejemplo, el código máquina.

xor eax , eax l0002: o ebx , ebx jge l0003 add eax , [ ebx ] mov ebx , [ ebx + 0x4 ] jmp l0002 l0003: mov [ 0x10040000 ], eax

podría traducirse como:

eax = 0 ; mientras ( ebx < 0 ) { eax += ebx- > v0000 ; ebx = ebx- > v0004 ; } v10040000 = eax ;

El código no estructurado es más difícil de convertir en código estructurado que el código ya estructurado. Las soluciones incluyen replicar parte del código o agregar variables booleanas. ^{[ 3 ]}

La fase final consiste en la generación del código de alto nivel en la parte posterior del descompilador. Del mismo modo que un compilador puede tener varias partes posteriores para generar código máquina para diferentes arquitecturas, un descompilador puede tener varias partes posteriores para generar código de alto nivel en diferentes lenguajes de alto nivel.

Justo antes de la generación del código, puede ser conveniente permitir la edición interactiva del IR, quizás mediante una interfaz gráfica de usuario . Esto permitiría al usuario introducir comentarios y nombres de variables y funciones no genéricos. Sin embargo, estos se pueden introducir casi con la misma facilidad en una edición posterior a la descompilación. El usuario podría querer modificar aspectos estructurales, como convertir un whilebucle en forotro. Estos cambios son más difíciles de realizar con un editor de texto simple, aunque las herramientas de refactorización de código fuente pueden facilitar este proceso. El usuario podría necesitar introducir información que no se identificó durante la fase de análisis de tipos, por ejemplo, modificar una expresión de memoria a una expresión de matriz o estructura. Finalmente, podría ser necesario corregir un IR incorrecto o realizar cambios para que el código de salida sea más legible.

Se han desarrollado descompiladores que utilizan redes neuronales . Dicho descompilador puede entrenarse mediante aprendizaje automático para mejorar su precisión con el tiempo. ^{[ 4 ]}

• Descompilador de Mocha
• Descompilador JD
• Descompilador JAD

• Reflector .NET
• dotPeek
• Descompilador JEB (Android Dalvik, Intel x86, ARM, MIPS, WebAssembly, Ethereum)
• Ghidra
• IDA Pro , que incluye un descompilador como función de pago opcional.
• Ninja binario
• uncompyle6 (código de bytes de Python de la versión 1.0 a la 3.8)