Analyseur APK
Déposez un paquet Android — un fichier .apk — et lisez ce qu’il déclare de lui-même avant qu’il n’approche un téléphone : son nom de paquet et sa version, les niveaux de SDK qu’il vise, chaque autorisation qu’il demande, s’il autorise le débogage et les sauvegardes, lesquels de ses composants d’autres applications peuvent atteindre, et les certificats avec lesquels il est signé. Le fichier ne quitte jamais votre appareil : il est ouvert et analysé dans cette page, pas téléversé, car un APK dont vous vous méfiez est exactement le fichier à ne pas confier au serveur d’un inconnu.
Ou déposez le fichier n’importe où dans ce cadre. Tout ce qui suit est lu dans le paquet lui-même, sur cet appareil — le manifeste, les ressources compilées et les blocs de signature.
Résumé du paquet
Autorisations
Les niveaux de protection suivent la classification propre au framework Android. Une autorisation que cette page ne reconnaît pas est signalée comme absente du tableau de référence — les autorisations personnalisées, de constructeur ou plus récentes sont nommées honnêtement, jamais devinées.
Indicateurs de l’application
Composants
Certificats de signature
Remarques
Ce qu’un APK déclare avant d’exécuter la moindre ligne de code
Un APK est une archive ZIP qui a des opinions. Avant qu’Android n’exécute le moindre de son code, le système lit le AndroidManifest.xml binaire qu’elle contient, et ce seul fichier est une déclaration d’intention étonnamment complète. Il nomme le paquet — l’identité à laquelle les mises à jour sont comparées — et sa version. Il énonce la plus ancienne version d’Android que l’application prétend prendre en charge et celle dont elle suit les règles de comportement, et c’est pourquoi le SDK cible compte : une cible basse maintient silencieusement en vie l’ancien comportement d’autorisations, plus permissif. Il énumère chaque autorisation que l’application pourra jamais utiliser, car une autorisation non déclarée ne peut pas être accordée plus tard. Il dit si la compilation est débogable — un indicateur qui ne devrait jamais survivre à une version de production — et si ses données peuvent finir dans les sauvegardes de l’appareil. Et il inventorie les composants de l’application : activités, services, récepteurs et fournisseurs, chacun avec un état d’exportation qui décide si d’autres applications de l’appareil peuvent l’appeler. Un composant exporté sans vérification d’autorisation est la surface d’attaque classique d’Android, et vous pouvez la voir ici, dans le manifeste, sans rien installer.
L’autre moitié de l’histoire, c’est la signature. Android n’installe une mise à jour par-dessus une application existante que lorsque les deux sont signées avec la même clé ; l’empreinte du certificat du signataire est donc la continuité d’identité de l’application : le même nom de paquet signé par une autre clé est une autre application portant un libellé familier. Cette page lit les deux générations de signature — les certificats de type Jar dans META-INF et le bloc APK Signature Scheme v2/v3 — et affiche pour chaque signataire le sujet, l’émetteur, la fenêtre de validité et l’empreinte SHA-256, que le comparateur de certificats et de clés peut confronter à une clé ou un CSR que vous détenez. Le guide compagnon, ce que contient un APK avant de l’installer, déroule toute l’inspection en liste de contrôle. Deux limites honnêtes : cette page lit des déclarations, pas un comportement — elle ne décompile pas le code, n’exécute pas l’application et ne juge pas si c’est un logiciel malveillant — et là où le manifeste lui-même est ambigu (un indicateur exported omis sur un composant avec intent-filter, un libellé que les ressources compilées ne résolvent pas), elle le dit au lieu de combler le vide par une supposition. Pour ce que l’application fait sur le réseau une fois lancée, l’analyseur PCAP lit la capture.
Questions fréquentes
Où va mon fichier APK ?
Nulle part. Le fichier est ouvert et analysé dans cette page, sur votre appareil, et rien n’est téléversé, transmis ni stocké — analyser un fichier n’émet aucune requête réseau. C’est ici plus important que pour la plupart des outils : les APK que l’on veut le plus inspecter sont ceux dont on se méfie déjà — un fichier venu d’un forum, un téléchargement direct, une fiche de boutique qui semble fausse — et envoyer un binaire suspect à un service d’analyse distant est en soi une exposition. Il fonctionne aussi hors ligne une fois la page chargée.
Que faut-il vérifier avant d’installer un APK ?
Quatre choses, toutes visibles ci-dessus. Le nom de paquet : est-ce le véritable espace de noms de l’éditeur, ou un sosie avec un caractère changé ? Les autorisations : une application lampe de poche a-t-elle vraiment besoin de vos contacts, de votre journal d’appels et de votre position précise — et une demande de niveau signature ou spécial se cache-t-elle parmi les demandes de routine ? Les composants exportés : chaque activité, service, récepteur ou fournisseur que d’autres applications peuvent atteindre est une surface que vous acceptez. Et le signataire : une mise à jour doit porter le même certificat de signature que l’application installée, alors comparez l’empreinte SHA-256 à la copie de confiance avant d’installer une « version plus récente » venue de n’importe où.
Cela peut-il me dire si une application est un logiciel malveillant ?
Non, et tout outil qui le promet à partir du seul manifeste en vend trop. Cette page lit ce que le paquet déclare — identité, autorisations, composants, indicateurs et signatures —, ce qui suffit à attraper les négligents et les imposteurs : un clone avec le mauvais signataire, une lampe de poche exigeant l’accès aux SMS, une compilation de production restée débogable. Juger ce que le code fait réellement exige une décompilation, une analyse dynamique ou le verdict d’un scanner réputé sur le binaire lui-même. Traitez un résultat propre ici comme « rien de déclaré ne semble anormal », jamais comme un certificat de sécurité.
Pourquoi certaines autorisations indiquent-elles « absent du tableau de référence » ?
Parce que l’honnêteté vaut mieux qu’une supposition plausible. Les niveaux de protection affichés — normal, dangereux, signature, spécial — proviennent d’un tableau soigné des autorisations android.* les plus connues et du niveau que le framework attribue à chacune. Les fournisseurs ajoutent leurs propres autorisations, les constructeurs en ajoutent d’autres, et les nouvelles versions d’Android introduisent de nouveaux noms ; aucun d’eux n’est dans le tableau, alors la page le dit explicitement. Un niveau inconnu ne signifie pas que l’autorisation est inoffensive ou dangereuse — il signifie que cette référence ne la couvre pas, et le nom et l’espace de noms de l’autorisation elle-même sont le point de départ de la vérification.
Que signifie « exporté : non spécifié » ?
Cela signifie que le manifeste ne le dit vraiment pas. Quand un composant déclare un intent-filter mais omet android:exported, la réponse effective a dépendu du SDK cible de l’application et de la version d’Android — les anciennes règles exportaient ces composants par défaut, les nouvelles refusent d’installer l’application tant que le développeur n’a pas décidé. Un lecteur qui imprimerait un oui ou un non assuré inventerait un fait que le fichier ne contient pas, alors cette page signale l’omission elle-même. Dans vos propres compilations, c’est la ligne qui mérite d’être corrigée explicitement.