御盾Conclusiones y condiciones de decisión.
- La instalación exitosa, la verificación exitosa de la firma y la identidad del editor oficial son tres juicios distintos; los dos primeros no pueden sustituir al tercero.
- Los paquetes vueltos a firmar normalmente no pueden superponer una versión oficial instalada bajo una identidad de firma diferente; la cadena de actualización es una puerta crítica para identificar artefactos anómalos.
- El APK final debe fijar el nombre del paquete, la versión, el resumen del certificado, el resumen del archivo, el origen de la compilación y el orden de procesamiento del canal.
- El servidor debe mantener una lista blanca de versiones e identidades de aplicación permitidas, tratando las señales de integridad de la plataforma como entradas de riesgo en lugar de confiar en los datos autoinformados por el cliente.
Distinguir entre validación de instalación, identidad de firma y autorización comercial
Android requiere que los APK estén firmados. El sistema verifica si la estructura del paquete del instalador y los datos de la firma demuestran que el contenido actual fue firmado por la clave privada correspondiente. Si un atacante modifica archivos DEX, recursos o el Manifiesto y luego vuelve a firmar completamente el resultado con su propia clave, el nuevo paquete puede ser criptográficamente coherente consigo mismo y cumplir las condiciones para una instalación nueva.
Este resultado solo responde si el paquete actual tiene una firma verificable; no responde si el firmante es el editor oficial. La autorización de marca, los canales legítimos, los permisos de inicio de sesión de cuenta y el acceso a interfaces de alto riesgo son preocupaciones comerciales que la aplicación y el servidor deben evaluar por separado.
Por lo tanto, los informes de prueba no deben equiparar "instalable tras volver a firmar" con "fallo en la protección de firma", ni equiparar "fallo en la instalación" con "todos los riesgos de reempaquetado cerrados". Las preguntas correctas son: ¿Puede el paquete modulado llegar a los dispositivos de los usuarios? ¿Puede hacerse pasar por la versión oficial durante una actualización? ¿Puede conectarse a servicios reales? ¿Y cómo identifica y gestiona el servidor estos casos?
| Juicio | Pregunta respondida | Evidencia requerida | Conclusión que no puede extrapolarse |
|---|---|---|---|
| Paquete analizable | ¿Puede el instalador leer la estructura del archivo? | Resultado del instalador, Manifiesto y estructura de recursos | No prueba la legitimidad de la firma ni la seguridad del código |
| Firma actual coherente consigo misma | ¿Está el contenido actual firmado por la clave privada correspondiente al certificado actual? | Verificación del esquema de firma y resumen del certificado | No prueba que el certificado pertenezca a la entidad oficial |
| Continuidad de identidad en la actualización | ¿Puede superponer una aplicación oficial ya instalada? | Ejecución de una actualización desde una versión genuina en producción | No prueba que todas las interfaces comerciales rechacen clientes anómalos |
| Autorización comercial aprobada | ¿Permite el servidor que la cuenta y la versión accedan a los recursos? | Políticas del lado del servidor sobre versión, cuenta, integridad y comportamiento | No garantiza que el código del cliente sea inmune al análisis o a la modificación |
Por qué los paquetes vueltos a firmar a menudo solo permiten una instalación nueva
Android utiliza la identidad de firma de la aplicación para mantener la continuidad de las actualizaciones. Cuando una aplicación instalada acepta una actualización superpuesta, la plataforma debe confirmar que la nueva versión cumple con las reglas de identidad de firma respecto a la versión existente. Un paquete modificado firmado con un certificado no relacionado generalmente no puede superponerse directamente a la versión oficial; requiere desinstalar primero la app oficial, cambiar el nombre del paquete o inducir al usuario a instalarla en un entorno separado.
Por esto, las pruebas de reempaquetado deben ejecutar tanto instalaciones limpias como actualizaciones superpuestas. Probar solo instalaciones limpias omite las verificaciones de continuidad de firma, mientras que probar solo actualizaciones superpuestas pasa por alto rutas donde paquetes falsificados entran al dispositivo mediante nombres de paquete diferentes o ciclos de desinstalación y reinstalación. Los resultados de ambos escenarios deben registrarse por separado.
La rotación de firmas y Play App Signing añaden complejidad a la cadena de lanzamiento. Los equipos deben preservar las identidades de certificado actuales e históricamente permitidas, las reglas de rotación y las responsabilidades de las claves de carga frente a las claves de firma de aplicaciones. Las políticas del lado del servidor deben usar datos que coincidan con el método de distribución. Los certificados de desarrollo, los certificados de carga y los certificados de distribución final nunca deben confluirse en un único campo.
- Ejecutar actualización superpuesta desde la versión en vivo actual
- Realizar instalación limpia tras la desinstalación
- Verificar cambios en el nombre del paquete e impactos en el directorio de datos
- Validar la rotación de certificados contra las reglas de la plataforma de distribución
La gobernanza de reempaquetado debe comenzar con la identidad del artefacto final
Los equipos suelen guardar solo el número de compilación, neglectando registrar el digesto de archivo y el digesto del certificado de firma del APK final. La inyección de recursos de canal, realineación, re-firma u optimización de paquetes pueden alterar el archivo final. Si el escaneo de seguridad analiza artefactos previos al canal, los archivos recibidos por los usuarios en vivo no están cubiertos por la misma evidencia.
Recomendamos generar registros de artefactos inequívocos para cada candidato de lanzamiento: nombre del paquete, versionCode, versionName, SHA-256 del archivo, SHA-256 del certificado, resultado de verificación del esquema de firma, origen de compilación, canal, orden de procesamiento y marca de tiempo de generación. Las comprobaciones estáticas, las actualizaciones de instalación, las pruebas de regresión funcional y las reglas de permiso del lado del servidor deben hacer referencia a este registro.
Los digestos de archivo no son medidas de protección en sí mismos; su valor radica en evitar que el objeto de prueba cambie silenciosamente durante el flujo de trabajo. Cualquier cambio en el digesto, la firma o la secuencia del canal indica un nuevo release candidate, lo que requiere volver a ejecutar las puertas afectadas.
artifact:
package: com.example.redacted
version_code: 240
version_name: 2.4.0
sha256: REDACTED
signing:
certificate_sha256: REDACTED
schemes: [v2, v3]
distribution: managed-channel
pipeline:
- build-release
- harden-candidate
- channel-resources
- final-sign
acceptance:
install_fresh: required
upgrade_from_production: required
server_policy_check: requiredLos servidores deben tratar a los clientes anómalos como un problema de política
Los clientes pueden reportar nombres de paquete, versiones, certificados o materiales de integridad, pero los clientes modificados también pueden manipular estos campos de reporte estándar. Los servidores deben priorizar señales verificables, combinando el estado de la cuenta, la versión, el comportamiento de la solicitud, el riesgo del dispositivo y el entorno de distribución en una política, en lugar de confiar en un único booleano reportado por el cliente.
Play Integrity puede devolver veredictos sobre reconocimiento de aplicaciones, integridad del dispositivo, licencias de cuenta y riesgo ambiental. La documentación oficial señala que ciertas señales pueden no estar disponibles debido a la versión del SO, el factor de forma del dispositivo, la fuente de distribución, el estado de Play Services o la configuración. El enfoque correcto es modelar por separado los estados de 'no disponible', 'fallo' y 'alto riesgo', preparando estrategias para degradación, verificación secundaria, restricción de privilegios o denegación.
Los escenarios de distribución fuera de Yudun no pueden simplemente copiar las señales exclusivas de Yudun. La distribución empresarial, los canales nacionales y la entrega privada requieren establecer sus propias listas de permitidos de versiones, mapeos de certificados, mecanismos de actualización y procedimientos de manejo de anomalías. Las señales de la plataforma son parte de la evidencia, no una respuesta universal en todos los canales.
| Entrada | Método de verificación | Estados posibles | Acción recomendada |
|---|---|---|---|
| Versión y nombre del paquete | Comparar con el registro de versiones y las reglas del canal | Permitido, caducado, desconocido | Permitir, solicitar actualización o restringir capacidades de alto riesgo |
| Señal de reconocimiento de la aplicación | Validar la firma devuelta por la plataforma y los resultados de identidad de la aplicación | Identificada, no identificada, no disponible | Normal, desafiar o restringir, degradar según el canal |
| Cuenta y licencias | Permisos de cuenta en el servidor y licencias de distribución | Válido, caducado, anómalo | Autorizar o denegar según el alcance del recurso |
| Comportamiento de la solicitud | Frecuencia, repetición, cambios de dispositivo y contexto empresarial | Normal, sospechoso, de alto riesgo | Registrar, verificación secundaria, límite de tasa o bloqueo |
| Dispositivo y entorno | Veredictos de la plataforma y reglas de riesgo propietarias | Satisfecho, señal débil, desconocido | Clasificación por riesgos en lugar de un juicio absoluto puntual |
Una secuencia de lanzamiento incorrecta invalida las comprobaciones previas
Modificar DEX, recursos o el Manifest después de la firma final rompe el contenido cubierto por la firma; reconstruir o volver a firmar tras el escaneo desacopla las conclusiones del escaneo del archivo final. Si las herramientas de procesamiento de canales necesitan modificar el cuerpo del paquete, deben completarlo antes de la firma final, y la secuencia debe fijarse en el registro de artefactos.
La distribución AAB distingue además entre los artefactos subidos y los APK divididos que reciben los dispositivos de los usuarios. Los equipos deben descargar u obtener los artefactos realmente entregados desde la plataforma de distribución para realizar muestreos, confirmando que los nombres de paquete, versiones, identidades de firma y recursos clave coincidan con los registros de lanzamiento. Los APK genéricos generados localmente no pueden representar automáticamente todas las configuraciones de dispositivo.
Los paquetes de reversión también deben someterse a la misma validación de firma y actualización. En un incidente, volver a firmar temporalmente un archivo antiguo puede fallar al intentar una instalación superpuesta debido a discrepancias en números de versión, firmas o requisitos de migración de datos.
| Etapa | Entrada | Evidencia de salida | Condiciones principales de fallo |
|---|---|---|---|
| Compilación de lanzamiento | Código fuente y dependencias congelados | Registro de compilación y artefactos base | Dependencias o configuración no reproducibles |
| Procesamiento de endurecimiento de la aplicación | Configuración explícita de protección | Versión de configuración y artefactos candidatos | Objeto de procesamiento no coincide con la versión objetivo |
| Procesamiento de canal | Recursos del canal e información de cumplimiento | Artefactos candidatos del canal | Contenido modificado después de la firma |
| Firma final | Claves controladas y cuerpo final del paquete | Resumen del certificado y resultado de verificación de firma | Uso de clave o entorno incorrecto |
| Lanzamiento de aceptación | Archivo final único | Instalación, actualización, flujos empresariales y controles del servidor | Sustitución de objetos aceptados por otros archivos |
Cómo determinar que el riesgo de reempaquetado está bajo control publicable
Una conclusión publicable no significa que los paquetes modificados nunca puedan instalarse. Significa que la identidad del artefacto oficial es rastreable, los artefactos anómalos no pueden superponerse silenciosamente a las versiones oficiales, el servidor puede identificar o restringir clientes no confiables, los usuarios tienen vías para obtener versiones genuinas y recuperarse, y los equipos pueden auditar los archivos de entrega final.
Las pruebas deben conservar evidencia tanto para rutas de éxito como de fallo. Las rutas de éxito incluyen instalaciones y actualizaciones normales de versiones oficiales, inicios de sesión y flujos empresariales clave. Las rutas de anomalía incluyen actualizaciones superpuestas con certificados no relacionados, versiones desconocidas accediendo a interfaces de alto riesgo, versiones caducadas, señales de integridad no disponibles y recuperación de falsos positivos. Verificar solo el rechazo sin un proceso de recuperación atrapa a usuarios reales en estados irresolubles.
Este artículo no afirma que ninguna tecnología de endurecimiento por sí sola pueda prevenir todas las instalaciones vueltas a firmar. La gobernanza del reempaquetado es un esfuerzo de ingeniería de sistemas completado conjuntamente por la gestión de firmas, controles de actualización, gestión de artefactos, resiliencia del cliente, señales de plataforma y políticas del servidor.
- La identidad del artefacto oficial puede auditarse de forma independiente
- Los certificados anómalos no pueden superponerse silenciosamente a las instalaciones oficiales
- El servidor dispone de políticas graduadas para clientes desconocidos
- Los usuarios pueden recuperarse hacia canales de lanzamiento confiables
- Los paquetes de reversión han completado la validación de actualización por adelantado.
Límites de evidencia y aplicabilidad
Esta sección separa los datos documentados de la plataforma, los juicios de ingeniería y los límites que no se pueden generalizar en afirmaciones de productos no verificadas.
| Sentencia del artículo | Base de hecho o ingeniería | Límite de aplicabilidad |
|---|---|---|
| La instalabilidad de un paquete refirmado no equivale a la identidad del editor oficial. | Android exige que los APK tengan firmas verificables; los atacantes pueden generar firmas autoconsistentes usando sus propias claves sobre contenido modificado. | La instalabilidad también depende del nombre del paquete, las políticas del dispositivo, la versión del SO y la fuente de instalación; no se pueden inferir resultados específicos de muestras basándose únicamente en principios de diseño. |
| Las actualizaciones superpuestas deben verificar la continuidad de la identidad de la firma. | La documentación oficial de Android indica que la plataforma usa la clave de firma de la app para confirmar que las actualizaciones provienen del mismo titular de la clave. | La rotación de certificados y las reglas de firma de la plataforma de distribución deben verificarse según la configuración del proyecto. |
| Las señales de integridad de la plataforma deben validarse y gestionarse en el backend. | Los veredictos de Play Integrity incluyen información sobre reconocimiento de la aplicación, dispositivo, cuenta y entorno; los equipos oficiales recomiendan respuestas del backend basadas en el riesgo. | Las señales de Play no cubren todos los países, canales, dispositivos o escenarios sin conexión. |
| Los archivos de entrega final deben corresponder uno a uno con la evidencia de prueba. | Recompilar, modificar recursos o refirmar cambia la identidad del artefacto y su comportamiento potencial en tiempo de ejecución. | Los resúmenes digitales de archivos establecen una asociación de identidad, pero no proporcionan por sí mismos capacidades anti-manipulación. |
| Un fallo de instalación por sí solo no demuestra que los riesgos de reempaquetado estén cerrados. | Los paquetes anómalos pueden seguir planteando riesgos al cambiar nombres de paquete, realizar ciclos de desinstalación-reinstalación, usar otros canales o explotar la falta de políticas de versión en el servidor. | Las rutas de ataque específicas deben verificarse dentro de alcances de prueba autorizados contra arquitecturas reales de distribución y negocio. |
Preguntas de ingeniería
¿Por qué el sistema no rechaza directamente todos los APK firmados con certificados no oficiales?
El instalador de Android puede verificar si la firma de un paquete actual es autoconsistente, pero el sistema no sabe qué certificado reconoce cada marca. La identidad oficial debe determinarse conjuntamente por la cadena de actualización, la plataforma de distribución y los servicios de negocio.
Si un paquete refirmado no puede realizar una actualización superpuesta, ¿significa que no hay riesgo?
No. Los atacantes aún pueden inducir ciclos de desinstalación-reinstalación, modificar nombres de paquete o explotar la falta de políticas de versión en el servidor para acceder a la lógica de negocio. La prevención de actualizaciones superpuestas es solo un elemento en la matriz de gobernanza.
¿Es suficiente que el cliente lea su propio resumen digital del certificado?
No. Un cliente modificado puede alterar simultáneamente las comprobaciones locales o la lógica de reporte. La información del certificado puede participar en una defensa en profundidad, pero las decisiones de autorización de alto riesgo deben tomarlas el servidor combinando señales verificables.
Tras la publicación del AAB, ¿qué resumen digital de archivo debe guardarse?
Guarde la identidad del AAB subido y obtenga también artefactos entregados reales desde la plataforma de distribución para realizar muestreos. Diferentes dispositivos pueden recibir APK divididos; guardar solo un APK genérico generado localmente es insuficiente.
¿Cuándo puede formularse una conclusión de lanzamiento?
Una conclusión solo puede formularse para el alcance cubierto una vez que la identidad del artefacto firmado final está fijada, y se han completado la instalación, la actualización desde versiones en producción, los flujos de negocio clave, las políticas del lado del servidor, los rangos de SO objetivo y la validación de reversión.
¿Quieres probar esto en tu propia aplicación?
Envíe la versión candidata, los sistemas de destino y las rutas comerciales críticas para una prueba de concepto de Yudun y una evaluación de compatibilidad.
Continuar con: Cómo aceptar APK, DEX y firmar la integridad juntos