Descompilador

The first decompilation phase loads and parses the input machine code or intermediate language program's binary file format. It should be able to discover basic facts about the input program, such as the architecture (Pentium, PowerPC, etc.) and the entry point. In many cases, it should be able to find the equivalent of the main function of a C program, which is the start of the user written code. This excludes the runtime initialization code, which should not be decompiled if possible. If available the symbol tables and debug data are also loaded. The front end may be able to identify the libraries used even if they are linked with the code, this will provide library interfaces. If it can determine the compiler or compilers used it may provide useful information in identifying code idioms.^[1]

The next logical phase is the disassembly of machine code instructions into a machine independent intermediate representation (IR). For example, the Pentium machine instruction

moveax,[ebx+0x04]

might be translated to the IR

eax:=m[ebx+4];

Idiomatic machine code sequences are sequences of code whose combined semantics are not immediately apparent from the instructions' individual semantics. Either as part of the disassembly phase, or as part of later analyses, these idiomatic sequences need to be translated into known equivalent IR. For example, the x86 assembly code:

cdqeax; edx is set to the sign-extension≠edi,edi +(tex)pushxoreax,edxsubeax,edx

could be translated to

eax := abs(eax);

Some idiomatic sequences are machine independent; some involve only one instruction. For example, xoreax,eax clears the eax register (sets it to zero). This can be implemented with a machine independent simplification rule, such as a = 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)