Agradecemos a Ezequiel Salinas Bydlowski que comparte su experiencia y conocimientos a través de este post.
Ezequiel es especialista en ciberseguridad ofensiva, pentesting y Red Team, está enfocado en detección de vulnerabilidades y fortalecimiento defensivo.

Introducción

Este posteo habla sobre los tipos de binarios que existen dentro de los distintos SO (Sistemas Operativos), la intención es explicar cómo se conforman estos a bajo nivel, lo cual es un punto de partida para entender cómo se analiza malware. Mismo en este posteo veremos algunas de las herramientas para análisis estático de binarios. Se deja para una futura publicación lo que sería análisis de APK e IPSW.

Formatos

Los formatos de los distintos binarios se dividen según el sistema en que están preparados para ser ejecutados, los binarios PE están preparados para Windows, los ELF están preparados para Linux y Mach-O formato preparado para MacOS. Cada uno de estos tres tienen diferencias entre sí, como la arquitectura que soportan, la forma de identificar sus formatos, como deben organizarse las cabeceras, pero, tienen en común algo que es el tipo de archivo, esto quiere decir que los tres funcionan como un contenedor con instrucciones y herramientas para que el sistema a través de lenguaje ASM comprenda las acciones que debe realizar.

Analizando Binarios

Lo mejor para poder entender cómo se componen los binarios es analizarlos de manera estática, para poder ver cada header y entender para que sirve, con esto podemos ver que nos encontraremos dentro de cualquier binario a la hora de analizar.

Windows: Portable Executable (PE)

Es un estándar de binarios para Windows de 32 y 64 bits, se enfoca en ejecutables (.exe), archivos de tipo .dll y controladores (.sys).

Las cabeceras diferenciales de este tipo de archivo son:

• DOS Header: Cualquier binario .exe que abras en un hex editor va a tener los siguientes dos bytes al principio 4D 5A → en ASCII significa MZ que son las iniciales de Mark Zbikowski uno de los ingenieros de Microsoft que diseño el sistema DOS (Disk Operating System) en los años 80s.

La mayoría de las DOS Headers son cabeceras de herencia que estan ahi solo por el mero hecho de hacer que un binario nuevo tenga compatibilidad con un sistema antiguo.

El campo que vemos como e_lfanew sería el parámetro de inicio del PE Header que importa para analizar, este es un puntero indica donde comienzan esas cabeceras importantes para analizar.

Entre los DOS Header y los PE Header normalmente hay un DOS Stub: es una parte del binario que imprime el mensaje “This program cannot be run in DOS mode” si se intenta ejecutar un .exe en un OS MS-DOS.

• PE Header: Una vez que sigues la dirección marcada por la cabecera e_lfanew nos encontramos dentro de las PE Headers, la primera cabecera siempre comienza con los bytes 50 45 00 00 → PE\0\0 .

El PE Header se divide en tres partes:

• File Header (IMAGE_FILE_HEADER)

• Optional Header (IMAGE_OPTIONAL_HEADER)

Hay que tener en cuenta que a pesar de que su nombre lo diga no es opcional, ya que es esencial para el correcto funcionamiento de binarios

.exe y .dll, esto ya que contiene cabeceras como las siguientes:

• Entry Point es la dirección RVA (Relative Virtual Address) donde Windows empieza a ejecutar código. No siempre es el main() muchas veces pasa primero por el CRT Runtime. Es el primer campo a revisar cuando se analiza Malware.
• Secciones: En la última parte tenemos las secciones, se podria considerar que es un mapa del binario, es un array IMAGE_SECTION_HEADER que describe sección por sección y lo que almacena dentro de ellas.

A continuación, una lista de las secciones que podrían encontrarse si analizaran un binario PE

Secciones del compilador:

Secciones de debugging*:

Secciones de seguridad y protección:

Secciones específicas de .NET / CLR**:

*Estas secciones generalmente se eliminan en builds de Release. Si las ves en un binario sospechoso, puede ser que el autor compiló en modo Debug por descuido, lo cual filtra rutas del sistema, nombres de variables y estructura del proyecto.

**Los binarios .NET tienen una estructura interna completamente diferente dentro de estas secciones. El entry point real lleva al CLR runtime, no directamente al código del programador.

Las letras en permisos significan lo siguiente: R (lectura), W (escritura) y X (ejecución). Es importante aclarar que estos no son los permisos que tienes como usuario sobre el archivo en disco, sino los atributos que el loader de Windows asigna a cada región de memoria cuando carga el binario. Es decir, determinan qué operaciones puede realizar el procesador sobre esa región una vez el ejecutable está en memoria.

Linux: Executable and Linkable Format (ELF)

Los binarios de tipo Executable and Linkable Format son los que le envían instrucciones a maquinas con Kernel de Linux para poder ejecutar instrucciones comprensibles para la máquina. A diferencia del PE que tiene el legado MZ, el ELF fue diseñado desde cero en 1999 como parte del estándar System V ABI, por lo que es más limpio conceptualmente.

Se compone de las siguientes cabeceras (Headers):

• ELF Header: Los primeros bytes de cualquier ELF siempre son 7F 45 4C 46 →

\x7FELF

Este Header tiene la siguiente estructura:

Valores de e_type :

Nota: Los ejecutables modernos compilados con PIE (Position Independent Executable) aparecen como ET_DYN, no como ET_EXEC.

Valores de e_machine

• Program Header Table:

Cada entrada describe un segmento (segment): muestra una sección del binario que el kernel mapea en la memoria.

Tipos de segmentos más importantes:

• Section Header Table:

Cada entrada describe una sección con su contenido especifico:

Secciones más comunes:

MacOS: Mach–O

Es el formato de binario de Apple. Fue creado originalmente para el microkernel Mach en la Universidad Carnegie Mellon y Apple lo adoptó cuando compró NeXT en 1997. A diferencia del PE y el ELF, Mach-O tiene una característica única: los Fat Binaries / Universal Binaries.

Fat Binaries / Universal Binaries

Antes de ver la estructura dejo una lista de los distintos tipos de paquetes que entran dentro de Fat Binaries:

Un Fat Binary es un paquete que ejecuta varios Mach-O el sistema se encarga de elegir el slice correcto cuando ejecuta el paquete, su estructura es algo así:

Además de esto podemos ver sus distintos Headers para saber que encontraríamos a la hora de analizar uno

• Mach-O Header:

Valores de cputype :

Valores de filetype :

Flags importantes:

• Load Commands

Todos los Loads Commands comparten esta cabecera base:

El loader de macOS (dyld) lee cada Load Command en orden y ejecuta las instrucciones que contiene.

Los Load Commands más importantes

LC_LOAD_DYLIB en detalle:

• Segments y Sections

En Mach-O hay una jerarquía de dos niveles Segments que contienen

Sections

Segmentos estándar:

Secciones dentro de __TEXT:

Secciones dentro de __DATA:

Dynamic Linker de Apple (dyld)

El equivalente a ld–linux.so en Linux, pero con diferencias importantes:

Kernel carga un binario → lee LC_LOAD_DYLINKER (/usr/lib/dyld) → dyld procesa LC_DYLD_INFO_ONLY → LC_MAIN (entry point del binario)

dyld procesa LC_DYLD_INFO_ONLY (estructura):

• Rebase: ajusta punteros internos por ASLR

• Binding: resuelve símbolos de librerías externas
• Lazy binding: resuelve símbolos al primer uso

Code Signing – Obligatorio en iOS, importante en macOS

Comparativa de los tres formatos

Créditos: Ezequiel Salinas Bydlowski