hariri.ch
Prenez contact

Développement Outils & Logiciels

vphone-cli : ce que permet vraiment cet outil pour démarrer un iPhone virtuel sur Mac

6 min de lecture

Illustration conceptuelle montrant un iPhone virtuel au-dessus d’une puce de calcul, entouré de couches de virtualisation et de contrôle automatisé.

Un outil de virtualisation iPhone, mais dans un cadre très spécifique

vphone-cli est présenté par son dépôt GitHub comme un outil capable de démarrer un iPhone virtuel via Apple Virtualization.framework, en s’appuyant sur une infrastructure de VM de recherche PCC. Dit autrement, il ne s’agit pas d’un simple simulateur iOS classique, mais d’une chaîne orientée machine virtuelle invitée.

Le cadre d’exécution est toutefois très contraint. L’outil nécessite un hôte Apple Silicon et macOS 15 ou plus, c’est-à-dire Sequoia ou une version ultérieure. Le projet précise aussi que le démarrage invité en PV=3 ne peut pas être imbriqué : il faut donc un Mac hôte non virtualisé sous macOS 15+.

Pour les équipes d’ingénierie, cela signifie que l’expérimentation ne se transpose pas automatiquement à n’importe quel parc de machines ni à n’importe quel environnement CI. Un Mac Intel, un hôte macOS plus ancien, ou une exécution dans une VM macOS imbriquée sortent du périmètre documenté.

Ce qu’il faut préparer avant de lancer une VM

Le dépôt liste plusieurs prérequis techniques. Il faut notamment Xcode ainsi que le SDK iOS, utilisés pour la compilation croisée d’un démon invité. Ce point indique que l’outil ne se limite pas à télécharger une image prête à l’emploi : une partie de la chaîne dépend aussi d’outils de développement Apple.

Autre exigence importante : une relaxation de SIP et de AMFI est nécessaire pour autoriser des entitlements privés PV=3 avec un binaire non signé. La documentation décrit deux approches. La première est la plus permissive : désactiver complètement SIP, puis désactiver AMFI via un argument de démarrage amfi_get_out_of_my_way=1 -v. La seconde conserve SIP dans un mode relaxé réservé au débogage et passe par une allowlist du binaire avec amfidont, tout en laissant AMFI activé à l’échelle du système.

En pratique, ce point réserve clairement vphone-cli à des usages de recherche, de test avancé ou de laboratoire. La documentation ne décrit pas un scénario de poste de travail standard, et les manipulations autour de SIP/AMFI ont des implications de sécurité évidentes pour la machine hôte.

Installation et chaîne de création de la VM

L’installation documentée passe par Homebrew avec la commande brew install zqxwce/tap/vphone-cli. Le dépôt indique ensuite qu’une seule commande peut créer une VM de bout en bout, en enchaînant le téléchargement, le patch, la restauration DFU, l’installation d’un CFW et le premier démarrage.

Pour ceux qui veulent piloter les étapes manuellement, l’exemple de build montre notamment une préparation de firmware avec fw prepare et l’option --iphone-version 26.1. Le projet documente aussi l’emplacement de travail par défaut : tout ce que crée vphone-cli est stocké sous ~/.vphone/. Cette arborescence peut être redirigée via la variable d’environnement VPHONE_ROOT, ce qui peut être utile pour isoler plusieurs jeux de tests, déplacer les données sur un autre volume ou mieux intégrer l’outil à une infrastructure d’automatisation.

Le dépôt mentionne par ailleurs un environnement testé comprenant Mac16,11 27.0b2, un build iPhone 17,3_27.0_24A5424a et CloudOS 26.4-23E5207q. Cela ne constitue pas une matrice de compatibilité exhaustive, mais donne un point de référence concret sur lequel les auteurs disent avoir validé le fonctionnement.

Cinq variantes de firmware, du mode le plus conservateur au plus intrusif

