Ce qu'il y a dans un APK avant de l'installer

Pourquoi un APK installé manuellement mérite un premier regard

Les applications d'une boutique officielle arrivent avec une fiche, un historique d'avis et une page d'éditeur. Un APK téléchargé hors boutique — depuis le site d'un fournisseur, un miroir, un forum, un message de discussion ou une vieille sauvegarde — n'apporte aucun de ce contexte, et l'invite d'installation ne le remplace pas. L'installateur d'Android affiche le nom et l'icône, et les autorisations apparaissent tard, regroupées et simplifiées, au moment même où vous avez le moins de chances de vous arrêter pour réfléchir. Une fois l'application installée et lancée une fois, elle détient peut-être déjà les autorisations accordées et a utilisé le réseau. Le moment bon marché pour poser des questions, c'est avant, tant que le fichier n'est encore qu'un fichier.

Ce n'est pas un argument contre l'installation manuelle elle-même. Les fournisseurs distribuent directement des applications légitimes, les entreprises déploient ainsi leurs outils internes, et les anciennes versions résolvent parfois de vrais problèmes. C'est un argument pour lire ce qu'on vous a remis. L'analyseur d'APK de ce site analyse le paquet dans votre navigateur — le fichier n'est jamais téléversé ni exécuté — et présente le manifeste, les autorisations, les composants et le certificat de signature dans une seule vue. Quel que soit l'outil utilisé, gardez cet ordre : inspecter d'abord, installer ensuite, et traiter toute application qui ne survit pas à l'inspection comme une réponse en soi.

Le manifeste est la propre déclaration de l'application

Chaque APK contient un AndroidManifest.xml, stocké en XML binaire, et c'est la déclaration de l'application sur elle-même. Il nomme le paquet — l'identité unique qu'utilise Android, comme com.example.app — ainsi qu'un versionCode numérique et un versionName lisible. Il déclare les composants que contient l'application, les autorisations qu'elle demande et les fonctions matérielles et logicielles qu'elle attend. Comme Android fait appliquer une grande partie de ce fichier, il est plus difficile à falsifier à la légère qu'une fiche de boutique ou une page de téléchargement : une application ne peut pas utiliser silencieusement une autorisation qu'elle n'a jamais déclarée, ni prétendre être la mise à jour d'un paquet dont elle ne partage pas le nom.

Deux nombres du manifeste en disent long sur la maintenance. Le minSdkVersion est la plus ancienne version d'Android sur laquelle l'application fonctionnera ; un plancher très bas implique la compatibilité avec des appareils et des modèles de sécurité d'il y a de nombreuses années, parfois nécessaire, parfois simplement héritée et oubliée. Le targetSdkVersion est le niveau de comportement Android que l'application prétend suivre. Google relève chaque année la cible exigée pour les mises à jour en boutique, car une cible plus élevée soumet l'application à des règles de confidentialité et de sécurité plus récentes. Un APK dont la cible date de plusieurs années n'est pas automatiquement malveillant — mais il vous dit qu'il a évité, ou jamais satisfait, ces règles nouvelles, et vous devriez demander pourquoi.

Les autorisations, lues correctement

Android classe les autorisations, et la classe compte plus que le nom. Les autorisations normales sont accordées automatiquement à l'installation — l'accès au réseau est l'exemple familier — parce que le système les juge à faible risque. Les autorisations dangereuses couvrent des données et actions sensibles comme les contacts, les messages, la position précise, le micro et l'appareil photo ; elles exigent une invite à l'exécution que l'utilisateur peut refuser. Les autorisations de signature ne sont accordées qu'aux applications signées avec le même certificat, ou au système lui-même, si bien qu'une application tierce qui en déclare une n'y gagne rien. En lisant une liste d'autorisations, rangez-la mentalement dans ces catégories avant de juger la moindre ligne.

Le contexte est le verdict, pas le nombre. Une lampe de poche qui demande à lire les SMS n'a aucune raison honnête de le faire ; une messagerie qui demande la même autorisation peut au moins s'expliquer — lire un code de vérification, ou proposer de devenir votre application de messages par défaut. Une application bancaire peut légitimement demander de nombreuses autorisations, tandis qu'un jeu simple qui n'en demande que quelques-unes pourrait inclure justement celle qui ne colle pas. Ne notez donc pas les applications au seul nombre d'autorisations. Pour chaque autorisation dangereuse, demandez quelle fonction de cette application cesserait de marcher sans elle. Les demandes que vous ne pouvez rattacher à aucune fonction sont le résultat, et ce sont exactement celles que cache le résumé d'installation.

Composants exportés et surface d'attaque qu'ils créent

