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 esta documentación 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 fue una limitación y ya no lo es. La issue #4276, «Android MultiDEX support», se abrió el 23 de mayo de 2022 y está cerrada desde el 31 de agosto de 2022. Consultado el 13 de agosto de 2026 con gh api repos/NationalSecurityAgency/ghidra/issues/4276. En una aplicación real la lógica está repartida entre classes.dex, classes2.dex y sucesivos, así que era una carencia importante mientras duró.
• La documentación que circula dice que la cobertura llega «hasta Android 12», pero DexConstants.java acepta de la 035 a la 040, que es todo lo que emite D8 («Formato DEX → §4 · magic y la tabla de versiones»). Fuera solo queda la 041, que es experimental.

⚠️ sin verificar: no se ha comprobado hasta qué punto el decompilador de Ghidra produce salida utilizable sobre bytecode Dalvik: Ghidra no está instalado en la máquina de referencia. La prueba pendiente es importar un classes.dex del «muestrario» con analyzeHeadless, decompilar todas sus funciones con DecompInterface y comparar cuántos métodos salen, y cómo, frente a jadx --no-res sobre el mismo fichero.

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.

Las extensiones de terceros que siguen publicadas son de la otra mitad del problema, el puente JNI del código nativo, y ninguna tiene commits en 2026. Búsqueda en la API de GitHub el 25 de septiembre de 2026 (ghidra con android, jni, dex, dalvik, apk, smali, oat y vdex, y los temas ghidra + android):

Para el DEX no apareció ninguna: lo que en 2026 se mueve bajo esos términos son servidores MCP y skills de agentes que llaman a Ghidra, no extensiones.

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. Consultado el 12 de agosto de 2026.

Los precios se publican en la página de tarifas, en suscripción anual: IDA Free es gratuita, IDA Home cuesta desde 365 €, e IDA Pro va de 1.099 € (Essential) a 8.599 € (Ultimate), con las Expert de 2, 4 y 6 decompiladores entre medias, desde 2.999 €. La OEM se negocia aparte. Consultado el 25 de septiembre 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. Como ancla de mercado, IDA eliminó la licencia perpetua en octubre de 2024, y la reacción documentada fue sustitución declarada por 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 en la máquina de referencia. 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. Es una de las trampas clásicas: MobSF, AppSweep, jadx, apktool y Ghidra marcan el suelo en cero, y cobrar ahí es regalarle usuarios al competidor gratuito.

5.2 Dónde no llega

Que es la otra mitad del dato:

• No reporta el problema de las páginas de 16 KB. La hoja de ruta lo señala explícitamente: 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, aunque acepta .xapk, .apks y .aab directamente (ALLOWED_EXTENSIONS en mobsf/MobSF/settings.py).
• No informa de la cobertura de decompilación. El problema del 21 % de la «sección 6.2 de Decompiladores a Java · El dato que de verdad importa» 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.

5.3 Androguard, la biblioteca de debajo

Consultado el 25 de septiembre de 2026 vía la API de GitHub y el README de la etiqueta v4.1.4. Activo.

Es una biblioteca de Python, con línea de órdenes, para leer y analizar APK sin salir de Python: DEX y ODEX, el XML binario, la tabla de recursos, desensamblado de bytecode Dalvik, referencias cruzadas y un decompilador propio, DAD. La CLI androguard expone subcomandos como axml, arsc, decompile, sign, apkid, disassemble y cg, que genera el grafo de llamadas.

Su lugar en este documento es debajo de otras herramientas: MobSF lleva una copia de su analizador de APK y AXML en mobsf/StaticAnalyzer/tools/androguard4/, con la licencia en LICENSES/androguard.txt, y su README cita a F-Droid Server, Quark-Engine y VirusTotal entre quienes lo usan. Para leer código, jadx decompila mejor; Androguard sirve cuando el análisis se escribe en Python y hace falta el modelo del APK como objetos.

La rama principal del repositorio ya es Androguard 5, que su README describe como distinta del paquete de PyPI y todavía sin publicar: quien instale con pip obtiene la 4.1.4.

⚠️ No ejecutado localmente: Androguard no está instalado en la máquina de referencia.

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 porque no hay un LICENSE en la raíz; el licenciamiento dual está en dos ficheros aparte, LICENSE.GPL —la GPL versión 3— y LICENSE.COMMERCIAL, leídos el 24 de septiembre de 2026.

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

Instalado con pip3 install --user apkid y ejecutado el 13 de agosto de 2026 sobre los 58 APK standalone del muestrario y los 23 base.apk de sus contenedores: 387 entradas escaneadas contando cada classes*.dex. Un aviso sobre la CLI, que el README no dice: no tiene opción de versión. -v es --verbose, y pasarle --version es un error de argumentos; la versión sale en la cabecera de apkid -h («APKiD - Android Application Identifier v3.1.0»).

El reparto de etiquetas sobre esas 387 entradas:

