Mission client : extraire le design d’une application mobile

La demande

J’ai mené cette mission pour un client, hors cursus, en quelques jours. Le client voulait récupérer le front d’une application mobile, dont toute sa partie design : couleurs et polices. Seul le binaire publié de l’application était disponible, sans son code source. L’application existe sur Android et sur iOS. Faute d’appareil iOS, j’ai analysé le paquet Android. Tout le travail s’est fait hors ligne : aucune requête n’a été émise vers les serveurs de l’application.

Lire l’application à partir du binaire

J’ai commencé par trier le paquet : ce qu’il embarque, ses bibliothèques natives, les marqueurs de son moteur de compilation. Les noms de classes et de méthodes présents dans le binaire m’ont redonné la structure du code.

J’ai ancré chaque affirmation à une source primaire : le binaire, ses chaînes ou sa configuration. J’ai classé chaque point comme observé, inféré ou supposé. Les symboles ont contredit une de mes hypothèses de départ sur une bibliothèque embarquée ; je l’ai corrigée.

Reconstituer la charte graphique

Pour la partie design, je suis parti des ressources du paquet. Les couleurs viennent de ses fichiers de ressources, les polices de la liste de polices qu’il embarque. Le paquet contient aussi des images vectorielles (SVG). J’ai mesuré sur des captures d’écran de l’application les valeurs absentes des ressources, comme les rayons des angles et les espacements. J’ai réuni le tout dans un kit d’interface : une palette classée par rôle, un spécimen typographique et les composants de l’application (barre d’application, carte, boutons, bandeau d’alerte, barre de navigation basse). La police de l’application est sous licence libre : ses fichiers accompagnent le kit. Ses icônes viennent d’un jeu libre, réutilisable lui aussi. Les logos, les noms et les marques de l’éditeur sont exclus du kit : ils restent sa propriété.

Ce que chaque outil atteint

Une passe légère avec strings sur le binaire a suffi pour le triage. Le décodage du paquet avec apktool a donné ses ressources : couleurs, liste des polices et images. Le décompilateur jadx a reconstruit le code managé du paquet, qui n’apparaît pas dans les chaînes du binaire natif ; il y a donné la liste des extensions tierces que l’application intègre. Le comportement de l’application en fonctionnement et son trafic réseau restent hors de portée d’une analyse statique.

Ce que j’ai appris, ce que je referais

J’ai appris à séparer ce que j’observe de ce que j’en déduis : chaque point du kit est classé observé, inféré ou supposé, et ce classement m’a fait corriger une hypothèse fausse sur une bibliothèque embarquée. Chaque outil n’atteint qu’une couche du paquet. Je referais la mesure des rayons et des espacements avec un outil capable de relire le code compilé de cette architecture, pour tirer ces valeurs du code plutôt que de captures.

Limites

Le travail est resté statique : je n’ai observé ni l’application en fonctionnement ni son trafic réseau. Je n’ai pas relu le corps des méthodes du code compilé : l’outil prévu pour le relire ne prenait pas en charge l’architecture du paquet. La structure du code repose donc sur les noms des symboles et sur les chaînes du binaire. Pour la même raison, les rayons et les espacements du kit restent des valeurs approchées, mesurées sur des captures.