De l'App Store au clone : comment l'IA transforme votre fichier .ipa en modèle. 

IA – Accélérer la rétro-ingénierie

Chaque application iOS que vous publiez sur l'App Store est un fichier binaire compilé. Il est dépourvu de vos commentaires, de vos noms de variables, de vos schémas d'architecture et de votre documentation. Pendant des décennies, cette étape de compilation a constitué un véritable obstacle. La rétro-ingénierie était complexe. Elle exigeait des spécialistes, des semaines de travail et une certaine familiarité avec la lecture de l'assembleur ARM. Les spécialistes devaient passer des heures à comparer Ghidra et IDA avant même de pouvoir commencer. 

Cette barrière a disparu. 

Lorsque j'ai demandé à un modèle d'IA de rédiger ce paragraphe, il a évoqué la possibilité, offerte par un abonnement gratuit à l'IA, de remplacer intégralement les chercheurs en sécurité expérimentés pour la rétro-ingénierie d'applications iOS. Bien que cette technologie ne soit pas encore pleinement opérationnelle, j'ai réussi, en quelques heures seulement, à partir d'une petite application iOS compilée, à en créer un clone complet, avec les mêmes fonctionnalités, à partir d'un code source flambant neuf.  

Ce blog explique précisément comment cela se produit et montre que les protections d'analyse statique fonctionnent contre le clonage de cette application d'IA.   

Comment fonctionne la rétro-ingénierie assistée par l'IA 

Pour comprendre la menace, il faut d'abord comprendre ce que contient un fichier binaire iOS compilé. 

Une application iOS est distribuée sous forme d'exécutable Mach-O dans une archive .ipa. Le compilateur supprime les métadonnées du code source, mais pas toutes. Les environnements d'exécution Swift et Objective-C dépendent de métadonnées qui, par conception, survivent à la compilation : noms de classes, de méthodes et de propriétés, conformités aux protocoles et informations de type. De plus, les chaînes de caractères contenant les URL des points de terminaison d'API, les messages d'erreur, les noms de clés et les journaux sont stockées en clair dans les segments de données binaires. Les frameworks liés sont visibles dans les commandes de chargement. 

La chaîne d'outils traditionnelle de rétro-ingénierie, comprenant otool, strings, Ghidra, llvm-nm et bien d'autres, existe depuis des années. Elle produit des données brutes : symboles, listes de désassemblage et vues hexadécimales. Utile à un expert, mais opaque pour le commun des mortels. Il faut toujours savoir lire l'assembleur pour exploiter le désassemblage, et la plupart des développeurs n'apprécient guère cette lecture. 

La couche d'IA modifie le modèle. Les agents exécutent automatiquement des outils de rétro-ingénierie en ligne de commande. Ils extraient les symboles, les chaînes de caractères et les informations d'assemblage, et peuvent commencer à tirer des conclusions sur les comportements. L'agent peut passer directement du fichier IPA aux documents de conception. Ensuite, une autre équipe d'agents peut utiliser ces documents pour implémenter une application ou y intégrer des fonctionnalités copiées.  

Le risque de vol de adresse IP — Ce qui est réellement exposé 

La logique métier est codée dans les noms des symboles. Les noms de vos classes, méthodes et propriétés concrétisent vos choix de conception. Ils décrivent le fonctionnement de votre application, sa structure et les problèmes qu'elle résout. Dans une version finale, nombre de ces noms sont conservés tels quels. Les algorithmes propriétaires, l'API côté client et la logique métier critique sont présents dans l'application finale. Un concurrent ou une application imitatrice n'a pas besoin de votre code source.  

Étude de cas : Clonage d’un répartiteur de tâches à partir d’un seul fichier .ipa 

Pour illustrer cela concrètement, j'ai appliqué cette méthodologie à une véritable application iOS appelée Job Dispatcher. Il s'agit d'une de nos applications d'exemple qui comprend un écran de connexion, affiche des tâches pour un technicien, peut afficher la météo et ouvrir une carte pour obtenir un itinéraire. Le code source est disponible à l'adresse suivante : https://github.com/digitalai-opensource/job-dispatcher et j'ai également utilisé cette application pour montrer la rétro-ingénierie à l'aide de Ghidra à https://digital.ai/catalyst-blog/ios-binary-modification/Étonnamment, cloner l'application entière s'est avéré moins laborieux que d'utiliser Ghidra pour contourner une partie de l'authentification.   

