Análisis de APK:

desempaquetar, leer el manifiesto y seguir el flujo

Malware y Reversing  |  unfantasmaenelsistema.com

Una aplicación Android es, por dentro, un archivo ZIP con una estructura fija. Dentro viven el manifiesto que declara permisos y componentes, el bytecode compilado en formato DEX, los recursos, las librerías nativas y la firma que garantiza que nadie ha tocado el paquete después de construirlo. Con herramientas gratuitas se puede abrir ese envoltorio, recuperar un código Java o Kotlin muy legible y entender qué hace la app sin instalarla en ningún teléfono.

Este artículo recorre el APK de fuera hacia dentro con la mirada de quien hace triaje: qué contiene cada pieza, cómo leer el manifiesto para localizar la superficie de ataque, cómo pasar de DEX a código fuente con jadx, qué comportamientos levantan sospecha y cómo montar un entorno de análisis aislado. Todos los ejemplos son de lectura: inspeccionar el paquete, nunca modificarlo ni ejecutar la muestra fuera de un laboratorio sin salida a la red.

1. Qué hay dentro de un APK

Un APK (Android Package) es un ZIP con la extensión cambiada. Descomprimirlo con cualquier utilidad de archivo deja a la vista una estructura estándar. Un AAB (Android App Bundle) es el formato que se sube a Google Play: no se instala directamente, sino que Play genera APK optimizados por dispositivo a partir de él; para el análisis se suele trabajar con el APK universal que se puede extraer del bundle con bundletool.

1.1 La firma del paquete

Android exige que todo APK vaya firmado. El esquema v1 (JAR signing) firmaba fichero a fichero dentro de META-INF y dejaba margen para manipular el ZIP; v2 (Android 7) firma el archivo completo como un bloque; v3 (Android 9) añade rotación de clave; v4 acompaña con una firma incremental en un fichero aparte. Verificar la firma con apksigner verify –verbose dice qué esquemas están presentes y qué certificado firma. La firma garantiza integridad y continuidad del firmante entre actualizaciones, no que la app sea legítima: cualquiera genera un certificado autofirmado, y hay familias de malware que reutilizan el mismo certificado en decenas de muestras, lo que a su vez sirve para agruparlas.

2. Desempaquetar: apktool y el manifiesto

El AndroidManifest.xml de un APK no es texto: es XML en un formato binario propio. Para leerlo hay que decodificarlo. apktool d muestra.apk hace dos cosas: reconstruye el manifiesto y los recursos a XML legible, y desensambla el DEX a smali, la representación textual del bytecode Dalvik. El smali es verboso pero fiel; sirve cuando la decompilación a Java falla o cuando hay que ver instrucciones exactas.

# Desempaquetado y lectura de metadatos. Ninguna de estas ordenes ejecuta la app.
apktool d -o muestra_out muestra.apk        # manifiesto + recursos + smali
 
# Metadatos rapidos sin desempaquetar del todo:
aapt dump badging muestra.apk               # package, versiones, permisos, features
aapt dump permissions muestra.apk           # solo la lista de permisos
apksigner verify --verbose --print-certs muestra.apk   # esquema de firma y certificado
unzip -l muestra.apk                         # inventario de ficheros del paquete

Con el manifiesto ya en claro, la lectura sigue un orden fijo: package y versiones; uses-sdk (un targetSdk bajo relaja comprobaciones modernas del sistema); la lista de uses-permission; y el bloque de componentes — activities, services, broadcast receivers y content providers — prestando atención a cuáles son accesibles desde otras apps.

2.1 Permisos peligrosos

Android clasifica los permisos por nivel de protección. Los dangerous son los que dan acceso a datos o funciones sensibles y requieren consentimiento explícito en tiempo de ejecución. No hay permiso «malicioso» en sí mismo — una app de mensajería legítima pide SMS y contactos — pero el conjunto pedido debe encajar con lo que la app dice ser. Una supuesta linterna que pide SMS, accesibilidad y administración del dispositivo no cuadra.

2.2 Componentes exportados

Un componente está exportado cuando otra aplicación del dispositivo puede invocarlo. Lo está de forma explícita con android:exported=»true», o de forma implícita si declara un intent-filter y no lo desmiente (desde Android 12 hay que declararlo siempre). Cada componente exportado es una entrada a la app que hay que revisar: un content provider exportado sin permisos puede filtrar la base de datos interna; un service exportado puede ejecutar acciones privilegiadas por encargo de un tercero; un broadcast receiver exportado puede recibir eventos falsificados. En el análisis se listan todos, se marca cuáles no deberían ser públicos y se sigue su código.

3. De DEX a código legible: jadx

