Analizador de Bibliotecas Nativas (.so) de Android
Analiza archivos .so de Android online y gratis. Nuestro analizador de bibliotecas nativas interpreta cabeceras ELF, tablas de símbolos, funciones JNI, importaciones, exportaciones y cabeceras de sección. Rápido, seguro y sin registro.
Upload an Android .so File to Begin
Upload any Android native library (.so file) to analyze its ELF structure, symbol tables, JNI functions, imports and exports, section headers, and detect symbol stripping. All processing is completely local in your browser.
¿Por qué usar nuestro Analizador de Bibliotecas Nativas (.so) de Android?
- Análisis completo de la cabecera ELF: el analizador de bibliotecas nativas interpreta toda la estructura de la cabecera ELF: magia de identificación, clase (32/64 bits), codificación de datos (endianness), SO/ABI (Linux, Android, System V), tipo de máquina (ARM, AArch64, x86, x86-64), tipo de archivo, dirección del punto de entrada y ubicación de las tablas de cabeceras de programa y de sección. Todos los campos se decodifican en etiquetas legibles, con los valores hexadecimales mostrados al lado.
- Análisis exhaustivo de la tabla de símbolos: extrae y muestra todos los símbolos de las tablas .symtab y .dynsym con sus nombres, tipos (FUNC, OBJECT, NOTYPE), enlaces (LOCAL, GLOBAL, WEAK), visibilidad (DEFAULT, HIDDEN, PROTECTED), direcciones, tamaños y secciones asociadas. Filtra por exportaciones, importaciones, funciones JNI o todos los símbolos con una interfaz con búsqueda.
- Detección y análisis de funciones JNI: detecta automáticamente las funciones JNI (Java Native Interface) por su convención de nombres Java_. Cada función JNI se resalta con una insignia especial que muestra su nombre JNI completo. El analizador extrae los componentes de paquete, clase y método de cada nombre Java_ para consultarlos fácilmente durante la ingeniería inversa.
- Análisis de stripping y seguridad: detecta si el archivo .so tiene los nombres de símbolos eliminados, una técnica de ofuscación habitual tanto en compilaciones de lanzamiento legítimas como en malware. El analizador también identifica funciones de seguridad clave: cabeceras de programa GNU_RELRO (reubicación de solo lectura), secciones GOT/PLT, almacenamiento local de hilos, tablas de manejo de excepciones y constructores .init_array.
Casos de uso comunes del Analizador de Bibliotecas Nativas de Android
- Análisis de malware y spyware de Android: los ingenieros inversos analizan archivos .so de APK sospechosos para detectar código nativo malicioso. El malware suele usar bibliotecas nativas para ejecutar payloads, aplicar técnicas anti-análisis y escalar privilegios. El analizador de bibliotecas nativas revela funciones JNI con nombres sospechosos, tablas de símbolos ofuscadas y funciones del sistema importadas que indican comportamiento malicioso.
- Revisión de seguridad de apps y pentesting: los auditores de seguridad examinan bibliotecas nativas para verificar que las compilaciones de lanzamiento estén correctamente stripped, que se hayan eliminado los símbolos de depuración y que no queden nombres de funciones sensibles expuestos. El analizador ayuda a identificar símbolos de desarrollador olvidados, funciones JNI que exponen lógica de API del backend y funciones importadas que podrían explotarse para corromper memoria.
- Inspección de SDK de terceros: analiza los componentes nativos de SDK de Android de terceros antes de integrarlos. El analizador de bibliotecas nativas revela qué funciones del sistema importa el SDK, qué callbacks JNI registra y si contiene exportaciones inesperadas. Esto es fundamental en SDK que manejan datos sensibles como identificadores publicitarios, huellas de dispositivo o analítica.
- Desarrollo y depuración con NDK: los desarrolladores de Android NDK usan el analizador para verificar que sus archivos .so compilados tengan la arquitectura correcta (arm64-v8a, armeabi-v7a, x86_64), las exportaciones de funciones JNI adecuadas y la visibilidad de símbolos esperada. Ayuda a depurar problemas de enlazado, exportaciones faltantes y exposición no intencionada de símbolos antes del lanzamiento.
- Investigación de vulnerabilidades y desarrollo de exploits: los investigadores de vulnerabilidades examinan archivos .so para obtener información de versión, identificar compilaciones concretas de bibliotecas y analizar las funciones importadas para entender la superficie de ataque. El análisis de cabeceras de sección revela segmentos escribibles y ejecutables, la ausencia de protección RELRO y otras vulnerabilidades de corrupción de memoria.
- Aprendizaje del formato de archivo ELF: los estudiantes que aprenden la especificación ELF (Executable and Linkable Format) pueden ver un archivo ELF real analizado, con todas sus cabeceras, secciones y símbolos mostrados. El analizador asocia cada campo de la estructura ELF con su definición en la especificación, lo que lo convierte en una excelente herramienta didáctica para entender cómo funcionan las bibliotecas compartidas en Linux y Android.
¿Qué es un archivo .so de Android?
Un archivo .so (Shared Object) es el equivalente en Android a una biblioteca de enlace dinámico en Linux. Las apps de Android usan bibliotecas nativas escritas en C o C++ mediante el Android NDK (Native Development Kit) para código crítico para el rendimiento, motores de juego, criptografía, procesamiento de señales y SDK de terceros. Estas bibliotecas siguen la especificación ELF (Executable and Linkable Format), el mismo formato que usan los ejecutables y bibliotecas compartidas de Linux. Cada archivo .so contiene código máquina compilado para una arquitectura de CPU concreta -ARM, ARM64, x86 o x86-64- y se carga en el proceso de la app en tiempo de ejecución mediante System.loadLibrary(). El analizador de bibliotecas nativas interpreta esta estructura ELF para revelar cabeceras, secciones, símbolos y funciones JNI.
Cómo funciona el Analizador de Bibliotecas Nativas de Android
- Sube tu archivo .so: selecciona cualquier biblioteca nativa de Android para analizarla. El analizador lee los datos binarios ELF directamente en tu navegador, sin subida a servidores: todo el procesamiento es local.
- Análisis ELF: la herramienta lee la magia de identificación ELF (\x7fELF), determina la clase (32 o 64 bits) y el endianness, y luego interpreta toda la cabecera ELF, incluidas las cabeceras de programa (segmentos) y las cabeceras de sección. Sigue la tabla de cadenas de cabeceras de sección para resolver nombres como .text, .data, .bss, .dynsym y .init_array.
- Extracción y análisis de símbolos: el analizador interpreta tanto la sección .symtab (tabla de símbolos) como la .dynsym (tabla de símbolos dinámicos), resolviendo los nombres a través de las tablas de cadenas correspondientes (.strtab y .dynstr). Cada símbolo se clasifica por tipo, enlace y visibilidad. Las funciones JNI (con prefijo Java_) se detectan y etiquetan automáticamente, y se comprueba si la biblioteca tiene los símbolos eliminados.
Estructuras ELF clave que verás
- Cabecera ELF: la cabecera de 52-64 bytes al inicio de cada archivo .so, que contiene el número mágico, la clase (32/64 bits), el orden de bytes, el SO/ABI, el tipo de máquina (ARM, AArch64, x86) y los punteros a las tablas de cabeceras de programa y de sección.
- Cabeceras de programa: describen los segmentos que se cargan en memoria en tiempo de ejecución. Los segmentos LOAD se asignan al espacio de direcciones del proceso. DYNAMIC contiene información de enlazado dinámico. GNU_RELRO hace que los datos de reubicación sean de solo lectura tras la carga. INTERP especifica la ruta del enlazador/cargador dinámico.
- Cabeceras de sección: describen la disposición del archivo en tiempo de enlazado, incluidas .text (código ejecutable), .data (datos inicializados), .bss (datos sin inicializar), .dynsym/.dynstr (símbolos dinámicos), .init_array/.fini_array (funciones constructoras/destructoras), .got/.got.plt (tabla de desplazamiento global), .plt (tabla de enlace de procedimientos) y .ARM.exidx (índice de excepciones ARM).
- Tablas de símbolos: contienen nombres de funciones y variables con sus direcciones, tamaños, tipos (FUNC, OBJECT, NOTYPE) y enlaces (LOCAL, GLOBAL, WEAK). Los símbolos dinámicos se usan para el enlazado en tiempo de ejecución, mientras que los símbolos normales se usan para depuración y pueden eliminarse en compilaciones de lanzamiento.
Privacidad, seguridad y notas de uso
El Analizador de Bibliotecas Nativas de Android procesa todos los archivos íntegramente en tu navegador con JavaScript. Ningún dato de archivo se sube jamás a un servidor, se almacena en ninguna base de datos ni se comparte con terceros. No hay límite de tamaño más allá de lo que pueda manejar tu navegador: los archivos de más de 100 MB pueden tardar más en procesarse, pero nunca saldrán de tu dispositivo. Todo el análisis ELF, la extracción de tablas de símbolos, la detección de JNI y el análisis de secciones se hace localmente. Exporta los informes de análisis en JSON para compartir los resultados con tu equipo o guardarlos.
Preguntas frecuentes
Un archivo .so (Shared Object) es una biblioteca nativa que usan las apps de Android para código crítico para el rendimiento escrito en C o C++. Analizar archivos .so revela la estructura ELF, las funciones importadas y exportadas, los métodos JNI invocables desde Java/Kotlin y posibles problemas de seguridad. Como el código nativo tiene acceso directo a la memoria, analizar archivos .so es fundamental para auditorías de seguridad y análisis de malware.
Android admite cuatro arquitecturas de CPU principales para bibliotecas nativas: arm64-v8a (ARM de 64 bits, la mayoría de dispositivos modernos), armeabi-v7a (ARM de 32 bits, dispositivos antiguos), x86_64 (emuladores Intel/AMD de 64 bits y algunas tablets) y x86 (x86 de 32 bits, emuladores antiguos). El Analizador de Bibliotecas Nativas de Android detecta automáticamente la arquitectura a partir del campo de tipo de máquina del encabezado ELF.
Las funciones JNI (Java Native Interface) son funciones de C/C++ invocables desde Java o Kotlin mediante la convención de nombres Java_packagename_Class_method. Sirven de puente entre la app de Android y el código nativo. El analizador detecta todas las funciones JNI por su prefijo Java_, lo que facilita identificar la superficie completa de API nativa de cualquier archivo .so.
Una biblioteca stripped tiene los nombres de símbolos eliminados de la sección .symtab, conservando la sección .dynsym para el enlazado en tiempo de ejecución. Es habitual en compilaciones de lanzamiento, pero dificulta la ingeniería inversa. El analizador detecta el stripping comprobando si existen símbolos con nombre en la tabla de símbolos.
Por supuesto. Todo el análisis ELF, la extracción de tablas de símbolos, la detección de JNI y el análisis de secciones se realizan localmente en tu navegador con JavaScript. Tus archivos .so nunca se suben a ningún servidor, ni se guardan en ninguna base de datos, ni se transmiten por la red.
La GOT (Global Offset Table) y la PLT (Procedure Linkage Table) son secciones ELF que permiten el enlazado dinámico en tiempo de ejecución. La GOT contiene las direcciones de variables globales y funciones importadas de otras bibliotecas. La PLT contiene código auxiliar que resuelve las direcciones de funciones en la primera llamada (enlazado perezoso).
GNU_RELRO (Relocation Read-Only) es una cabecera de programa que marca los datos de reubicación como de solo lectura una vez que el enlazador dinámico los ha resuelto. Así se evita que los atacantes sobrescriban entradas de la GOT para secuestrar el flujo de control. El analizador de bibliotecas nativas comprueba esta función de seguridad.
Sí, el analizador ofrece dos opciones de exportación: Copiar informe genera un resumen en texto plano con la información de la cabecera ELF, los recuentos de símbolos, el número de funciones JNI y el estado de stripping. Exportar JSON crea un archivo JSON estructurado con todos los datos analizados para su posterior análisis.
La sección .init_array contiene punteros a funciones constructoras que se ejecutan al cargar la biblioteca. El malware suele usar .init_array para rutinas de inicialización o descifrado de payloads. La sección .fini_array contiene destructores que se llaman al descargar la biblioteca. El analizador detecta la presencia de ambas secciones.