Qué hay dentro de un APK antes de instalarlo

Un APK es un archivo zip con una declaración adjunta. Antes de que Android ejecute una sola línea de su código, el paquete ya afirma quién dice ser, qué versiones de Android admite, qué quiere permiso para hacer, qué partes suyas pueden invocar otras apps y quién lo firmó. Nada de eso exige instalar nada. Leerlo primero convierte un acto de fe en una inspección de diez minutos, y esa inspección suele bastar para decidir.

Por qué un APK instalado manualmente merece una mirada previa

Las apps de una tienda oficial llegan con una ficha, un historial de reseñas y una página del editor. Un APK descargado por fuera — de un sitio de un proveedor, un espejo, un foro, un mensaje de chat o una copia antigua — no trae nada de ese contexto, y el aviso de instalación no lo sustituye. El instalador de Android muestra el nombre y el icono, y los permisos aparecen tarde, agrupados y simplificados, justo en el momento en que menos probable es que te detengas a pensar. Cuando una app ya está instalada y se ha abierto una vez, puede que ya tenga los permisos concedidos y haya usado la red. El momento barato para hacer preguntas es antes, cuando el archivo todavía es solo un archivo.

Esto no es un argumento contra la instalación manual en sí. Los proveedores distribuyen apps legítimas directamente, las empresas despliegan así herramientas internas y las versiones antiguas a veces resuelven problemas reales. Es un argumento a favor de leer lo que te entregaron. El analizador de APK de este sitio analiza el paquete en tu navegador — el archivo nunca se sube ni se ejecuta — y presenta el manifiesto, los permisos, los componentes y el certificado de firma en una sola vista. Uses la herramienta que uses, mantén ese orden: primero inspeccionar, después instalar, y trata cualquier app que no supere la inspección como una respuesta en sí misma.

El manifiesto es la propia declaración de la app

Cada APK lleva un AndroidManifest.xml, almacenado en XML binario, y es la declaración de la app sobre sí misma. Nombra el paquete — la identidad única que usa Android, como com.example.app — junto con un versionCode numérico y un versionName legible. Declara los componentes que contiene la app, los permisos que solicita y las funciones de hardware y software que espera. Como Android hace cumplir buena parte de este archivo, es más difícil de falsear a la ligera que una ficha de tienda o una página de descarga: una app no puede usar en silencio un permiso que nunca declaró, ni fingir ser la actualización de un paquete cuyo nombre no comparte.

Dos números del manifiesto dicen mucho sobre el mantenimiento. El minSdkVersion es el Android más antiguo en el que funcionará la app; un suelo muy bajo implica compatibilidad con dispositivos y modelos de seguridad de hace muchos años, a veces necesaria y a veces simplemente heredada y olvidada. El targetSdkVersion es el nivel de comportamiento de Android que la app afirma seguir. Google eleva cada año el objetivo exigido para actualizar en la tienda, porque un objetivo más alto somete la app a reglas de privacidad y seguridad más recientes. Un APK con un objetivo de hace varios años no es automáticamente malicioso, pero te está diciendo que evitó, o nunca cumplió, esas reglas nuevas, y deberías preguntar por qué.

Los permisos, leídos como es debido

Android clasifica los permisos, y la clase importa más que el nombre. Los permisos normales se conceden automáticamente al instalar — el acceso a la red es el ejemplo familiar — porque el sistema los juzga de bajo riesgo. Los permisos peligrosos cubren datos y acciones sensibles como contactos, mensajes, ubicación precisa, micrófono y cámara; necesitan un aviso en tiempo de ejecución que el usuario puede rechazar. Los permisos de firma solo se conceden a apps firmadas con el mismo certificado, o al propio sistema, así que una app de terceros que declare uno no gana nada con ello. Al leer una lista de permisos, ordénala mentalmente en esos grupos antes de juzgar cualquier línea.

El contexto es el veredicto, no la cantidad. Una linterna que pide leer SMS no tiene ninguna razón honesta para ello; una app de mensajería que pide el mismo permiso al menos puede explicarse: leer un código de verificación u ofrecerse como app de mensajes predeterminada. Una app bancaria puede solicitar legítimamente muchos permisos, mientras que un juego sencillo que pide solo unos pocos podría incluir justo el que no encaja. Así que no puntúes las apps solo por el número de permisos. Pregunta, para cada permiso peligroso, qué función de esta app dejaría de funcionar sin él. Las solicitudes que no puedes relacionar con una función son el hallazgo, y son exactamente lo que oculta el resumen de instalación.

Componentes exportados y la superficie de ataque que crean

Una app se compone de componentes — actividades (pantallas), servicios, receptores de difusión y proveedores de contenido — y el manifiesto indica cuáles están exportados, es decir, son alcanzables por otras apps del dispositivo. Los componentes exportados no son un error por defecto: un destino para compartir, un abridor de archivos y un enlace profundo funcionan porque un componente se exporta a propósito, protegido y, en el Android moderno, declarado de forma explícita. El riesgo está en los componentes exportados que nunca debieron ser una puerta pública: un servicio que cualquier app puede iniciar, un receptor que cualquiera puede activar o un proveedor que entrega los datos de la app a quien los pida, sin ninguna comprobación de permisos delante.