Je suis parti du simple fichier .ipa, mon objectif étant de générer le code source Swift d'une application équivalente. J'y suis parvenu en quelques heures avec une intervention humaine minimale. Cela aurait été plus rapide, mais l'agent a fouillé les répertoires src de ma machine et a trouvé le code source original ; j'ai donc dû tout recommencer. 

Méthodologie

1. Générez des diagrammes d'architecture à partir des seuls fichiers binaires compilés. Six diagrammes ont été produits, mais ces deux exemples illustrent les éléments essentiels. Ces diagrammes sont assez précis.

2. Un pRompt a été utilisé pour générer un document de spécifications en vue de la recréation de l'application. Ce document produit un cahier des charges détaillé, que vous pouvez consulter en cliquant sur la section « Cahier des charges produit détaillé » ci-dessous.

Le document généré comprend plusieurs recommandations importantes, notamment : « Notes d’implémentation pour le renforcement de la sécurité en production (après la définition de la configuration de référence) : remplacer l’authentification locale par une véritable authentification côté serveur et un cycle de vie de session géré. Déplacer les secrets et les données de session vers le trousseau d’accès lorsque cela est possible. »

Développer le document des exigences produit

Document des exigences produit : Clone du répartiteur de tâches (rétro-ingénierie de la base)

1. Objectif du document

Définir un PRD complet et implémentable pour reconstruire l'application iOS analysée en tant que clone fonctionnel, tout en séparant clairement les faits confirmés des inconnus non définis par le binaire source.

2. Fondements de la preuve

Ce PRD est dérivé de l'analyse binaire Mach-O de l'exécutable de l'application, des métadonnées de l'application provenant d'Info.plist, des frameworks et symboles liés, et des chaînes d'exécution et des noms de classes/types extraits.

Le code source et les contrats du backend n'étaient pas disponibles. Certaines exigences ont été déduites et sont signalées comme lacunes.

3. Exigences confirmées par catégorie

3.1 Scope

Application iOS nommée Job Dispatcher. Objectif principal : répartir les interventions des techniciens, afficher les interventions ouvertes/fermées, permettre à l’utilisateur de consulter les détails des interventions, afficher l’itinéraire/le contexte de localisation sur une carte et obtenir les prévisions météorologiques pour la destination.

Les actions principales de l'utilisateur comprennent la connexion, la consultation des listes d'emplois, la consultation des détails d'un emploi, l'ouverture de la carte et du contexte d'itinéraire pour un emploi, et la modification du statut de l'emploi (ouvert/fermé).

3.2 Flux UX

Le lancement de l'application nécessite une authentification. Une fois les identifiants valides, l'utilisateur accède à la liste des offres d'emploi. Il peut alors filtrer les offres ouvertes et fermées, consulter les détails, explorer la carte et obtenir des informations météorologiques.

Architecture 3.3

Structure d'application SwiftUI avec les modèles App et View. Pont UIKit via UIViewRepresentable pour l'intégration de MapKit. Les objets LocationManager et MapViewCoordinator dédiés prennent en charge le comportement de la carte piloté par des délégués et la gestion d'état observable.

4. Points de vue fondamentaux

• Vue de connexion : Gère la saisie des identifiants et la validation de l'authentification.
• Vue de la liste des emplois : Affiche les collections de tâches ouvertes et fermées.
• InfoView : Présente des informations détaillées sur l'emploi et la météo.
• Vue cartographique : Affiche le tracé de la carte, les annotations, les superpositions et la position de l'utilisateur.

5. Référence de mise en œuvre

Créez une application iOS SwiftUI ciblant iOS 14 et versions ultérieures, utilisant MapKit, CoreLocation, la mise en réseau URLSession, le décodage JSON et les intégrations de prévisions weather.gov.

Implémenter des tâches JSON pré-initialisées, la validation de l'authentification locale, le rendu des itinéraires, la récupération des données météorologiques de destination et la gestion des erreurs de connexion, de géocodage, de météo et de réseau.

6. Critères d'acceptation

