Cómo ver los módulos y bibliotecas cargados por un proceso en macOS

Toda aplicación de macOS carga bibliotecas dinámicas (dylibs) y frameworks en tiempo de ejecución. Inspeccionar estos módulos cargados te ayuda a depurar problemas de enlazado, auditar dependencias de terceros, detectar bibliotecas inyectadas y entender la arquitectura interna de una app. Esta guía cubre cinco métodos para comprobar qué módulos ha cargado un proceso, desde herramientas de línea de comandos integradas hasta una app gráfica dedicada.

Respuesta rápida

Usa vmmap <pid> | grep '\.dylib' en el Terminal para listar todas las bibliotecas dinámicas que ha cargado un proceso en ejecución. Para las dependencias de enlazado estático, usa otool -L /ruta/al/binary. Para una interfaz visual y con búsqueda que muestre los módulos cargados con rutas de archivo, versiones y UUIDs con un solo clic, usa ProcXray.

¿Qué son los módulos cargados en macOS?

Un módulo cargado es una biblioteca dinámica (.dylib), un framework (.framework) o un bundle (.bundle) que el enlazador dinámico de macOS (dyld) mapea en el espacio de direcciones de un proceso en tiempo de ejecución. Hay dos categorías:

• Dependencias en tiempo de carga: bibliotecas contra las que se enlaza el binario en tiempo de compilación. El enlazador dinámico las carga automáticamente al iniciarse el proceso.
• Bibliotecas cargadas en tiempo de ejecución: bibliotecas cargadas bajo demanda mediante dlopen() durante la ejecución. Los plugins, las extensiones y las funciones opcionales suelen usar este patrón.

Los procesos del sistema de macOS suelen cargar entre 100 y 300 módulos, mientras que apps complejas como Xcode o Chrome pueden cargar más de 1000. Saber qué módulos están cargados es fundamental para diagnosticar fallos, identificar conflictos de versiones y auditar la seguridad.

Método 1: vmmap — Listar todos los módulos cargados de un proceso en ejecución

El comando vmmap muestra las regiones de memoria virtual de un proceso en ejecución. Como cada dylib cargada ocupa su propia región de memoria, puedes filtrar la salida para ver cada módulo que hay actualmente en memoria.

# Listar todas las dylibs cargadas de un proceso en ejecución por PID
vmmap <pid> | grep '\.dylib'

Para encontrar primero el PID:

# Encontrar el PID de Safari
pgrep -x Safari

Ejemplo de salida:

__TEXT   7FF80B2A0000-7FF80B2C1000  r-x/r-x  /usr/lib/system/libsystem_kernel.dylib
__TEXT   7FF80B2C1000-7FF80B2FD000  r-x/r-x  /usr/lib/system/libsystem_c.dylib
__TEXT   7FF80B300000-7FF80B365000  r-x/r-x  /usr/lib/libobjc.A.dylib

Cada línea muestra el rango de direcciones de memoria, los permisos y la ruta completa de la biblioteca cargada.

Para incluir también los frameworks:

# Mostrar todas las dylibs y frameworks cargados
vmmap <pid> | grep -E '\.(dylib|framework)/'

Para contar cuántos módulos están cargados:

vmmap <pid> | grep '\.dylib' | awk '{print $NF}' | sort -u | wc -l

Cuándo usar vmmap

Usa vmmap cuando necesites ver todo lo que un proceso en ejecución ha cargado realmente en memoria, incluidos los módulos cargados en tiempo de ejecución que otool no puede mostrar. Requiere que el proceso esté en ejecución y puede requerir privilegios elevados para los procesos del sistema.

Método 2: otool -L — Comprobar las dependencias de enlazado estático

El comando otool inspecciona binarios Mach-O. La opción -L lista todas las bibliotecas dinámicas contra las que el binario se enlaza en tiempo de compilación.

# Listar las bibliotecas enlazadas de un binario de aplicación
otool -L /Applications/Safari.app/Contents/MacOS/Safari

Ejemplo de salida:

/Applications/Safari.app/Contents/MacOS/Safari:
    /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    /usr/lib/libSystem.B.dylib
    /usr/lib/libc++.1.dylib

Esto muestra las bibliotecas que el binario espera cargar: sus dependencias en tiempo de compilación. No muestra las bibliotecas cargadas en tiempo de ejecución mediante dlopen().

Para inspeccionar las propias dependencias de una dylib concreta:

otool -L /usr/lib/libobjc.A.dylib

Cuándo usar otool

Usa otool -L cuando quieras saber qué debería cargar un binario antes incluso de ejecutarlo. Es útil para verificar configuraciones de compilación, comprobar que se enlazan los frameworks del SDK correctos y detectar dependencias que faltan.

Método 3: lsof — Encontrar bibliotecas cargadas a través de los archivos abiertos

El comando lsof lista todos los archivos abiertos por un proceso. Como las bibliotecas cargadas son archivos mapeados en memoria, aparecen en la salida de lsof.

# Listar todos los archivos .dylib cargados de un proceso
lsof -p <pid> | grep '\.dylib'

Para incluir los frameworks:

lsof -p <pid> | grep -E '\.(dylib|framework)'

Cuándo usar lsof

Usa lsof cuando necesites una comprobación rápida y ya estés familiarizado con él. Sin embargo, vmmap proporciona información más detallada (direcciones de memoria, permisos) y es la herramienta preferida para inspeccionar módulos.

