Una metodología de primer análisis para binarios desconocidos

La ingeniería inversa premia la paciencia y castiga las suposiciones — pero la mayor parte del tiempo no hace falta un análisis profundo para responder las primeras preguntas sobre un binario desconocido: ¿qué es esto, aproximadamente, y merece más tiempo del mío? Esta es la rutina de primer análisis que ejecuto antes de abrir el desensamblador en serio. Nada de esto es novedoso; el valor está en hacerlo siempre en el mismo orden, para que las notas de una muestra sean comparables con las de la siguiente.

0. Primero, procedencia y hashes

Antes de que nada se ejecute o se abra: registrar SHA-256, tamaño, origen y timestamps, y comprobar el hash contra bases de datos de muestras conocidas. Dos minutos de contabilidad ahorran horas de re-análisis después — y, de vez en cuando, terminan la investigación de inmediato.

1. Identidad del archivo, no su extensión

file, magic bytes y una revisión de cabeceras. ¿Es de verdad un PE/ELF? ¿Qué arquitectura, qué linker, qué artefactos de compilador? Los packers se delatan aquí más a menudo de lo que la gente espera: nombres de sección raros, entry points anómalos o una sección .text sospechosamente pequeña.

2. Strings — pero leídas como evidencia

Todo el mundo ejecuta strings; menos gente lee la salida con ojo crítico. Yo busco tres clases:

• Infraestructura: URLs, IPs, dominios, user agents, rutas de registro
• Pistas de capacidades: format strings, mensajes de error, plantillas de comandos
• Ausencia: un programa real tiene strings aburridas por todas partes. Un binario casi sin ellas te está diciendo que está empaquetado u ofuscado — lo cual ya es, en sí mismo, un hallazgo.

3. Los imports como mapa de capacidades

La tabla de imports es el resumen de comportamiento más barato que vas a conseguir. VirtualAlloc + WriteProcessMemory + CreateRemoteThread se lee como inyección; CryptEncrypt junto a APIs de enumeración de ficheros se lee como ransomware; casi ningún import se lee como un loader que lo resuelve todo en tiempo de ejecución. Escribe la hipótesis antes del desensamblado — el objetivo de la pasada profunda es falsarla.

4. La entropía te dice dónde mirar

La entropía por sección separa lo empaquetado de lo plano en segundos. Un .rsrc o un overlay con entropía alta es donde se esconden los payloads; un .text de entropía alta significa que el programa real solo existe en ejecución, y el análisis estático debe desplazarse al stub de desempaquetado en lugar de al ruido.

5. Solo ahora, el desensamblador

Con una hipótesis, el tiempo en Ghidra es dirigido en lugar de exploratorio: entry point, las funciones que referencian las strings e imports interesantes, referencias cruzadas hacia fuera. Anoto sobre la marcha y paro cuando la hipótesis queda confirmada o rota — el objetivo de una primera pasada es una decisión (escalar, archivar o detonar en el laboratorio), no una reconstrucción completa.

La meta-lección

La rutina importa más que las herramientas. Cada paso produce un artefacto — hashes, identidad, clases de strings, mapa de capacidades, perfil de entropía — y los artefactos componen un informe de triage que otra persona puede revisar. Esa revisabilidad es lo que separa el análisis de las sensaciones, y es exactamente la parte que merece automatizarse. Automatizarla es un proyecto en curso — el toolkit de triage de binarios — y esta checklist es su especificación.