Une application se compose de composants — activités (écrans), services, récepteurs de diffusion et fournisseurs de contenu — et le manifeste indique lesquels sont exportés, c'est-à-dire accessibles aux autres applications de l'appareil. Les composants exportés ne sont pas une erreur par défaut : une cible de partage, un ouvreur de fichiers et un lien profond fonctionnent parce qu'un composant est exporté à dessein, protégé et, dans l'Android moderne, déclaré explicitement. Le risque se trouve dans les composants exportés qui n'auraient jamais dû être une porte publique : un service que n'importe quelle application peut démarrer, un récepteur que n'importe laquelle peut déclencher, ou un fournisseur qui remet les données de l'application à qui les demande, sans aucun contrôle d'autorisation devant.

Deux indicateurs du manifeste méritent un regard direct dans toute application de production. Une application marquée débogable peut être inspectée par des outils sur une machine connectée ; c'est un réglage de développement, et le livrer activé est un signal d'alarme sur la façon dont la version a été construite. Autoriser la sauvegarde signifie que les données privées de l'application peuvent entrer dans les sauvegardes de l'appareil, ce qui peut être pratique et peut aussi déplacer des données que vous croyiez à l'intérieur de l'application vers un endroit bien moins contrôlé. Aucun des deux indicateurs ne prouve qu'une application est nuisible. Tous deux sont bon marché à vérifier, difficiles à justifier dans un produit fini, et exactement le genre de détail qui n'apparaît jamais sur une page de téléchargement.

Certificats de signature : le système d'identité d'Android

Chaque APK est signé, et le certificat de signature est ce qu'Android a de plus proche d'une pièce d'identité. Android n'installera une mise à jour par-dessus une application existante que si les deux copies partagent le même nom de paquet et le même signataire. Cette règle unique fait beaucoup de travail silencieux : un étranger ne peut pas envoyer une mise à jour trojanisée d'une application à laquelle vous faites déjà confiance, car il ne possède pas la clé d'origine, et l'empreinte du certificat — affichée habituellement comme un résumé SHA-256 — est le moyen pratique de vérifier la continuité. Si un fournisseur publie une empreinte attendue, comparez-la. Le comparateur de certificats et de clés de ce site couvre la même logique d'empreintes pour les certificats et les clés en général.

Soyez clair sur ce qu'une empreinte prouve et ne prouve pas. Elle prouve que ce fichier a été signé par le détenteur d'une clé privée particulière, et qu'il correspond — ou non — à un autre fichier signé avec la même clé. Elle ne prouve pas que le détenteur de la clé est honnête, compétent, ni même l'entreprise nommée dans les champs d'objet du certificat, que le signataire remplit lui-même. Une application reconditionnée est typiquement signée avec un certificat différent de l'original, c'est pourquoi une empreinte différente est un fort signal d'arrêt ; une empreinte identique n'est qu'un signal de continuité. L'identité dans Android, c'est la continuité de la clé, rien de plus — traitez-la comme telle.

Une liste de contrôle avant installation

Assemblez les pièces dans un ordre fixe et l'inspection prend quelques minutes. D'abord, l'identité : le nom du paquet correspond-il à l'application attendue, et le code et le nom de version sont-ils plausibles pour l'édition que vous vouliez télécharger ? Ensuite, la maintenance : quel âge ont les niveaux SDK minimum et cible, et cela convient-il à une application encore entretenue ? Troisièmement, les autorisations : énumérez les dangereuses et rattachez chacune à une fonction, en vous arrêtant sur toute celle que vous ne pouvez pas expliquer. Quatrièmement, la surface : quels composants sont exportés, et le débogage et la sauvegarde sont-ils activés ? Cinquièmement, la signature : l'empreinte du certificat correspond-elle à la valeur déclarée par l'éditeur, ou au moins à la copie à laquelle vous faites déjà confiance ? Faites passer le fichier par l'analyseur d'APK et parcourez cette liste sur un seul écran.

Décidez ensuite en trois catégories, pas deux. Installez, quand tout se rattache à une fonction et que l'empreinte est bonne. Installez prudemment — sur un appareil de test, dans un profil professionnel, ou sans accorder les autorisations douteuses — quand presque tout colle mais qu'un point demande surveillance. Ou renoncez, quand le nom du paquet est faux, que l'empreinte ne correspond pas, ou qu'une autorisation dangereuse n'a aucune fonction imaginable derrière elle. Renoncer coûte un téléchargement ; l'autre direction peut coûter un compte. Et gardez l'habitude à sa juste mesure : c'est du triage, comme les dix premières minutes avec l'analyseur de captures de paquets — une lecture rapide et honnête de ce qu'un fichier déclare sur lui-même, faite avant de lui donner une place sur l'appareil que vous emportez partout.

Questions fréquentes