Método 4: dyld_info — Inspeccionar el enlazador dinámico

A partir de macOS 12 (Monterey), Apple proporciona el comando dyld_info para inspeccionar la información del enlazador dinámico.

# Mostrar todas las dylibs dependientes de un binario
dyld_info -dependents /Applications/Safari.app/Contents/MacOS/Safari

Para inspeccionar el uso de la caché compartida de dyld de un proceso en ejecución:

# Listar la plataforma y las dependencias
dyld_info -platform -dependents /usr/lib/libobjc.A.dylib

Cuándo usar dyld_info

Usa dyld_info cuando necesites información detallada sobre el comportamiento del enlazador dinámico, incluidos los requisitos de plataforma y las cadenas de dependencias. Ofrece una salida más limpia que otool para el análisis de dependencias.

Método 5: ProcXray — Inspector visual de módulos

ProcXray ofrece una pestaña Modules dedicada que muestra todos los módulos cargados de cualquier proceso en ejecución, sin comandos que recordar ni salidas que analizar.

Cómo inspeccionar módulos con ProcXray

1. Abre ProcXray.
2. Selecciona un proceso en la lista de procesos (usa la barra de búsqueda o la vista de árbol para encontrarlo).
3. Haz clic en la pestaña Modules del panel de detalles.
4. Explora la lista completa de dylibs y frameworks cargados, con rutas de archivo y detalles.

Usa el campo de búsqueda de la pestaña Modules para filtrar por nombre de biblioteca; por ejemplo, escribe «libsystem» para encontrar todas las bibliotecas del sistema cargadas, o «swift» para localizar los módulos del runtime de Swift.

Qué añade ProcXray frente a las herramientas de línea de comandos

• Inspección con un clic. Selecciona un proceso, haz clic en Modules y listo. No hace falta encontrar el PID ni escribir comandos.
• Búsqueda y filtrado. Filtra módulos por nombre al instante con resultados en tiempo real.
• Contexto completo. Ve los módulos junto a las variables de entorno, los archivos abiertos, las conexiones de red y las firmas de código del proceso en pestañas contiguas.
• Funciona con todos los procesos. Inspecciona cualquier proceso en ejecución sin construir comandos distintos para cada situación.

Comparación de métodos

Casos de uso prácticos

Depurar un fallo relacionado con una versión de biblioteca incorrecta o ausente

# Comprobar si está cargada la versión de biblioteca esperada
vmmap <pid> | grep 'libssl'

Si la salida apunta a una libssl distinta de la esperada (por ejemplo, una versión de Homebrew en lugar de la del sistema), has encontrado el conflicto de versiones.

Auditar una app en busca de bibliotecas inyectadas

Los investigadores de seguridad y los desarrolladores pueden comprobar si se han cargado bibliotecas inesperadas en un proceso:

# Buscar bibliotecas que no provengan de /System o /usr/lib
vmmap <pid> | grep '\.dylib' | grep -v '/System/' | grep -v '/usr/lib/'

Cualquier resultado puede indicar inyecciones de terceros, plugins o frameworks personalizados que merecen una investigación.

Comprobar si una app usa un framework concreto

# ¿Usa esta app SwiftUI?
vmmap <pid> | grep 'SwiftUI'

# ¿Está enlazada contra Metal?
otool -L /path/to/binary | grep 'Metal'

Preguntas frecuentes

¿Cuál es la diferencia entre una dylib y un framework en macOS?

Una .dylib es un archivo de biblioteca dinámica autónomo. Un .framework es un directorio bundle que contiene una dylib junto con cabeceras, recursos y metadatos. Los frameworks son el formato de empaquetado estándar para las bibliotecas del sistema de Apple y los SDKs de terceros. En tiempo de ejecución, dyld carga ambos de la misma manera.

¿Puedo ver qué dylibs usa una app en ejecución sin el Terminal?

Sí. ProcXray te permite seleccionar cualquier proceso en ejecución y ver sus módulos cargados en una interfaz gráfica con búsqueda integrada. No hacen falta comandos de terminal.

¿Por qué un proceso carga cientos de bibliotecas?

macOS depende en gran medida del enlazado dinámico. Incluso una sencilla app «Hello World» escrita en Swift carga más de 100 módulos, porque el runtime de Swift, el framework Foundation y las bibliotecas del sistema básicas arrastran cada uno sus propias dependencias. Esto es normal y está diseñado así: las bibliotecas compartidas reducen el uso de memoria en todo el sistema.

¿Muestra otool -L todo lo que cargará un proceso?

No. otool -L solo muestra las dependencias de enlazado en tiempo de compilación. Las bibliotecas cargadas en tiempo de ejecución mediante dlopen() —como plugins, funciones opcionales y componentes de carga diferida— no se muestran. Usa vmmap en el proceso en ejecución para ver el panorama completo.

¿Necesito sudo para inspeccionar los módulos de otro proceso?

Para tus propios procesos, no. Para procesos del sistema o procesos de otros usuarios, puede que necesites sudo con vmmap y lsof. ProcXray te pedirá los permisos de macOS necesarios la primera vez que lo abras.

Fuentes y referencias

• Apple: vmmap man page
• Apple: otool man page
• Apple: dyld — Dynamic Link Editor
• Apple: lsof man page

Descarga ProcXray → — gratis, macOS Sonoma+.