Analizador APK

Suelta un paquete de Android —un archivo .apk— y lee lo que declara sobre sí mismo antes de que se acerque a un teléfono: su nombre de paquete y su versión, los niveles de SDK a los que apunta, cada permiso que solicita, si permite la depuración y las copias de seguridad, cuáles de sus componentes pueden alcanzar otras apps y con qué certificados está firmado. El archivo nunca sale de tu dispositivo: se abre y se analiza en esta página, no se sube, porque un APK del que sospechas es exactamente el archivo que no deberías entregar al servidor de un desconocido.

O suelta el archivo en cualquier parte de este recuadro. Todo lo siguiente se lee del propio paquete, en este dispositivo: el manifiesto, los recursos compilados y los bloques de firma.

Lo que un APK declara antes de ejecutar una línea de código

Un APK es un archivo ZIP con opiniones. Antes de que Android ejecute código alguno suyo, el sistema lee el AndroidManifest.xml binario que lleva dentro, y ese único archivo es una declaración de intenciones sorprendentemente completa. Nombra el paquete —la identidad contra la que se cotejan las actualizaciones— y su versión. Indica la versión de Android más antigua que la app dice admitir y aquella cuyas reglas de comportamiento sigue, y por eso importa el SDK objetivo: un objetivo bajo mantiene vivo, en silencio, el comportamiento de permisos antiguo y más laxo. Enumera cada permiso que la app podrá usar jamás, porque un permiso no declarado no puede concederse después. Dice si la compilación es depurable —un indicador que nunca debería sobrevivir a una versión de producción— y si sus datos pueden acabar en las copias de seguridad del dispositivo. E inventaría los componentes de la app: actividades, servicios, receptores y proveedores, cada uno con un estado de exportación que decide si otras apps del dispositivo pueden llamarlo. Un componente exportado sin comprobación de permisos es la superficie de ataque clásica de Android, y puedes verla aquí, en el manifiesto, sin instalar nada.

La otra mitad de la historia es la firma. Android solo instala una actualización sobre una app existente cuando ambas están firmadas con la misma clave, así que la huella del certificado del firmante es la continuidad de identidad de la app: el mismo nombre de paquete firmado con otra clave es otra app con una etiqueta familiar. Esta página lee ambas generaciones de firma —los certificados estilo Jar de META-INF y el bloque APK Signature Scheme v2/v3— y muestra el sujeto, el emisor, la ventana de validez y la huella SHA-256 de cada firmante, que el comparador de certificados y claves puede cotejar con una clave o un CSR que tengas. La guía complementaria, qué hay dentro de un APK antes de instalarlo, recorre toda la inspección como una lista de verificación. Dos límites honestos: esta página lee declaraciones, no comportamiento —no descompila código, no ejecuta la app ni juzga si es malware— y donde el propio manifiesto es ambiguo (un indicador exported omitido en un componente con intent-filter, una etiqueta que los recursos compilados no resuelven), lo dice en lugar de rellenar el hueco con una conjetura. Para lo que la app hace en la red una vez en marcha, el analizador PCAP lee la captura.

Preguntas frecuentes

¿Adónde va mi archivo APK?

A ninguna parte. El archivo se abre y se analiza en esta página, en tu dispositivo, y nada se sube, se transmite ni se almacena: analizar un archivo no hace ninguna petición de red. Aquí importa más que en la mayoría de las herramientas: los APK que más se quieren inspeccionar son los que ya despiertan desconfianza —un archivo de un foro, una descarga directa, una ficha de tienda que parece incorrecta— y enviar un binario sospechoso a un servicio de escaneo remoto es en sí mismo una exposición. También funciona sin conexión una vez cargada la página.

¿Qué debería comprobar antes de instalar un APK?

Cuatro cosas, todas visibles arriba. El nombre del paquete: ¿es el espacio de nombres real del editor o un imitador con un carácter cambiado? Los permisos: ¿una app de linterna necesita de verdad tus contactos, tu registro de llamadas y tu ubicación precisa, y hay alguna petición de nivel firma o especial disfrazada de rutinaria? Los componentes exportados: cada actividad, servicio, receptor o proveedor que otras apps pueden alcanzar es superficie que estás aceptando. Y el firmante: una actualización debe llevar el mismo certificado de firma que la app instalada, así que compara la huella SHA-256 con la copia en la que confías antes de instalar por fuera una «versión más nueva» de cualquier sitio.

¿Puede decirme si una app es malware?

No, y cualquier herramienta que lo prometa a partir de un manifiesto está vendiendo humo. Esta página lee lo que el paquete declara —identidad, permisos, componentes, indicadores y firmas—, lo que basta para atrapar a los descuidados y a los impostores: un clon con el firmante equivocado, una linterna que exige acceso a los SMS, una compilación de producción que quedó depurable. Juzgar lo que el código hace de verdad requiere descompilación, análisis dinámico o el veredicto de un escáner reputado sobre el propio binario. Trata un resultado limpio aquí como «nada de lo declarado parece mal», nunca como un certificado de seguridad.

¿Por qué algunos permisos dicen «no está en la tabla de referencia»?

Porque la honestidad gana a una conjetura plausible. Los niveles de protección mostrados —normal, peligroso, firma, especial— proceden de una tabla cuidada de los permisos android.* más conocidos y del nivel que el framework asigna a cada uno. Los proveedores añaden sus propios permisos, los fabricantes añaden más y las nuevas versiones de Android introducen nombres nuevos; ninguno de ellos está en la tabla, así que la página lo dice explícitamente. Un nivel desconocido no significa que el permiso sea inofensivo o peligroso: significa que esta referencia no lo cubre, y el nombre y el espacio de nombres del propio permiso son el lugar por donde empezar a comprobar.

¿Qué significa «exportado: no especificado»?

Significa que el manifiesto realmente no lo dice. Cuando un componente declara un intent-filter pero omite android:exported, la respuesta efectiva ha dependido del SDK objetivo de la app y de la versión de Android: las reglas antiguas exportaban esos componentes por defecto, y las nuevas se niegan a instalar la app hasta que el desarrollador lo decide. Un lector que imprimiera un sí o un no con total confianza estaría inventando un dato que el archivo no contiene, así que esta página informa de la omisión en sí. En tus propias compilaciones, es la fila que merece corregirse de forma explícita.