Pourquoi les APK re-signés s'installent toujours et où résident les risques

Distinguer la validation d'installation, l'identité de signature et l'autorisation métier

Android exige que les APK soient signés. Le système vérifie si la structure du paquet de l'installateur et les données de signature prouvent que le contenu actuel a été signé par la clé privée correspondante. Si un attaquant modifie les fichiers DEX, les ressources ou le Manifeste, puis re-signe entièrement le résultat avec sa propre clé, le nouveau paquet peut être cryptographiquement auto-cohérent et satisfaire aux conditions d'une nouvelle installation.

Ce résultat répond uniquement à la question de savoir si le paquet actuel possède une signature vérifiable ; il ne répond pas à la question de savoir si le signataire est l'éditeur officiel. L'autorisation de marque, les canaux légitimes, les permissions de connexion au compte et l'accès aux interfaces à haut risque sont des préoccupations métier que l'application et le serveur doivent évaluer séparément.

Par conséquent, les rapports de test ne doivent pas assimiler « installable après re-signature » à un « échec de la protection de signature », ni « échec de l'installation » à la fermeture de tous les risques de reconditionnement. Les questions correctes sont : le paquet modifié peut-il atteindre les appareils des utilisateurs ? Peut-il usurper la version officielle lors d'une mise à jour ? Peut-il se connecter aux services réels ? Et comment le serveur identifie-t-il et gère-t-il ces cas ?

Pourquoi les paquets re-signés permettent souvent uniquement une nouvelle installation

Android utilise l'identité de signature de l'application pour assurer la continuité des mises à jour. Lorsqu'une application installée accepte une mise à jour par superposition, la plateforme doit confirmer que la nouvelle version respecte les règles d'identité de signature par rapport à la version existante. Un paquet modifié signé avec un certificat non lié ne peut généralement pas remplacer directement la version officielle ; il nécessite d'abord la désinstallation de l'application officielle, le changement du nom du paquet, ou l'incitation de l'utilisateur à l'installer dans un environnement séparé.

C'est pourquoi les tests de reconditionnement doivent exécuter à la fois une installation fraîche et des mises à jour par superposition. Tester uniquement l'installation fraîche omet les vérifications de continuité de signature, tandis que tester uniquement les mises à jour par superposition ignore les voies par lesquelles des paquets usurpés entrent sur l'appareil via différents noms de paquets ou des cycles de désinstallation-réinstallation. Les résultats pour ces deux scénarios doivent être enregistrés séparément.

La rotation des signatures et Play App Signing ajoutent de la complexité à la chaîne de publication. Les équipes doivent préserver les identités de certificats actuelles et historiquement autorisées, les règles de rotation, ainsi que les responsabilités distinctes des clés de téléversement et des clés de signature d'application. Les politiques côté serveur doivent utiliser des données correspondant à la méthode de distribution. Les certificats de développement, de téléversement et de distribution finale ne doivent jamais être confondus dans un seul champ.

• Exécuter une mise à jour par superposition depuis la version active actuelle
• Effectuer une installation fraîche après désinstallation
• Vérifier les changements de nom de paquet et les impacts sur le répertoire de données
• Vérifier la rotation des certificats conformément aux règles de la plateforme de distribution

La gouvernance du reconditionnement doit commencer par l'identité de l'artefact final

Les équipes enregistrent souvent uniquement le numéro de build, négligeant de consigner le condensat du fichier APK final et celui du certificat de signature. L'injection de ressources par canal, le réalignement, la re-signature ou l'optimisation du paquet peuvent altérer le fichier final. Si l'analyse de sécurité porte sur des artefacts pré-canaux, les fichiers reçus par les utilisateurs actifs ne sont pas couverts par les mêmes preuves.

Nous recommandons de générer des registres d'artefacts sans ambiguïté pour chaque candidat à la publication : nom du paquet, versionCode, versionName, SHA-256 du fichier, SHA-256 du certificat, résultat de la vérification du schéma de signature, origine du build, canal, ordre de traitement et horodatage de génération. Les contrôles statiques, les mises à jour d'installation, les tests de régression fonctionnelle et les règles d'autorisation côté serveur doivent tous se référer à ce registre.

Les condensats de fichiers ne sont pas des mesures de protection en soi ; leur valeur réside dans la prévention de la modification silencieuse de l'objet testé durant le flux de travail. Toute modification du condensat, de la signature ou de la séquence de canaux indique un nouveau candidat à la publication, nécessitant la réexécution des portes concernées.

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: required

