Análisis binario y estático

1. Qué es y por qué existe

Los tres documentos anteriores cubren un solo plano: el DEX, sus recursos y su contenedor. Es donde vive la mayor parte de una aplicación Android y donde trabajan jadx, apktool y APKEditor.

No es donde vive todo. Un APK moderno lleva bibliotecas nativas en lib/<abi>/*.so que son binarios ELF de ARM o x86, ajenos por completo al DEX; y una aplicación hace cosas en ejecución —resolver dominios, descifrar cadenas, cargar código— que ningún análisis estático observa directamente. Cuando la lógica interesante se mueve al código nativo, se mueve precisamente para salir del alcance de los documentos anteriores.

Este documento reparte el instrumental en tres categorías de trabajo, y esa clasificación es lo más útil que aporta:

Confundirlas es el error de encuadre habitual: buscar en el smali una lógica que está en un .so, o abrir Ghidra para leer código Java.

Frontera de este documento. Todo lo que sigue se documenta como instrumental de análisis legítimo, que es lo que es. Las técnicas para saltarse PairIP o Play Integrity y el desempaquetado de packers comerciales están fuera del alcance de este corpus por decisión, no por descuido. Lo que sí se documenta es cómo se detectan esas protecciones y qué implican para el análisis.

2. Ghidra

Consultado el 12 de agosto de 2026 vía la API de GitHub. Muy activo. El dominio histórico ghidra-sre.org redirige hoy al repositorio de GitHub, que es la fuente canónica.

Es la suite de ingeniería inversa más importante que existe en abierto: desensamblador, decompilador a pseudo-C, gestor de proyectos, comparación de binarios, scripting en Java y Python, y trabajo colaborativo con servidor propio. Que sea Apache-2.0 y gratis es lo que convirtió el análisis de binarios en algo accesible fuera de las empresas que podían pagar IDA.

2.1 Para qué se usa en Android

Para el código nativo, que es el caso principal. Se extrae el .so del APK —un unzip basta— y se abre en Ghidra:

unzip -j app.apk 'lib/arm64-v8a/*.so' -d nativos/

A partir de ahí, el trabajo es el de cualquier binario ELF de ARM64: identificar funciones, seguir referencias cruzadas, leer el decompilador. Lo específico de Android es el puente JNI: las funciones exportadas con nombres del tipo Java_com_ejemplo_Clase_metodo son las llamables desde el DEX, y son el punto de entrada natural. Las registradas dinámicamente con RegisterNatives no aparecen en la tabla de símbolos y hay que buscarlas en JNI_OnLoad — que es exactamente por qué se registran así.

El detalle del formato y de la convención JNI está en Código nativo y ELF.

2.2 El soporte de DEX y APK, que ya viene de serie

Aquí hay una confusión frecuente que conviene deshacer: el soporte de Android no es una extensión de terceros, viene en la distribución oficial. La documentación de formatos de fichero de Ghidra registra:

Y existe un módulo de procesador Dalvik en el árbol del proyecto, bajo Ghidra/Processors/Dalvik/, con sus propios inject payloads para el decompilador.

Dicho lo cual, hay que ser honesto sobre su utilidad práctica:

• Para leer código Java, jadx es mejor, y por bastante. El camino natural es jadx para el DEX y Ghidra para el .so.
• El soporte de multidex es una limitación conocida. La issue #4276 del repositorio está abierta sobre ello, y en una aplicación real la lógica está repartida entre classes.dex, classes2.dex y sucesivos.
• La cobertura declarada llega hasta Android 12, lo que deja fuera las versiones de DEX más recientes.

⚠️ sin verificar: no se ha podido confirmar en esta revisión hasta qué punto el decompilador de Ghidra produce salida utilizable sobre bytecode Dalvik, ni el estado actual de la issue #4276; la API de GitHub devolvió 403 por límite de tasa al consultar issues.

2.3 Extensiones

El marco de extensiones de Ghidra está en Java y permite añadir cargadores, procesadores y analizadores. Han existido varias extensiones de terceros orientadas a Android, en buena medida anteriores a que el soporte nativo de DEX/APK entrara en la distribución oficial.

⚠️ sin verificar: no se ha podido determinar qué extensiones de Ghidra para Android siguen mantenidas en 2026. La búsqueda en la API de GitHub devolvió cero resultados para los términos consultados y las consultas de repositorios concretos fueron bloqueadas por límite de tasa. Se prefiere declarar el hueco a listar proyectos cuyo estado no se ha comprobado.

Lo que sí está verificado es que el soporte base no requiere extensión alguna.

3. radare2, rizin y Cutter

Tres nombres, dos linajes y una escisión que conviene entender.

Consultado el 12 de agosto de 2026 vía la API de GitHub. Los tres están vivos: radare2 y rizin recibieron commits el mismo día de la consulta.

La API reporta la licencia de radare2 como NOASSERTION porque su COPYING.md no es un texto estándar: declara que la mayor parte del proyecto es LGPLv3 pero que dependencias y plugins concretos llevan licencias distintas. Para uso corporativo, eso obliga a revisar plugin por plugin.

radare2 es el proyecto original: un marco de ingeniería inversa de línea de órdenes con una curva de aprendizaje pronunciada y una densidad de funcionalidad enorme. Su fortaleza real es que es scriptable de arriba abajo y se comporta bien en procesamiento por lotes, que es donde Ghidra y IDA son incómodos.

rizin es un fork de radare2 nacido en septiembre de 2020, con el objetivo declarado de una base de código más limpia, una API más estable y mejor documentación. Es una escisión de gobernanza, no técnica. Menos tracción bruta —3.775 estrellas frente a 24.557— pero desarrollo igualmente activo.

Cutter es la interfaz gráfica de rizin, y su nombre despista: 19.452 estrellas, más que el motor que la mueve. Es la puerta de entrada para quien quiere el motor de rizin sin la línea de órdenes de rizin.

3.1 En qué se diferencian de Ghidra

En la práctica se complementan: rizin o radare2 para «dime rápido qué hay en estos ochenta .so», Ghidra para «voy a pasar tres horas entendiendo esta función».

4. IDA Pro

El estándar comercial. La hace Hex-Rays SA.

Su propia descripción: «A powerful disassembler, decompiler and a versatile debugger. In one tool.» Más de 60 desensambladores, y decompiladores para x86, ARM, MIPS, PPC, RISC-V, ARC y V850 según la edición. Ediciones: IDA Free, IDA Home, IDA Classroom, IDA Pro e IDA Pro OEM, con licencias nominales, por equipo o flotantes. La página del producto no publica precios y remite a la sección de compra. Consultado el 12 de agosto de 2026.

Qué aporta frente a Ghidra: un decompilador con reputación de producir salida más limpia, soporte de arquitecturas exóticas, y depuración remota muy pulida. Para trabajo profesional continuado sobre binarios difíciles, sigue siendo la referencia.

Qué le juega en contra: además del precio, un cambio de modelo. IDA eliminó la licencia perpetua en octubre de 2024 y pasó a suscripción, un movimiento que empujó a parte de sus usuarios hacia Ghidra. El listón de calidad sigue siendo suyo; el de accesibilidad se lo llevó Ghidra en 2019.

5. MobSF

Consultado el 12 de agosto de 2026 vía la API de GitHub. Muy activo: la última release es del mismo día del último push, y solo 19 issues abiertas para un proyecto de once años y 21.587 estrellas indican una gestión de cola muy disciplinada.

Se describe como «a security research platform for mobile applications in Android, iOS and Windows Mobile». Hace análisis estático de binarios APK, IPA y APPX y de código fuente; análisis dinámico interactivo para Android e iOS con captura de tráfico y datos en ejecución; y análisis de malware y evaluación de privacidad.

Se despliega con Docker o con pip:

docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Credenciales por defecto mobsf/mobsf. Requiere Python 3.12 o superior para la instalación directa.

⚠️ No ejecutado localmente: MobSF no está instalado y estas reglas prohíben instalarlo. Toda la descripción procede del README oficial del proyecto y de sus metadatos en GitHub, consultados el 12 de agosto de 2026.

5.1 Por qué «marca el suelo en cero»

Es una observación de mercado, no técnica.

MobSF entrega, gratis y en una sola pasada: manifiesto analizado con permisos clasificados por peligrosidad, componentes exportados, certificado y esquema de firma, hallazgos sobre el código, cadenas y URL extraídas, dominios y su reputación, secretos embebidos, comprobaciones de configuración de red, y un informe navegable con puntuación.

Eso significa que cualquier producto que pretenda cobrar por escaneo estático básico está compitiendo con cero euros, y perdiendo. MobSF, jadx, apktool y Ghidra marcan ese suelo entre las herramientas gratuitas.

5.2 Dónde no llega

Que es la otra mitad del dato:

• No reporta el problema de las páginas de 16 KB. Desde el 1 de febrero de 2027 Google Play no admite actualizaciones sin ese soporte, y MobSF ni lo menciona.
• No correlaciona con la política de Play. Lee el targetSdk pero no dice si será rechazado.
• No hace merge de splits. Se le da un APK; un .xapk hay que fusionarlo antes.
• No informa de la cobertura de decompilación. El problema del 21 % de la sección 6.2 de Decompiladores a Java queda invisible.
• Es un servidor web con interfaz, no una CLI de primera clase. Automatizarlo se hace contra su API REST, no contra un binario.

6. APKiD

Consultado el 12 de agosto de 2026 vía la API de GitHub y el README del proyecto. Activo. La API reporta la licencia como NOASSERTION; el README declara el licenciamiento dual. ⚠️ sin verificar: no se ha podido leer el texto del fichero de licencia; las consultas devolvieron 404 y 403. El esquema dual procede del README, no del fichero legal.

Su lema lo resume: «PEiD for Android». Responde a una pregunta distinta de la del resto del documento: no qué hace la aplicación, sino cómo fue construida.

6.1 Cómo funciona

Reglas YARA aplicadas sobre los DEX y sobre los binarios nativos del APK. YARA busca patrones de bytes y de cadenas; APKiD aporta el catálogo de patrones que identifican a cada productor de esos bytes.

Lo que detecta:

• Compiladores: dx, d8, r8, dexlib (o sea, que el APK pasó por apktool o similar), dexmerge, y compiladores de terceros.
• Ofuscadores: DexGuard, Allatori, Zelix, obfuscapk y otros.
• Packers: Jiagu, Bangcle, SecNeo, Virbox y familias afines.
• Anti-análisis: anti-debug, anti-VM, anti-desensamblador, detección de emulador.
• Rarezas: manipulaciones del DEX que ninguna cadena de compilación legítima produce.

La huella más útil es la primera. Que el compilador salga como dexlib en vez de d8 significa que el APK fue reempaquetado, no compilado desde fuentes. Es un dato de primera línea para saber si se está mirando un binario original.

6.2 Uso

apkid app.apk
apkid -j app.apk                    # salida JSON
apkid -r -t 60 /ruta/con/apks/      # recursivo, con timeout de YARA

Opciones: -j/--json, -r/--recursive, -t TIMEOUT, --scan-depth para el anidamiento de ZIP, -o DIR para escribir a fichero y --typing para elegir cómo identifica los ficheros (magic, filename o none). Se instala con pip o se ejecuta en contenedor.

Salida de la forma:

[+] APKiD 3.1.0 :: from RedNaga :: rednaga.io
[*] app.apk!classes.dex
 |-> compiler : r8

⚠️ No ejecutado localmente: APKiD no está instalado. La sintaxis, las opciones y la forma de la salida proceden del README oficial, consultado el 12 de agosto de 2026.

6.3 El dato que relativiza los packers

Merece decirse aquí porque APKiD es la herramienta que lo mide: solo el 0,59 % de las aplicaciones de Google Play llevan packer detectable, frente a proporciones un orden de magnitud mayores en los mercados chinos. La cifra, con su fuente y sus tres avisos, está en la sección 6.1 de Packers y protectores. El estudio de decompilación de la sección 6 de Decompiladores a Java lo corrobora desde otro ángulo: APKiD detectó packer en 127 de 13.601 aplicaciones de Play y en 131 de 24.553 muestras de malware, y en ninguna de las 3.018 de F-Droid.

O sea: el packing es un problema real y poco frecuente en el ecosistema occidental. Es parte del argumento por el que desempaquetar packers comerciales queda fuera del alcance de este corpus — pozo sin fondo, riesgo legal y un 0,59 % de superficie.

El catálogo de familias y sus huellas está en Packers y protectores.

7. Análisis estático sobre el código recuperado

7.1 semgrep

Consultado el 12 de agosto de 2026 vía la API de GitHub. Muy activo, con commits del mismo día de la consulta.

Su propia descripción: «Lightweight static analysis for many languages. Find bug variants with patterns that look like source code». La idea es que la regla se escribe con la sintaxis del lenguaje analizado en vez de con una expresión regular:

rules:
  - id: cifrado-con-modo-ecb
    pattern: Cipher.getInstance("$ALGO/ECB/$PADDING")
    message: Modo ECB, que no oculta patrones en el texto cifrado
    languages: [java]
    severity: WARNING

Cómo encaja en Android: semgrep no lee DEX. Se ejecuta sobre el Java que produjo jadx, o sobre el smali si se escriben reglas para texto plano. Y de ahí sale su límite práctico: el Java de un decompilador es aproximado y no compila, así que las reglas que dependen de resolución de tipos van a rendir peor que sobre código fuente real. Para búsqueda de patrones sintácticos —llamadas a APIs concretas, constantes criptográficas, URLs— funciona bien.

jadx -d fuente/ --no-res app.apk
semgrep scan --config p/java fuente/

⚠️ No ejecutado localmente: semgrep no está instalado, y jadx tampoco. ⚠️ sin verificar: la página de inicio rápido de la documentación consultada no enumera los lenguajes soportados, así que no se ha podido confirmar el nivel de soporte de Kotlin. El soporte de Java sí está implícito en el uso establecido de la herramienta, pero no se ha verificado contra una lista oficial.

7.2 jadx en línea de órdenes dentro de un pipeline

jadx tiene CLI, y eso lo hace la pieza de entrada natural de cualquier automatización que necesite código:

app.apk ──jadx --no-res──▶ fuente/ ──semgrep / grep / analizador propio──▶ hallazgos

Tres cautelas, todas desarrolladas en Decompiladores a Java:

1. La decompilación es parcial y jadx no falla por ello. El código de salida no dice si el resultado está completo. Hay que contar los marcadores de fallo en la salida generada.
2. Ejecutarlo en subproceso con límite de memoria y timeout. Se cuelga con aplicaciones grandes.
3. Un hallazgo negativo no prueba nada si un 5 % de los métodos no decompiló.

7.3 Linters de seguridad

lint de Android Studio y los linters de Gradle operan sobre el proyecto fuente, no sobre el APK. Son útiles para quien construye la aplicación; no aplican al que analiza un binario ajeno, que es el lector de este corpus. Se mencionan para descartarlos explícitamente.

8. Análisis dinámico

Lo que ninguna herramienta estática ve: qué hace el proceso mientras corre.

8.1 Frida

Consultado el 12 de agosto de 2026 vía la API de GitHub y su fichero de licencia. Muy activo. La API reporta NOASSERTION porque la wxWindows Library Licence no es una de las licencias que GitHub reconoce automáticamente; el texto del fichero la identifica sin ambigüedad.

Qué es: un marco de instrumentación dinámica. Inyecta un motor de JavaScript en un proceso en ejecución y desde ahí permite interceptar llamadas a funciones —tanto de Java/Kotlin como nativas—, leer y escribir memoria, enumerar clases cargadas y trazar la ejecución.

Para qué se usa legítimamente, que es como se documenta aquí:

• Comprobar qué hace realmente una función cuando el análisis estático es ambiguo: se le pone un hook y se registran sus argumentos y su valor de retorno.
• Ver los datos antes de que se cifren y después de que se descifren, para entender un protocolo propietario en una auditoría autorizada.
• Enumerar clases y métodos cargados en ejecución, que es la única forma de ver el código que se carga dinámicamente.
• Trazar llamadas nativas cuando la lógica está en un .so y el análisis estático no basta.
• Investigación de malware: observar el comportamiento en un entorno controlado.

Todos esos usos presuponen autorización sobre la aplicación analizada. Frida es un depurador sofisticado y se documenta como tal.

8.2 objection

Consultado el 12 de agosto de 2026 vía la API de GitHub. Activo.

Se describe como «runtime mobile exploration». Es una capa por encima de Frida que convierte las operaciones habituales en órdenes de una consola interactiva, sin tener que escribir JavaScript: explorar el almacenamiento de la aplicación, listar actividades y servicios, volcar el keystore, inspeccionar bases de datos. Es el atajo para el trabajo rutinario de una auditoría; Frida directamente es lo que se usa cuando hace falta precisión.

⚠️ No ejecutado localmente: ni Frida ni objection están instalados, y no hay dispositivo Android conectado al entorno de referencia. Toda la descripción procede de los metadatos y las descripciones oficiales de ambos proyectos.

8.3 Emulador frente a dispositivo real

La fila de la detección es la que decide. Un emulador deja huellas abundantes —propiedades del sistema con valores goldfish/ranchu, ficheros de dispositivo característicos, IMEI y número de serie por defecto, ausencia de sensores— y comprobarlas es barato. La fila de la ABI tiene un efecto secundario que sorprende: una aplicación con código nativo solo para ARM sobre un emulador x86 se apoya en la traducción del emulador, cuando existe, y eso cambia el comportamiento y los tiempos.

La práctica establecida es emulador para lo repetible y dispositivo real para lo que se resiste.

8.4 Cuando la aplicación detecta el entorno de análisis

Es el problema estructural del análisis dinámico y hay que anticiparlo, porque se manifiesta como «la aplicación se cierra sola» o, peor, como «la aplicación funciona pero da datos distintos».

El repertorio de detección incluye anti-debug leyendo TracerPid de /proc/self/status, ptrace(PTRACE_TRACEME) sobre uno mismo, medición de tiempos, detección de root, detección de emulador, comprobaciones de integridad del propio APK y de su firma, y detección específica de Frida —el puerto por defecto, el hilo gum-js-loop, cadenas características en la memoria del proceso.

Este corpus documenta esas técnicas para reconocerlas, no para neutralizarlas. El catálogo completo, con las huellas de cada una, está en Anti-análisis y hardening.

La consecuencia metodológica es la que importa: si una aplicación detecta el entorno y cambia de comportamiento, el análisis dinámico deja de ser un oráculo fiable y hay que volver al estático, que no se puede engañar de la misma manera. Son técnicas complementarias, y la protección contra una es precisamente lo que hace valiosa a la otra.

9. Qué categoría cubre cada herramienta

●●● cobertura principal · ●● capacidad real · ● marginal · — no aplica

Y el orden por el que se atraviesan en un análisis de verdad:

1. APKiD          ¿cómo se construyó esto? ¿hay packer, ofuscador, reempaquetado?
        ▼
2. aapt2 / MobSF  ¿qué declara? permisos, componentes, firma, red
        ▼
3. jadx           ¿qué hace el código? — sabiendo que puede faltar un 5 %
        ▼
4. Ghidra / r2    ¿qué hace el .so? — si la lógica se fue ahí
        ▼
5. Frida          ¿qué hace de verdad? — si lo anterior no bastó

El paso 1 va primero por una razón concreta: si APKiD detecta un packer, los pasos 3 y 4 van a leer el stub y no la aplicación, y todo lo que se concluya de ahí será falso. Saberlo antes de empezar ahorra el análisis entero.

Fuentes

1. Ghidra — repositorio oficial — https://github.com/NationalSecurityAgency/ghidra Consultado el 12 de agosto de 2026 vía la API de GitHub y /releases/latest. De aquí salen la licencia Apache-2.0, la versión 12.1.2 del 5 de junio de 2026, la fecha de publicación como código abierto y los recuentos de la sección 2. La redirección de ghidra-sre.org a este repositorio se comprobó el mismo día.
2. Ghidra — soporte de formatos de fichero — https://nationalsecurityagency-ghidra.mintlify.app/processors/file-formats Consultado el 12 de agosto de 2026. De aquí sale íntegra la tabla de cargadores de la sección 2.2: ApkLoader.java, DexLoader.java con cobertura de KitKat a Android 12, CDexLoader.java para Compact DEX y el soporte de ODEX vía el procesador Dalvik.
3. radare2 — repositorio oficial — https://github.com/radareorg/radare2 Consultado el 12 de agosto de 2026 vía la API de GitHub y su endpoint /license. De aquí salen los recuentos y la declaración de COPYING.md de que la mayor parte del proyecto es LGPLv3 con dependencias y plugins bajo otras licencias.
4. rizin — repositorio oficial — https://github.com/rizinorg/rizin Consultado el 12 de agosto de 2026 vía la API de GitHub. De aquí salen la licencia LGPL-3.0, la fecha de creación de septiembre de 2020 que data la escisión, y los recuentos.
5. Cutter — repositorio oficial — https://github.com/rizinorg/cutter Consultado el 12 de agosto de 2026 vía la API de GitHub. De aquí salen la licencia GPL-3.0 y los recuentos de la sección 3.
6. IDA Pro — página oficial de Hex-Rays — https://hex-rays.com/ida-pro Consultado el 12 de agosto de 2026. De aquí salen las ediciones, los tipos de licencia, el recuento de desensambladores y decompiladores, y la ausencia de precios publicados.
7. MobSF — repositorio y README — https://raw.githubusercontent.com/MobSF/Mobile-Security-Framework-MobSF/master/README.md y https://github.com/MobSF/Mobile-Security-Framework-MobSF Consultados el 12 de agosto de 2026 vía la API de GitHub y el contenido en crudo. De aquí salen la licencia GPL-3.0, la versión v4.5.2 del 10 de agosto de 2026, los recuentos, la descripción de capacidades y las órdenes de Docker con sus credenciales por defecto.
8. APKiD — repositorio y README — https://raw.githubusercontent.com/rednaga/APKiD/master/README.md y https://github.com/rednaga/APKiD Consultados el 12 de agosto de 2026 vía la API de GitHub y el contenido en crudo. De aquí salen la versión v3.1.0 del 9 de abril de 2026, los recuentos, el esquema de licenciamiento dual, el funcionamiento con reglas YARA sobre DEX y nativos, y las opciones de la sección 6.2.
9. semgrep — repositorio oficial — https://github.com/semgrep/semgrep Consultado el 12 de agosto de 2026 vía la API de GitHub. De aquí salen la licencia LGPL-2.1, la fecha de creación y los recuentos de la sección 7.1.
10. semgrep — documentación, inicio rápido — https://docs.semgrep.dev/getting-started/quickstart Consultado el 12 de agosto de 2026. De aquí salen el modelo de licenciamiento con la plataforma comercial aparte y las órdenes semgrep scan y semgrep ci. Esta página no enumera los lenguajes soportados, lo que motiva la marca de no verificado sobre Kotlin.
11. Frida — repositorio y licencia — https://github.com/frida/frida y su endpoint /license en la API de GitHub Consultados el 12 de agosto de 2026. De aquí salen la wxWindows Library Licence 3.1 leída del propio fichero, la versión 17.17.0 del 5 de agosto de 2026 y los recuentos.
12. objection — repositorio oficial — https://github.com/sensepost/objection Consultado el 12 de agosto de 2026 vía la API de GitHub y /releases/latest. De aquí salen la licencia GPL-3.0, la versión 1.12.5 del 2 de junio de 2026 y los recuentos.
13. A Large-Scale Empirical Study of Android App Decompilation — Noah Mauthe, Ulf Kargén, Nahid Shahmehri. SANER 2021. https://www.ida.liu.se/~ulfka17/papers/SANER2021.pdf Consultado el 12 de agosto de 2026; PDF descargado y extraído con pdftotext. De aquí sale la tabla I con las detecciones de packer por APKiD citadas en la sección 6.3: 0 en F-Droid, 127 de 13.601 en Google Play y 131 de 24.553 en malware.
14. Documentos de este corpus — Packers y protectores (§6.1), de donde sale el 0,59 % de packers en Google Play de la sección 6.3 con su fuente original y sus avisos, y Alineación y zipalign, de donde sale la fecha del 1 de febrero de 2027 para el requisito de páginas de 16 KB de la sección 5.2.