• L'utilisateur peut se connecter et accéder à la liste des offres d'emploi.
• Les tâches ouvertes et fermées s'affichent correctement.
• L'écran de la carte demande l'autorisation de localisation.
• Les données météorologiques de destination se chargent correctement.
• Les conditions d'erreur génèrent un retour d'information clair.

3. À partir de ces diagrammes et spécifications, créez une nouvelle session avec une application iOS Swift vierge. J'ai choisi de constituer une équipe d'agents : un agent Chef de Produit orchestrant un agent Développeur, un agent Assurance Qualité et un agent Concepteur. N'ayant pas pris de captures d'écran de l'interface utilisateur, l'IA a dû choisir les mises en page. L'agent Chef de Produit a utilisé les fichiers de spécifications et de conception pour créer l'intégralité du clone à partir d'une simple instruction humaine. Les agents ont ensuite simulé le travail d'une véritable équipe Scrum pendant plusieurs heures, et j'ai finalement obtenu un clone complet de Job Dispatcher. L'un des aspects les plus amusants du processus a été de voir l'agent Chef de Produit élaborer des plans de sprint, estimant par exemple que l'implémentation de la fonctionnalité météo prendrait deux semaines. C'était rassurant de constater que l'IA semble tout aussi incapable que n'importe qui d'autre d'estimer les efforts nécessaires.

4. Le processus ne comporte que trois étapes, mais j'ai tout de même été surpris de constater que l'application fonctionnait correctement dans le simulateur iOS. Certes, l'implémentation était loin d'être prête pour la production. La majeure partie du code se trouvait dans un seul fichier volumineux, la console affichait des avertissements lors de l'exécution et les identifiants étaient codés en dur (admin/password) au lieu d'une combinaison plus sécurisée comme tech/secret.

Pourquoi cela est plus important que la rétro-ingénierie traditionnelle 

Le constat est clair : cette attaque a toujours été possible. Ce qui a changé, c'est tout son environnement. Le processus traditionnel de rétro-ingénierie exigeait une expertise pointue des formats binaires, du désassemblage et du comportement à l'exécution. Le processus assisté par l'IA, lui, se limite à la capacité d'exécuter une commande terminal et de rédiger une invite de commande. Les chefs de produit, les développeurs juniors et les fondateurs non techniques peuvent désormais mener une analyse de rétro-ingénierie pertinente sur l'application d'un concurrent. Les applications clonées peuvent être commercialisées rapidement. Les logiciels SaaS peuvent être reproduits au lieu d'être renouvelés (sauf les nôtres, bien sûr !). Cette attaque est évolutive et semble vouée à s'améliorer grâce à de nouveaux modèles d'IA ou simplement à des invites de commande plus performantes.  

La défense : Protections contre l'analyse statique 

La bonne nouvelle, c'est que l'attaque décrite ci-dessus repose entièrement sur la richesse sémantique du binaire. Sans cette richesse, la chaîne d'inférence de l'IA s'effondre. 

Le renommage des symboles, le chiffrement des chaînes de caractères, l'obfuscation du flux de contrôle et les techniques de chiffrement constituent une couche de défense robuste. L'IA s'appuie fortement sur les informations textuelles facilement accessibles pour élaborer ses diagrammes de conception. Voici un diagramme similaire issu d'une version de Job Dispatcher protégée par l'obfuscation du flux de contrôle et le chiffrement des chaînes littérales. 

Il reconnaît encore les vues de base de l'application, mais il a imaginé une application de recherche d'emploi bien conçue. Où est mon mot de passe codé en dur ?! Le mot de passe codé en dur est ma logique métier critique Pour cette application, comment pourrais-je l'utiliser autrement pour des blogs d'attaques spectaculaires ? Et je n'ai même pas de serveur de listes de tâches auquel me connecter. 

Conclusion 

Le modèle de menace pesant sur la adresse IP des applications mobiles a profondément changé. L'IA n'a pas créé une nouvelle catégorie d'attaque, mais elle a rendu une catégorie existante accessible et extensible. 

Le fichier binaire que vous envoyez à l'App Store est public. Chaque client, chaque concurrent et chaque personne mal intentionnée peut le télécharger en quelques secondes. Pendant la majeure partie de l'histoire d'iOS, ce risque était acceptable car le coût d'exploitation de cette faille était élevé. Ce coût est désormais négligeable.