Análisis estático

El análisis estático examina un binario sin ejecutarlo: desensamblas y decompilas el código para leer su lógica, inspeccionas las cadenas, los imports, la estructura y los datos. Es la base del reversing porque te da el mapa completo del programa de forma segura (no ejecutas malware) y reproducible. La herramienta estrella es el decompilador, que reconstruye un pseudo-C legible a partir del código máquina.

Qué miras (y con qué)

# información general del binario
file / rabin2 -I      arquitectura, formato, stripped, protecciones
checksec              mitigaciones (ELF)
# contenido legible
strings               mensajes, rutas, URLs, claves, pistas
# símbolos e imports
nm / readelf -s       funciones (si no está stripped)
objdump -T / rabin2 -i   imports (qué funciones de librería usa -> pistas de comportamiento)
# desensamblar/decompilar
Ghidra / IDA / r2     el código en ensamblador + pseudo-C

Los imports son muy reveladores: si un binario importa socket/connect, hace red; CreateFile/RegSetValue, toca ficheros/registro; VirtualAlloc/WriteProcessMemory, probablemente inyecta código (malware).

Ghidra: el flujo de trabajo

1. Importar el binario -> auto-análisis
2. Symbol Tree / Functions -> localizar main (o entry)
3. Decompiler window -> leer el pseudo-C de cada función
4. renombrar variables/funciones a medida que entiendes (clave para no perderse)
5. seguir referencias cruzadas (xrefs): quién llama a qué, quién usa una variable/string
6. anotar y reconstruir la lógica hasta responder la pregunta (¿cómo valida? ¿qué hace?)

El decompilador no da código perfecto, pero sí comprensible: renombrar y comentar sobre la marcha es lo que convierte un volcado confuso en lógica clara.

Técnicas útiles

# cross-references (xrefs): localizar dónde se usa un string/función
#   -> encontrar la función de validación buscando xrefs al mensaje "Wrong password!"
# seguir la cadena desde un string interesante hasta la lógica que lo usa
# identificar algoritmos conocidos (constantes de cripto: AES S-box, MD5, etc.)
#   -> herramientas como FindCrypt / signsrch reconocen constantes criptográficas
# reconocer estructuras/clases (C++), vtables
# comparar binarios (bindiff) para encontrar qué cambió entre versiones (parches -> 1-day)

Cuándo el estático se complica

# código ofuscado: control flow flattening, strings cifradas, packing
#   -> el pseudo-C es ilegible; combinar con dinámico (rev-dynamic)
# packers: el ejecutable está comprimido/cifrado; el código real solo existe en runtime
#   -> desempacar (dinámico) y luego analizar estáticamente el dump
# binarios stripped: sin nombres de función -> más trabajo de reconstrucción

Para malware (precaución)

El análisis estático es seguro porque no ejecutas el código — ideal como primer paso con malware. Aun así, abrir el fichero en herramientas en una VM aislada es buena práctica. Para lo que esté cifrado/empacado, harás falta dinámico, y ahí sí hay que extremar el aislamiento (ver malware).

Para la defensa (dificultar el estático)

- stripping de símbolos, ofuscación de código y de strings (cifrado en runtime)
- packers/protectores comerciales
- comprobaciones de integridad
# todo esto encarece el análisis estático, no lo impide (ver rev-antidebug)

Checklist de prueba

file/checksec/strings/imports como primer mapeo
Localizar main/entry y la lógica relevante en Ghidra
Leer el pseudo-C y renombrar variables/funciones
Usar xrefs para seguir strings/funciones hasta la lógica
Reconocer algoritmos/constantes (cripto: FindCrypt)
Identificar si hay ofuscación/packing (¿pasar a dinámico?)
Reconstruir la lógica y responder la pregunta del reto
Combinar con dinámico si el estático se atasca