El código de la app está compilado en DEX (Dalvik Executable), un formato de bytecode diseñado para dispositivos con poca memoria: un solo fichero agrupa todas las clases. jadx decompila DEX directamente a Java (con soporte razonable para reconstruir patrones de Kotlin) y ofrece una interfaz — jadx-gui — con árbol de clases, búsqueda global, navegación por referencias y decompilado del manifiesto ya decodificado. Para automatizar, jadx en línea de comandos vuelca todo el proyecto a ficheros .java.

# Decompilacion a codigo fuente. Lectura: genera .java, no toca la muestra.
jadx -d muestra_src muestra.apk             # vuelca todo el proyecto
jadx-gui muestra.apk                        # exploracion interactiva
 
# Alternativa clasica en dos pasos:
d2j-dex2jar muestra.apk -o muestra.jar      # DEX -> JAR (dex2jar)
#   y abrir muestra.jar en un visor de bytecode Java

Con el código delante, el flujo se sigue desde los puntos de entrada, no leyendo de arriba abajo. Los puntos de entrada de una app Android son: la clase Application (su onCreate corre antes que nada), la activity de lanzamiento, los services y receivers declarados en el manifiesto, y cualquier callback de bibliotecas (push, jobs programados). Desde ahí se navega por llamadas hacia las zonas interesantes: red, ficheros, criptografía, reflexión, telefonía.

4. Comportamientos que levantan sospecha

El análisis estático no demuestra intención, pero ciertos patrones concentran el riesgo y marcan por dónde seguir. Ninguno es concluyente por sí solo — hay usos legítimos de casi todos — así que se valoran en conjunto y contra lo que la app dice hacer.

5. Análisis dinámico en entorno aislado

Cuando el estático deja preguntas — y con carga dinámica o cifrado de cadenas las deja siempre — toca ejecutar la muestra de forma controlada. La regla es no instalarla nunca en un teléfono personal ni con la SIM puesta. Un emulador (Android Virtual Device, Genymotion) sobre una máquina sin credenciales, con la red enrutada a un proxy de inspección o directamente cortada, permite observar sin exponer nada.

• Emulador dedicado: imagen limpia, sin cuentas, snapshot para revertir tras cada ejecución.
• Red: sin salida, o a través de un proxy con certificado propio para ver el tráfico TLS que la app no fije; si hay certificate pinning, se documenta y se decide si merece esfuerzo saltarlo en el lab.
• Observación: logcat filtrado por el paquete, monitor de ficheros y de conexiones, y volcado de los DEX que se carguen en tiempo de ejecución para decompilarlos aparte.
• Instrumentación: Frida sobre el emulador para registrar llamadas a APIs de SMS, cripto y reflexión, y para recuperar cadenas ya descifradas en memoria.
• Nunca un dispositivo físico de uso real; si hace falta hardware, un terminal de laboratorio reservado para esto, sin SIM y con borrado entre muestras.

5.1 MobSF para el primer barrido

MobSF (Mobile Security Framework) automatiza casi todo lo anterior: sube el APK y devuelve manifiesto decodificado, permisos clasificados, componentes exportados, hallazgos en el código (criptografía débil, secretos, WebView inseguro), dominios y URLs extraídos, estado de la firma y una puntuación orientativa. Su análisis dinámico usa un emulador que hay que tener configurado. Es un excelente punto de partida para priorizar, pero sus hallazgos se revisan a mano: marca verdaderos y falsos positivos con la misma seguridad aparente.

6. Herramientas de referencia

Un triaje de APK en diez minutos: hash y verificación de firma; aapt dump badging para package y permisos; apktool d y lectura del manifiesto marcando permisos peligrosos y componentes exportados; jadx y recorrido del flujo desde los puntos de entrada; strings sobre DEX, recursos y librerías nativas buscando URLs y claves; y comprobación de carga dinámica, reflexión y servicios de accesibilidad. Con eso se decide si la muestra pasa a análisis dinámico en emulador o a un informe.

Conclusión

Un APK es un ZIP con una estructura conocida, y esa estructura entrega gran parte del análisis gratis: el manifiesto declara permisos y componentes exportados, el DEX se decompila a código muy legible con jadx, y las cadenas de recursos y librerías nativas suelen guardar URLs y claves en claro. Antes de ejecutar nada se puede describir la superficie de ataque de la app y formular una hipótesis sobre lo que hace.

El método que rinde es siempre el mismo: verificar la firma, leer el manifiesto marcando permisos peligrosos y componentes públicos, seguir el flujo desde los puntos de entrada, buscar patrones de riesgo — SMS premium, accesibilidad, carga dinámica de DEX, ofuscación hecha a mano — y solo entonces, si quedan preguntas, bajar a un emulador aislado o a MobSF. La muestra no se instala jamás en un teléfono real.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)