Ingeniería inversa de MCU

Nota: todos los softwares están protegidos con contraseña; después de descargar el código, envíenos un correo electrónico y Mikatech le enviará la contraseña.

 

Un desensamblador es un programa informático que traduce lenguaje máquina a lenguaje ensamblador, la operación inversa a la de un ensamblador. Un desensamblador se diferencia de un decompilador, que apunta a un lenguaje de alto nivel en lugar de a un lenguaje ensamblador. El desensamblado, la salida de un desensamblador, a menudo se formatea para facilitar la lectura humana en lugar de ser adecuado para la entrada a un ensamblador, lo que lo convierte principalmente en una herramienta de ingeniería inversa.

El código fuente en lenguaje ensamblador generalmente permite el uso de constantes y comentarios del programador. Estos generalmente se eliminan del código máquina ensamblado por el ensamblador. Si es así, un desensamblador que opere sobre el código máquina produciría un desensamblado sin esas constantes y comentarios; la salida desensamblada se vuelve más difícil de interpretar para un humano que el código fuente anotado original. Algunos desensambladores hacen uso de la información de depuración simbólica presente en archivos objeto como ELF. El Desensamblador Interactivo permite al usuario humano crear símbolos mnemotécnicos para valores o regiones de código en una sesión interactiva: la perspicacia humana aplicada al proceso de desensamblado a menudo se asemeja a la creatividad humana en el proceso de escritura de código.

El desensamblado no es una ciencia exacta: en plataformas CISC con instrucciones de ancho variable, o en presencia de código automodificable, es posible que un solo programa tenga dos o más desensamblados razonables. Determinar qué instrucciones se encontrarían realmente durante la ejecución del programa se reduce al problema de la parada, que no tiene solución demostrada.

Escribir un desensamblador que produzca código que, al ser ensamblado, produzca exactamente el binario original es posible; sin embargo, a menudo hay diferencias. Esto plantea exigencias sobre la expresividad del ensamblador. Por ejemplo, un ensamblador x86 toma una elección arbitraria entre dos códigos binarios para algo tan simple como "MOV AX,BX". Si el código original usa la otra opción, el código original simplemente no puede ser reproducido en un punto dado. Sin embargo, incluso cuando se produce un desensamblado completamente correcto, persisten problemas si el programa requiere modificación. Por ejemplo, la misma instrucción de salto en lenguaje máquina puede ser generada por código ensamblador para saltar a una ubicación especificada (por ejemplo, para ejecutar código específico), o para saltar un número específico de bytes (por ejemplo, para saltar sobre una rama no deseada). Un desensamblador no puede saber lo que se pretende y puede usar cualquiera de las dos sintaxis, generando un desensamblado que reproduce el binario original [cita requerida]. Sin embargo, si un programador desea agregar instrucciones entre la instrucción de salto y su destino, es necesario comprender el funcionamiento del programa para determinar si el salto debe ser absoluto o relativo, es decir, si su destino debe permanecer en una ubicación fija o desplazarse para saltar tanto las instrucciones originales como las agregadas.

 

Ejemplos de desensambladores

Un desensamblador puede ser autónomo o interactivo. Un desensamblador autónomo, al ejecutarse, genera un archivo de lenguaje ensamblador que se puede examinar; uno interactivo muestra el efecto de cualquier cambio que el usuario realice de inmediato. Por ejemplo, es posible que el desensamblador inicialmente no sepa que una sección del programa es realmente código y la trate como datos; si el usuario especifica que es código, el código desensamblado resultante se muestra de inmediato, lo que permite al usuario examinarlo y tomar más acciones durante la misma ejecución.
Cualquier depurador interactivo incluirá alguna forma de ver el desensamblado del programa que se está depurando. A menudo, la misma herramienta de desensamblado se empaquetará como un desensamblador autónomo distribuido junto con el depurador. Por ejemplo, objdump, parte de GNU Binutils, está relacionado con el depurador interactivo gdb.

IDA
OllyDbg es un depurador de análisis a nivel de ensamblador de 32 bits
OLIVER y SIMON incluyen desensambladores para Ensamblador, COBOL y PL/1

 

 

Decompilador