Dos indicadores del manifiesto merecen una mirada directa en cualquier app de producción. Una aplicación marcada como depurable puede ser inspeccionada por herramientas en una máquina conectada; eso es un ajuste de desarrollo, y distribuirlo activado es una señal de alarma sobre cómo se construyó la versión. Permitir copias de seguridad significa que los datos privados de la app pueden incluirse en las copias del dispositivo, lo que puede ser cómodo y también puede mover datos que creías dentro de la app a un lugar mucho menos controlado. Ningún indicador prueba que una app sea dañina. Ambos son baratos de comprobar, difíciles de justificar en un producto acabado y exactamente el tipo de detalle que nunca aparece en una página de descarga.

Certificados de firma: el sistema de identidad de Android

Cada APK está firmado, y el certificado de firma es lo más parecido a un documento de identidad que tiene Android. Android solo instalará una actualización sobre una app existente cuando ambas copias compartan el mismo nombre de paquete y el mismo firmante. Esa única regla hace mucho trabajo silencioso: significa que un extraño no puede enviar una actualización troyanizada de una app en la que ya confías, porque no posee la clave original, y significa que la huella del certificado — mostrada normalmente como un resumen SHA-256 — es la forma práctica de comprobar la continuidad. Si un proveedor publica una huella esperada, compárala. El comparador de certificados y claves de este sitio cubre la misma lógica de huellas para certificados y claves en general.

Ten claro qué prueba y qué no prueba una huella. Prueba que este archivo fue firmado por quien posee una clave privada concreta, y que coincide — o no — con otro archivo firmado con la misma clave. No prueba que el titular de la clave sea honesto, competente o siquiera la empresa nombrada en los campos de sujeto del certificado, que rellena el propio firmante. Una app reempaquetada suele estar firmada con un certificado distinto del original, por lo que una huella que no coincide es una fuerte señal de parada; una huella coincidente es solo una señal de continuidad. La identidad en Android es continuidad de la clave, nada más: trátala como tal.

Una lista de comprobación antes de instalar

Junta las piezas en un orden fijo y la inspección lleva minutos. Primero, identidad: ¿coincide el nombre del paquete con la app que esperabas, y son plausibles el código y el nombre de versión para la edición que querías descargar? Segundo, mantenimiento: ¿qué antigüedad tienen los niveles mínimo y objetivo de SDK, y encaja eso con una app todavía cuidada? Tercero, permisos: enumera los peligrosos y relaciona cada uno con una función, deteniéndote en cualquiera que no puedas explicar. Cuarto, superficie: ¿qué componentes están exportados, y están activados el modo depurable y las copias? Quinto, firma: ¿coincide la huella del certificado con el valor declarado por el editor, o al menos con la copia en la que ya confías? Pasa el archivo por el analizador de APK y recorre esa lista en una sola pantalla.

Después decide en tres grupos, no en dos. Instala, cuando todo se relaciona con una función y la huella cuadra. Instala con cautela — en un dispositivo de prueba, en un perfil de trabajo o sin conceder los permisos dudosos — cuando casi todo encaja pero un punto necesita vigilancia. O aléjate, cuando el nombre del paquete es incorrecto, la huella no coincide o un permiso peligroso no tiene ninguna función imaginable detrás. Alejarte cuesta una descarga; la otra dirección puede costar una cuenta. Y mantén el hábito en proporción: esto es triaje, como los primeros diez minutos con el analizador de capturas de paquetes: una lectura rápida y honesta de lo que un archivo declara sobre sí mismo, hecha antes de darle un lugar en el dispositivo que llevas a todas partes.

Preguntas frecuentes

¿Un manifiesto limpio significa que un APK es seguro?

No. El manifiesto es una declaración, no un informe de comportamiento. Una app puede declarar un conjunto modesto y totalmente plausible de permisos y componentes y aun así comportarse mal en el código: conectándose a servidores, abusando de los permisos que le fueron concedidos legítimamente o descargando un comportamiento nuevo tras la instalación. Leer el manifiesto es triaje: detecta identidades que no coinciden, permisos inexplicables, componentes expuestos y certificados de firma incorrectos de forma rápida y barata. No es un veredicto de malware, y cualquier herramienta que convierta la lectura de un manifiesto en un sello verde de «seguro» está afirmando más de lo que la evidencia sostiene.

¿Por qué la misma app muestra permisos distintos en herramientas distintas?

Normalmente por tres razones legítimas. Primero, la limitación por versión: un permiso puede llevar un maxSdkVersion, de modo que solo se aplica hasta cierto nivel de Android, y las herramientas difieren en si muestran esas entradas. Segundo, la agrupación: Android presenta los permisos por grupos al preguntar, mientras que el manifiesto enumera permisos individuales, así que la vista agrupada parece más corta que la lista completa. Tercero, la fusión: las bibliotecas incluidas en la app aportan sus propias entradas de manifiesto, que la compilación fusiona en el archivo final, de modo que el manifiesto instalado puede contener permisos que ninguna parte del código propio de la app declaró jamás. Las diferencias son un motivo para mirar qué razón se aplica, no una prueba automática de manipulación.

¿Puedo comprobar un APK sin instalar nada?

Sí: ese es el sentido de un analizador local en el navegador. El APK se analiza como archivo: su manifiesto binario se decodifica, sus recursos se leen en busca de etiquetas y textos, y sus certificados de firma se extraen y se les calcula la huella. El código de la app nunca se ejecuta, no se instala nada en ningún dispositivo y, con el analizador de este sitio, el archivo tampoco se sube nunca: el análisis ocurre en la pestaña de tu navegador. Si un servicio de comprobación te pide subir un APK a un servidor, pregúntate si ese archivo — que puede ser una compilación interna — pertenece siquiera a la máquina de otra persona.