Cuando abrimos un binario de Windows, puede parecer un amasijo de bytes indescifrable, pero muchas veces hay texto legible oculto a simple vista. Esas cadenas delatan rutas, nombres de librerías, mensajes de error, indicadores de compilación y hasta pistas forenses de enorme valor. Extraerlas rápido con herramientas adecuadas nos ayuda a entender de qué va un ejecutable, sin tener que depurarlo ni desensamblarlo.
En este recorrido práctico y bien aterrizado verás cómo usar strings.exe (Sysinternals) y su homólogo de Linux, cómo apoyarte en PowerShell para rascar contenido (incluidos flujos NTFS), cómo interpretar señales de firmas y certificados, y qué mirar cuando el texto está camuflado mediante esteganografía o técnicas de ofuscación. Además, repasaremos utilidades clave como certutil, PEStudio, ExifTool, FLOSS, binwalk o la suite ZWSP-Tool para caracteres invisibles, de modo que puedas centrar el tiro desde el minuto uno.
Qué son las cadenas y por qué importan en un binario
Una cadena no es más que una secuencia de bytes interpretada con una codificación (ASCII, UTF-8, UTF-16/Unicode, etc.). En binarios PE de Windows aparecen de forma natural: nombres de funciones importadas, mensajes para el usuario, rutas, manifiestos XML, identificadores de certificados, o avisos del stub DOS como «This program cannot be run in DOS mode». Todo eso cuenta cosas: qué hace el programa, qué necesita y a qué llama.
Que un ejecutable muestre llamadas como LoadLibrary, GetProcAddress o IsDebuggerPresent sugiere dinámicas concretas (carga de módulos, resolución de API en tiempo de ejecución, comprobaciones anti-depuración). Las menciones a VeriSign, Microsoft u OCSP/CRL apuntan a una firma digital incrustada. Y, aunque la salida de una extracción de cadenas suele traer ruido y falsos positivos, un vistazo crítico permite obtener pistas de clasificación muy valiosas.
Tipos de análisis y por dónde empezar para no perder tiempo
Antes de lanzarte a desensamblar, conviene situarse: el trabajo sobre binarios suele dividirse en análisis estático (sin ejecutar), dinámico (observando su comportamiento), y análisis de código (estático/dinámico) si llegas a reversing y depuración. Empezar por lo estático tiene sentido: es rápido, seguro y permite clasificar la muestra o el ejecutable que tienes entre manos.
Un flujo sensato incluye: calcular hashes (SHA-256, etc.) para verificar integridad, identificar el tipo de archivo y su arquitectura (por ejemplo, que sea un PE32 de 32 bits), y levantar un entorno aislado. Trabajar en máquina virtual (Windows para dinámico, Linux/Remnux para utilidades) te da seguridad y flexibilidad; si tratas con varias VMs, verifica que la muestra es idéntica en todas mediante el hash.
Determinado que es un binario PE, toca rascar strings. Es barato en tiempo y puede destapar desde mensajes internos hasta configuraciones o endpoints de red. Si el ejecutable es conocido (por venir de un repositorio), quizá ya tengas “spoilers”; con muestras desconocidas, el valor es todavía mayor.
Extraer texto en Windows con strings.exe, FLOSS y compañía
En Windows lo más directo es strings.exe de Sysinternals. Esta utilidad recorre el archivo y vuelca las secuencias legibles que detecta. Úsala de base y, si la salida es demasiado ruidosa, apóyate en filtros y en el contraste con otras herramientas. Una forma típica de uso sería:
strings.exe binario.exe > cadenas.txtTe encontrarás de todo: desde el clásico stub DOS hasta listas de DLLs importadas, manifest embebido en XML, referencias a OCSP/CRL e incluso nombres de empresas certificadoras. El objetivo es separar el grano de la paja: ¿hay mensajes propios del programa?, ¿variables significativas?, ¿rutas o dominios?, ¿funciones que apunten a capacidades?
Si sospechas ofuscación o empaquetado (UPX, XOR simple sobre datos), prueba con FLOSS (FireEye/FLARE). FLOSS intenta descubrir cadenas construidas en tiempo de ejecución y decodificadas sobre la marcha, algo que strings.exe no ve. Si FLOSS no da más que strings, puede indicar ofuscación más elaborada o que la muestra, sencillamente, no contiene mucho texto interesante en claro.
Complementa siempre con visualizadores como PEStudio y con ExifTool para metadatos: el primero te agrupa indicadores (importaciones, secciones, recursos, firma), y el segundo es un comodín para cualquier archivo que pueda traer metadata útil. Comparar resultados entre herramientas reduce falsos positivos.
Desde el punto de vista del desarrollo, si tu preocupación es que tus registros o mensajes queden expuestos en el binario, existen estrategias como hashear literales en compilación (metaprogramación/UDL), usar arrays de char/hex en lugar de literales o aplicar un parche post-compilación que reemplace texto por su versión cifrada. Cada enfoque tiene trade‑offs: tiempos de compilación mayores, portabilidad limitada (p. ej., VS2013 y C++14), o complejidad para preservar la integridad del ejecutable. Y ojo: aunque ofusques, herramientas como FLOSS o análisis dinámico pueden reconstruir cadenas en ejecución.
Hacer lo mismo en Linux/WSL: el comando strings y algunos trucos
Si prefieres la terminal de Linux (o usas WSL) tienes el comando strings de GNU, con opciones útiles para afinar la salida. El uso mínimo sería:
strings ejemplo.binPara ignorar morralla y centrarte en cadenas de cierto tamaño, tira de -n (o -−−bytes):
strings -n 10 ejemplo.binCuando necesites saber dónde está cada cadena dentro del archivo, añade -t con base hexadecimal o decimal:
strings -t x archivo.binSi manejas muchos binarios, puedes pasarlos todos del tirón, encadenar con head para echar un vistazo rápido o forzar codificación con -e (por ejemplo, UTF-16LE en Windows):
strings archivo1.bin archivo2.bin | head -n 100
strings -e S archivo.binEstos básicos, combinados con grep/awk, te permiten buscar patrones concretos (URLs, rutas, extensiones, yara-likes). En una primera criba, el ahorro de tiempo es brutal.
PowerShell para leer contenido, binarios y flujos NTFS alternativos
PowerShell no es solo para automatizar tareas de sistema: con Get-Content puedes inspeccionar archivos como texto o como bytes, y además leer Alternate Data Streams (ADS) en NTFS. Para un archivo de texto grande, escoge entre lectura estándar (línea a línea) o cruda:
# Texto línea a línea
Get-Content -Path .\archivo.txt
# Todo el contenido en una sola cadena
Get-Content -Path .\archivo.txt -RawCuando te interese solo el final (por ejemplo, logs que crecen), usa -Tail o -TotalCount para acotar:
# Última línea
Get-Content .\archivo.txt -Tail 1
# Primeras 5 líneas
Get-Content .\archivo.txt -TotalCount 5Si el archivo es binario y quieres tratarlo como tal, agrega -AsByteStream (mejor junto a -Raw) para recibir un [byte[]] y procesarlo sin que PowerShell intente convertir nada:
$bytes = Get-Content -Path .\binario.exe -AsByteStream -Raw
$bytes.LengthEl caramelo en NTFS son los ADS: datos «ocultos» que conviven con el archivo principal. Puedes listar y leer streams con el parámetro -Stream:
# Ver streams de un fichero
Get-Item -Path .\sospechoso.txt -Stream *
# Leer el stream primario y uno alternativo
Get-Content -Path .\sospechoso.txt -Stream ':$DATA'
Get-Content -Path .\sospechoso.txt -Stream 'NewStream'Para rutas exactas con caracteres especiales, usa -LiteralPath. Y recuerda que -Filter, -Include y -Exclude ayudan a afinar lotes de ficheros sin tener que reinventar la rueda.
Firma digital, metadatos y qué te cuentan los certificados
En la extracción de cadenas es habitual tropezarse con nombres de CA (VeriSign, Thawte, Microsoft), rutas de CRL/OCSP o incluso cadenas de manifiestos. Eso sugiere que el binario podría estar firmado. En Windows, revisa las propiedades del archivo y, si quieres algo scriptable, tira de Get-AuthenticodeSignature en PowerShell para confirmar la firma y su validez (revocación, fecha, etc.).
También te puede ayudar certutil, una navaja suiza para certificados integrada en Windows. Para tu objetivo (inspección de texto y estructura) destacan:
- -dump: vuelca información de archivos y configuración (útil para ver ASN.1, atributos y cadenas relacionadas).
- -asn: analiza contenido en ASN.1 de .cer, DER o PKCS#7.
- -decode / -encode: decodifica/codifica Base64, y -decodehex / -encodehex para hexadecimal.
- -hashfile: calcula hash de un archivo (MD5, SHA1, SHA256, etc.).
- -store, -verifystore, -viewstore: inspección de almacenes de certificados.
- -verify: comprobación de cadenas de certificados y CRL.
Ejemplos prácticos que te ahorran tiempo: decodificar un blob Base64 que has extraído con strings para ver si hay texto al otro lado; o hacer un -dump de un fichero sospechoso para localizar campos visibles que strings ha pasado por alto:
# Decodificar Base64 a binario
certutil -decode in.txt out.bin
# Decodificar hex a binario
certutil -decodehex in.hex out.bin
# Hash rápido
certutil -hashfile binario.exe SHA256
# Vista ASN.1
certutil -asn firma.derOjo con las firmas: que un ejecutable traiga referencias a certificados no significa que la verificación sea válida. Certificados caducados o revocados hacen que el sistema no confíe en la firma, aunque el binario conserve metadatos con nombres de CA. Esa discrepancia también es indicio a tener en cuenta en la triage.
Cuando el texto está pero no se ve: esteganografía en archivos
No todo el texto «oculto» viene de un PE: a menudo está escondido en documentos, imágenes o audios mediante esteganografía. Conviene saber reconocer técnicas comunes para no pasar por alto mensajes encubiertos que los binarios podrían descargar o generar.
En texto plano, el camuflaje clásico usa espacios/tabs extra al final de línea (0/1), caracteres invisibles de Unicode como Zero-Width Joiner/Non-Joiner, o sustituciones por homoglifos (letras casi idénticas visualmente, distinto código). Herramientas como CyberChef sirven para contar caracteres y desenmascarar. Si quieres ir a tiro fijo con invisibles, ZWSP-Tool lo facilita muchísimo:
$ git clone https://github.com/TwistAtom/ZWSP-Tool.git
$ cd ZWSP-Tool
$ chmod +x install.sh
$ ./install.sh
# Detectar ZWSP con marcadores
$ zwsp-tool detect -P path_to_file/suspicious_text.txt
# Limpiar ZWSP
$ zwsp-tool clean -P path_to_file/suspicious_text.txt
# Incrustar/extractar con cifrado AES
$ zwsp-tool -o result.txt embed -p "Public text" -m "Private text" -e AES
$ zwsp-tool extract -P path_to_file/text.txt -e AES
# Fuerza bruta de ZWSP
$ zwsp-tool bruteforce -P path_to_file/suspicious_text.txtEn audio, hay imágenes escondidas en el espectrograma, datos distintos por canal o metadatos ID3 con sorpresa. Con Sonic Visualiser, Audacity y SoX puedes visualizar, aislar canales y convertir a espectrograma. Si suena a módem o ruido muy «digital», podría ser datos codificados y no música. Para audios/imágenes en general, steghide cifra/oculta y recupera con contraseña; stegsolve y stegonline aplican filtros rápidos; stegseek automatiza el brute-force de contraseñas de steghide.
En imágenes, además de revisar canales R/G/B/A por separado, el clásico es LSB (bits menos significativos) para esconder ficheros arbitrarios sin cambiar el aspecto. No te olvides de EXIF (coordenadas, fecha, cámara) y de que algunos casos son tan simples como otro archivo pegado al final; para eso, binwalk es mano de santo, aunque en PNG hay falsos positivos frecuentes.
Consejos transversales: compara largo visible vs real del texto, escucha audios por canales separados, revisa el tamaño anómalo de archivos y desconfía de coincidencias demasiado bonitas en binarios grandes. Siempre valida con dos herramientas distintas antes de dar un hallazgo por bueno.
Más allá de strings: empaquetado, ofuscación y entropía
Si no salen cadenas útiles, puede que el ejecutable esté empaquetado u ofuscado. UPX es fácil de detectar y desempaquetar; otras técnicas aplican XOR/cifrado simple a datos y recursos. Aquí FLOSS te ayuda con cadenas «dinámicas», y el análisis de secciones del PE y su entropía aporta señales fuertes: entropía alta suele indicar datos comprimidos o cifrados. Herramientas como PEStudio te dan esa lectura en un clic.
Recuerda que hay APIs para resolver importaciones en tiempo de ejecución, así que aunque no veas nombres de funciones en claro, eso no significa que el binario no tenga capacidades. Toca correlacionar: lo que no sale en strings puede salir en trazas dinámicas (ficheros tocados, registro modificado, red, API hooking).
Flujo de trabajo sugerido para extraer texto y señales útiles
Un enfoque que rara vez falla y evita perder horas: 1) Hash e identificación del archivo (tipo/arquitectura). 2) Extracción de strings con Sysinternals y GNU; filtrado por longitud y búsqueda de patrones. 3) Prueba con FLOSS si sospechas strings en runtime. 4) Metadatos con PEStudio y ExifTool, y firma con PowerShell/propiedades. 5) certutil para decodificar blobs Base64/hex y volcado ASN.1. 6) PowerShell ADS para streams alternativos. 7) Si el binario deja artefactos (imágenes, audios, docs), estego toolset (CyberChef, ZWSP-Tool, steghide, binwalk, Sonic Visualiser). 8) Señales de ofuscación/entropía y, si procede, pasar a análisis dinámico.
Unas pinceladas más de certutil que conviene tener a mano al tratar con cadenas y contenido incrustado: -URLcache para revisar/limpiar cachés de CRL/URLs; -syncWithWU y -generateSSTFromWU cuando audites raíces de confianza; y -verifyCTL para listas de confianza (AuthRoot/Disallowed). No son pasos de primer impacto para extraer texto, pero sí contextualizan mucho cuando aparecen referencias a PKI entre las cadenas.
Finalmente, recuerda que Get-Content dispone de parámetros como -ReadCount para ajustar rendimiento, y combinaciones como -Wait (tailing de logs) que, unidos a pipes y expresiones regulares, te dejan montar cribas potentes con muy poco código.
Trabajando así, en minutos tendrás una visión clara: qué se ve a simple vista, qué está ofuscado, qué metadatos cuadran y qué pistas accionables merece la pena seguir con más herramientas o en sandbox. Y lo mejor: sin tocar ni una línea del código interno.