Un decompilador es un programa informático que realiza la operación inversa a la de un compilador. Es decir, traduce el código de programa en un nivel de abstracción relativamente bajo (generalmente diseñado para ser legible por computadora en lugar de por humanos) a una forma con un nivel de abstracción más alto (generalmente diseñado para ser legible por humanos). Los decompiladores generalmente no reconstruyen perfectamente el código fuente original y pueden variar ampliamente en la inteligibilidad de sus salidas. No obstante, los decompiladores siguen siendo una herramienta importante en la ingeniería inversa de software.

El término decompilador se aplica más comúnmente a un programa que traduce programas ejecutables (la salida de un compilador) a código fuente en un lenguaje de alto nivel (relativamente) que, cuando se compila, producirá un ejecutable cuyo comportamiento es el mismo que el programa ejecutable original. En comparación, un desensamblador traduce un programa ejecutable a lenguaje ensamblador (y un ensamblador podría usarse para ensamblarlo de nuevo a un programa ejecutable).
La descompilación es el acto de usar un decompilador, aunque el término también puede referirse a la salida de un decompilador. Se puede usar para la recuperación de código fuente perdido, y también es útil en algunos casos para la seguridad informática, la interoperabilidad y la corrección de errores.[1][fuente no fiable] El éxito de la descompilación depende de la cantidad de información presente en el código que se descompila y la sofisticación del análisis realizado sobre él. Los formatos de bytecode utilizados por muchas máquinas virtuales (como la Máquina Virtual Java o el Common Language Runtime de .NET Framework) a menudo incluyen metadatos extensos y características de alto nivel que hacen que la descompilación sea bastante factible. La presencia de datos de depuración puede hacer posible reproducir los nombres originales de variables y estructuras e incluso los números de línea. El lenguaje máquina sin dichos metadatos o datos de depuración es mucho más difícil de descompilar.[2]
Algunos compiladores y herramientas posteriores a la compilación producen código ofuscado (es decir, intentan producir una salida que sea muy difícil de descompilar). Esto se hace para dificultar la ingeniería inversa del ejecutable.

 

Diseño

Los decompiladores se pueden considerar compuestos por una serie de fases, cada una de las cuales contribuye con aspectos específicos del proceso general de descompilación.

 

Cargador

La primera fase de descompilación carga y analiza el formato de archivo binario del programa de entrada en código máquina o lenguaje intermedio. Debe ser capaz de descubrir datos básicos sobre el programa de entrada, como la arquitectura (Pentium, PowerPC, etc.) y el punto de entrada. En muchos casos, debería poder encontrar el equivalente de la función main 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 los compiladores utilizados, puede proporcionar información útil para identificar modismos de código.

 

Desensamblado

La siguiente fase lógica es el desensamblado de las instrucciones de código máquina en una representación intermedia (IR) independiente de la máquina. Por ejemplo, la instrucción Pentium
mov eax, [ebx+0x04]
podría traducirse a la IR
eax := m[ebx+4];

 

Modismos

Las secuencias de código máquina idiomáticas son secuencias de código cuya semántica combinada no es inmediatamente evidente a partir de la semántica individual de las instrucciones. Ya sea como parte de la fase de desensamblado o como parte de análisis posteriores, estas secuencias idiomáticas deben traducirse a una IR equivalente conocida. Por ejemplo, el código ensamblador x86:
cdq eax ; edx se establece con la extensión de signo de eax
xor eax, edx
sub eax, edx
podría traducirse a
eax := abs(eax);
Algunas secuencias idiomáticas son independientes de la máquina; algunas involucran solo una instrucción. Por ejemplo, xor eax, eax limpia el registro eax (lo establece a cero). Esto se puede implementar con una regla de simplificación independiente de la máquina, como a xor a = 0.
En general, es mejor retrasar la detección de secuencias idiomáticas si es posible, para etapas posteriores que se vean menos afectadas por el orden de las instrucciones. Por ejemplo, la fase de programación de instrucciones de un compilador puede insertar otras instrucciones en una secuencia idiomática, o cambiar el orden de las instrucciones en la secuencia. Un proceso de coincidencia de patrones en la fase de desensamblado probablemente no reconocería el patrón alterado. Las fases posteriores agrupan expresiones de instrucciones en expresiones más complejas y las modifican a una forma canónica (estandarizada), lo que hace más probable que incluso el modismo alterado coincida con un patrón de nivel superior más adelante en la descompilación.
Es particularmente importante reconocer los modismos del compilador para llamadas a subrutinas, manejo de excepciones y sentencias switch. Algunos lenguajes también tienen un amplio soporte para cadenas o enteros largos.

 