Cero packers y cero protectores sobre 81 aplicaciones, incluidas Netflix, WhatsApp, Snapchat y cuatro juegos comerciales. La lectura completa de ese resultado —y las dos limitaciones serias que destapa— está en la «sección 7.1 de Ofuscadores comerciales · Lo que APKiD encuentra, y lo que no». En resumen: APKiD no identifica a DexGuard en la única muestra protegida con DexGuard, y su regla Resources Confusion dispara en 54 de las 58 aplicaciones limpias de F-Droid.

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 al 40-43 % en los mercados chinos. El estudio de decompilación de la «sección 6 de Decompiladores a Java · La comparación honesta: qué dicen las mediciones» 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 esta documentación — 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. La lista oficial no está en la página de inicio rápido sino en la de lenguajes de Semgrep CE, que separa los dos productos (docs/semgrep-ce-languages.mdx del repositorio semgrep/semgrep-docs, consultado el 25 de septiembre de 2026). En Semgrep Code, el comercial, Java y Kotlin son Generally available, con flujo de datos entre ficheros; en Semgrep CE, el LGPL de la ficha de arriba, los dos son Community supported: análisis limitado a una sola función, reglas de la comunidad y un análisis sintáctico con los requisitos de los lenguajes Experimental. Kotlin no está por debajo de Java en ninguno de los dos; lo que baja es el motor libre frente al de pago.

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 solo lo avisa en parte. Devuelve 3 cuando algún método no se pudo decompilar —y lo hace hasta con Termux, sin ofuscar—, pero un 0 no garantiza un código correcto. 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 esta documentación. 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.

Aquí se documentan 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 12.1.4, del 21 de septiembre, se consultó el 25 de septiembre), la fecha de publicación como código abierto y los recuentos de la «sección 2 · Ghidra». 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 · El soporte de DEX y APK, que ya viene de serie»: ApkLoader.java, DexLoader.java, CDexLoader.java para Compact DEX y el soporte de ODEX vía el procesador Dalvik. Es documentación generada automáticamente, no de la NSA: su «de KitKat a Android 12» se ha corregido con el código (fuente 15).
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 · radare2, rizin y Cutter».
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 y el recuento de desensambladores y decompiladores.
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 (la v4.5.3, del 21 de septiembre, se consultó el 25 de septiembre), 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 · Uso».
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 · semgrep».
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: la lista está en la fuente 20.
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 (la 17.18.0, del 9 de septiembre, se consultó el 25 de septiembre) 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 · El dato que relativiza los packers»: 0 en F-Droid, 127 de 13.601 en Google Play y 131 de 24.553 en malware.
14. NationalSecurityAgency/ghidra, issue #4276 — https://github.com/NationalSecurityAgency/ghidra/issues/4276 Consultada el 13 de agosto de 2026 con gh api. «Android MultiDEX support», abierta el 23 de mayo de 2022 y cerrada el 31 de agosto de 2022. Corrige la «sección 2.2 · El soporte de DEX y APK, que ya viene de serie», que la daba por abierta.
15. Ghidra — DexConstants.java — https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/FileFormats/src/main/java/ghidra/file/formats/android/dex/format/DexConstants.java Consultado el 24 de septiembre de 2026. Define las versiones de DEX de la 035 a la 040 que lee Ghidra («sección 2.2 · El soporte de DEX y APK, que ya viene de serie»).
16. Androguard — repositorio, README y CLI — https://github.com/androguard/androguard Consultado el 25 de septiembre de 2026 vía la API de GitHub, /releases/latest, el README y androguard/cli/cli.py de la etiqueta v4.1.4, y el README de la rama principal. De aquí salen la licencia Apache-2.0, la versión v4.1.4 del 5 de junio de 2026, los recuentos, las capacidades, los subcomandos y el estado de Androguard 5 de la «sección 5.3 · Androguard, la biblioteca de debajo».
17. MobSF — árbol del repositorio — https://github.com/MobSF/Mobile-Security-Framework-MobSF/tree/master/mobsf/StaticAnalyzer/tools/androguard4 Consultado el 25 de septiembre de 2026 vía la API de GitHub. De aquí sale la copia de Androguard que lleva MobSF, de la «sección 5.3 · Androguard, la biblioteca de debajo».
18. IDA — tarifas de Hex-Rays — https://hex-rays.com/pricing Consultado el 25 de septiembre de 2026. De aquí salen los precios anuales de la «sección 4 · IDA Pro».
19. Extensiones de Ghidra para Android — búsqueda en la API de GitHub — https://github.com/evilpan/jni_helper, https://github.com/Ayrx/JNIAnalyzer, https://github.com/extremecoders-re/ghidra-jni y https://github.com/LAripping/NativeEnrich Consultada el 25 de septiembre de 2026 con gh api search/repositories (ghidra con android, jni, dex, dalvik, apk, smali, oat y vdex, y los temas ghidra + android); las estrellas y la fecha del último commit de cada repositorio, con gh api repos/… y repos/…/commits. De aquí sale la tabla de la «sección 2.3 · Extensiones».
20. Semgrep — lenguajes de Semgrep CE — https://docs.semgrep.dev/semgrep-ce-languages (fuente: docs/semgrep-ce-languages.mdx en https://github.com/semgrep/semgrep-docs) Consultado el 25 de septiembre de 2026. De aquí salen los niveles de Java y Kotlin en Semgrep Code y en Semgrep CE, y la definición de Community supported, de la «sección 7.1 · semgrep».