Les serveurs doivent traiter les clients anormaux comme un problème de politique

Les clients peuvent signaler des noms de paquets, des versions, des certificats ou des matériaux d'intégrité, mais les clients modifiés peuvent également falsifier ces champs de signalement standard. Les serveurs doivent privilégier les signaux vérifiables, en combinant le statut du compte, la version, le comportement des requêtes, le risque appareil et l'environnement de distribution dans une politique, plutôt que de faire confiance à un booléen unique rapporté par le client.

Play Integrity peut renvoyer des verdicts sur la reconnaissance de l'application, l'intégrité de l'appareil, la licence du compte et le risque environnemental. La documentation officielle note que certains signaux peuvent être indisponibles en raison de la version du système d'exploitation, du facteur de forme de l'appareil, de la source de distribution, du statut des services Play ou de la configuration. L'approche correcte consiste à modéliser séparément les états « indisponible », « échec » et « risque élevé », en préparant des stratégies de dégradation, de vérification secondaire, de restriction de privilèges ou de refus.

Les scénarios de distribution hors Google Play ne peuvent pas simplement copier les signaux exclusifs à Play. La distribution en entreprise, les canaux nationaux et la livraison privée nécessitent l'établissement de leurs propres listes d'autorisation de versions, de mappages de certificats, de mécanismes de mise à niveau et de procédures de gestion des anomalies. Les signaux de la plateforme font partie des preuves, et non d'une réponse universelle valable pour tous les canaux.

Une séquence de publication incorrecte invalide les contrôles antérieurs

La modification du DEX, des ressources ou du Manifest après la signature finale rompt l'intégrité du contenu couvert par la signature ; reconstruire ou resigner après analyse découple les conclusions de l'analyse du fichier final. Si les outils de traitement de canal doivent modifier le corps du paquet, ils doivent le faire avant la signature finale, et la séquence doit être figée dans le registre des artefacts.

La distribution AAB distingue davantage les artefacts téléversés des APK fractionnés reçus par les appareils utilisateurs. Les équipes doivent télécharger ou obtenir depuis la plateforme de distribution les artefacts réellement livrés pour des vérifications ponctuelles, en confirmant que les noms de paquets, versions, identités de signature et ressources clés correspondent aux enregistrements de publication. Les APK génériques générés localement ne peuvent pas représenter automatiquement toutes les configurations d'appareil.

Les paquets de retour arrière doivent également subir la même validation de signature et de mise à niveau. En cas d'incident, resigner temporairement un ancien fichier peut échouer lors d'une installation par recouvrement en raison d'incompatibilités de numéros de version, de signatures ou d'exigences de migration de données.

Comment déterminer si le risque de repackaging est sous contrôle publiable

Une conclusion publiable ne signifie pas que les paquets modifiés ne pourront jamais s'installer. Cela signifie que l'identité de l'artefact officiel est traçable, que les artefacts anormaux ne peuvent pas silencieusement recouvrir les versions officielles, que le serveur peut identifier ou restreindre les clients non fiables, que les utilisateurs disposent de voies pour obtenir des versions authentiques et récupérer leur état, et que les équipes peuvent auditer les fichiers de livraison finaux.

Les tests doivent conserver des preuves pour les chemins de succès et d'échec. Les chemins de succès incluent l'installation et la mise à niveau normales des versions officielles, les connexions et les flux métier clés. Les chemins d'anomalie incluent les mises à niveau par recouvrement avec des certificats non liés, les versions inconnues accédant à des interfaces à haut risque, les versions expirées, les signaux d'intégrité indisponibles et la récupération des faux positifs. Vérifier uniquement le rejet sans processus de récupération piège les utilisateurs réels dans des états irrésolubles.

Cet article n'affirme pas qu'une technologie de durcissement seule peut empêcher toutes les installations resignées. La gouvernance du repackaging est un effort d'ingénierie système réalisé conjointement par la gestion des signatures, les contrôles de mise à niveau, la gestion des artefacts, la résilience du client, les signaux de la plateforme et les politiques côté serveur.

• L'identité de l'artefact officiel peut être auditée indépendamment
• Les certificats anormaux ne peuvent pas silencieusement recouvrir les installations officielles
• Le serveur dispose de politiques graduées pour les clients inconnus
• Les utilisateurs peuvent revenir vers des canaux de publication de confiance
• Les packages de retour arrière ont terminé la validation de mise à niveau en amont.