Análisis de programa

Se pueden aplicar varios análisis de programa a la 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 expresiones:
m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);

La expresión resultante se parece más a un lenguaje de alto nivel y también ha eliminado el uso del registro de máquina eax. Los análisis posteriores pueden eliminar el registro ebx.

 

Análisis de flujo de datos

Los lugares donde se definen y utilizan los contenidos de los registros deben rastrearse mediante el análisis de flujo de datos. El mismo análisis se puede aplicar a ubicaciones que se utilizan para temporales y datos locales. Luego se puede formar 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, es posible que el análisis de flujo de datos identifique una ruta por la cual un valor pueda fluir entre dos usos, aunque en realidad nunca sucedería o importaría. Esto puede llevar, en malos casos, a la necesidad de definir una ubicación como una unión de tipos. El decompilador puede permitir al usuario romper explícitamente tales dependencias no naturales, lo que llevará a un código más claro. Esto, por supuesto, significa que se usa una variable potencialmente sin inicializar, lo que indica un problema en el programa original.

 

Análisis de tipos

Un buen decompilador de código máquina realizará un análisis de tipos. Aquí, la forma en que se utilizan los registros o las ubicaciones de memoria da lugar a restricciones sobre el tipo posible de la ubicación. Por ejemplo, una instrucción and implica que el operando es un entero; los programas no utilizan tal operación en valores de punto flotante (excepto en código de biblioteca especial) ni en punteros. Una instrucción add da lugar a tres restricciones, ya que los operandos pueden ser ambos enteros, o un entero y un puntero (con resultados enteros y de puntero respectivamente; la tercera restricción proviene del orden de los dos operandos cuando los tipos son diferentes).

Se pueden reconocer varias expresiones de alto nivel que desencadenan el reconocimiento de estructuras o arreglos. Sin embargo, es difícil distinguir muchas de las posibilidades, debido a la libertad que permiten el código máquina o incluso algunos lenguajes de alto nivel como C con conversiones y aritmética de punteros.

El ejemplo de la sección anterior podría resultar en el siguiente código de alto nivel:
struct T1 *ebx;
struct T1 {
int v0004;
int v0008;
int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;

 

Estructuración

La penúltima fase de descompilación implica la estructuración de la IR en construcciones de nivel superior, como bucles while y sentencias condicionales if/then/else. Por ejemplo, el código máquina
xor eax, eax
l0002:
or ebx, ebx
jge l0003
add eax,[ebx]
mov ebx,[ebx+0x4]
jmp l0002
l0003:
mov [0x10040000],eax
podría traducirse a:
eax = 0;
while (ebx < 0) {
eax += ebx->v0000;
ebx = ebx->v0004;
}
v10040000 = eax;

El código no estructurado es más difícil de traducir a código estructurado que el código ya estructurado. Las soluciones incluyen replicar algo de código o agregar variables booleanas.

 

Generación de código

La fase final es la generación del código de alto nivel en el back-end del decompilador. Así como un compilador puede tener varios back-ends para generar código máquina para diferentes arquitecturas, un decompilador puede tener varios back-ends para generar código de alto nivel en diferentes lenguajes de alto nivel.

Justo antes de la generación de código, puede ser deseable permitir una edición interactiva de la IR, quizás usando alguna forma de interfaz gráfica de usuario. Esto permitiría al usuario ingresar comentarios y nombres de variables y funciones no genéricos. Sin embargo, estos se ingresan casi con la misma facilidad en una edición posterior a la descompilación. El usuario puede querer cambiar aspectos estructurales, como convertir un bucle while en un bucle for. Estos son menos fáciles de modificar con un editor de texto simple, aunque las herramientas de refactorización de código fuente pueden ayudar con este proceso. El usuario puede necesitar ingresar información que no se pudo identificar durante la fase de análisis de tipos, por ejemplo, modificar una expresión de memoria a una expresión de arreglo o estructura. Finalmente, es posible que sea necesario corregir la IR incorrecta o realizar cambios para que el código de salida sea más legible.