Un des aspects les plus structurants de vphone-cli est la présence de cinq variantes de patch firmware : less, regular, dev, jb et exp. Elles sont décrites comme offrant un niveau croissant de contournement des protections.

  • less est présenté comme un mode sans patch, qui conserve les mitigations iOS activées.
  • regular ajoute des contournements pour AMFI, SSV, Img4 et TXM.
  • dev ajoute un entitlement TXM ainsi que des bypass de débogage.
  • jb est décrit comme un jailbreak complet, avec installation automatique de Sileo et TrollStore au premier démarrage.
  • exp est présenté comme un sur-ensemble du mode jailbreak, avec en plus des patchs de recherche contre la détection de VM.

Cette gradation est importante pour comprendre le positionnement du projet. Il ne s’adresse pas uniquement à la virtualisation « neutre » d’un environnement iPhone, mais aussi à des scénarios de recherche où l’on veut choisir précisément le niveau de modification du système invité. Le mode less peut intéresser ceux qui veulent rester au plus près des mitigations iOS, tandis que les variantes supérieures visent des besoins de débogage, de jailbreak ou d’expérimentation sur les mécanismes de détection d’environnement virtualisé.

Pourquoi le socket de contrôle peut intéresser les équipes d’automatisation

Au-delà du démarrage de la VM, vphone-cli expose un socket de contrôle hôte à l’emplacement <bundle>/vphone.sock. La documentation indique qu’il permet des actions programmatiques comme la capture d’écran, le toucher, les gestes de balayage, l’envoi de touches matérielles et les opérations de presse-papiers.

Le détail le plus notable est que chaque action renvoie une capture d’écran inline, explicitement pour des tests de bout en bout pilotés par l’IA. Pour des développeurs outillage, cela ouvre un modèle d’automatisation différent d’une simple API de contrôle : chaque interaction peut immédiatement produire un retour visuel exploitable par une boucle de test, de validation ou d’agent logiciel.

Sans extrapoler au-delà de ce que documente le dépôt, on peut dire que cette interface fait de vphone-cli un projet potentiellement intéressant pour les workflows de test expérimental, notamment lorsqu’un contrôle visuel de l’état de l’appareil virtuel est nécessaire à chaque étape.

Limites connues et points d’attention

La FAQ du projet mentionne plusieurs limites concrètes. D’abord, le choix de région pendant la configuration initiale d’iOS a son importance : il est déconseillé de sélectionner le Japon ou l’Union européenne, car la VM ne peut pas satisfaire certaines vérifications réglementaires supplémentaires. La documentation suggère par exemple de choisir les États-Unis.

Ensuite, certains plantages de type EXC_GUARD ou GUARD_TYPE_MACH_PORT peuvent être traités en repatchant avec --force-exc-guard. Le dépôt précise que ce comportement est activé d’office pour les bases iOS 18.

Enfin, il faut garder à l’esprit que le projet est distribué sous licence MIT, avec une documentation également disponible en japonais, coréen et chinois dans le répertoire docs. Cette ouverture facilite l’exploration du code et des mécanismes, mais ne change pas la nature du projet : on reste face à un outil avancé, dépendant de conditions matérielles et système précises, et documentant explicitement des contournements de protections côté hôte et côté invité.

Pour un lecteur professionnel, la bonne lecture de vphone-cli est donc la suivante : ce n’est pas un remplaçant grand public du simulateur iOS, mais un outil de recherche et d’automatisation autour d’un iPhone virtualisé, avec un niveau de contrôle inhabituel et des exigences techniques élevées.

À retenir

  • vphone-cli documente le démarrage d’un iPhone virtuel via Apple Virtualization.framework et une infrastructure PCC de recherche.
  • L’outil exige un Mac Apple Silicon, macOS 15+ et un hôte non imbriqué pour le boot invité PV=3.
  • La chaîne peut créer une VM de bout en bout, du téléchargement au premier démarrage, avec stockage par défaut sous ~/.vphone/.
  • Cinq variantes de firmware sont proposées, de less sans patch à exp avec patchs de recherche anti-détection de VM.
  • Un socket de contrôle permet l’automatisation programmatique avec captures d’écran inline pour des scénarios de test E2E pilotés par l’IA.

Publié par :

Sources