Virtualiser macOS sur un Mac, tout le monde ou presque sait le faire. Même chose avec Linux... Mais iOS c'est un peu le Graal... Le truc interdit !

Sauf que des chercheurs en sécu viennent de tomber sur VPHONE600AP, un composant planqué dans le firmware Private Cloud Compute d'Apple qui permet de faire tourner iOS 26 en VM sur un simple Mac tout simplement via le Virtualization.framework. En gros, Apple a laissé traîner la clé sous le paillasson...

Pour ceux qui débarquent, Private Cloud Compute (PCC) c'est l'infrastructure serveur qu'Apple utilise pour faire tourner Apple Intelligence et bizarrement, le firmware de ces serveurs, qu'Apple appelle cloudOS, contient un composant qui n'a rien à faire là : un iPhone virtuel. VPHONE600AP, de son petit nom.

iOS 26 dans une VM sur Mac, avec le wallpaper clownfish en guise de bienvenue

C'est vrai que jusqu'ici, on pouvait faire tourner des VM sur iOS via UTM, mais dans l'autre sens c'était niet. Mais le chercheur du nom de wh1te4ever (bien connu dans le milieu du jailbreak iOS) a documenté comment exploiter ce composant dans un writeup hyper détaillé que je vous invite à lire.

La recette, c'est pas sorcier sur le papier : on prend le firmware d'un iPhone 16 sous iOS 26.1 (~8 Go à télécharger), on y greffe les éléments vphone récupérés dans cloudOS, et on patche le résultat jusqu'à ce que le tout accepte de démarrer dans une VM. En pratique, on se doute que c'est évidemment un poil plus corsé que ça mais c'est le résultat qui compte !

Côté patches, 3 niveaux de casse-tête s'offrent à vous. Le mode Regular, le plus pépère, qui se contente de 38 modifications. Le mode Development qui en empile 47. Et le mode Jailbreak avec ses 84 patches !

Le device tree du firmware vphone, aka "iPhone Research Environment Virtual Machine"

Ces patches touchent à tout ce qui empêche normalement iOS de tourner en dehors d'un vrai iPhone : le bootloader (iBSS, iBEC, LLB), la vérification du volume système (SSV bypass), le système de fichiers APFS (seal verification), et le trustcache TXM.

Et pour simplifier tout ça, un autre dev nommé Lakr233 a créé vphone-cli , un outil en ligne de commande qui automatise tout le processus. Téléchargement des firmwares, application des patches, boot de la VM... quelques commandes dans le Terminal et c'est parti. Sans cet outil, il faudrait se taper chaque patch à la main, parce que le processus complet prend une bonne vingtaine d'étapes.

Ensuite, une fois la bête lancée, trois façons d'y accéder : SSH sur le port 22222 pour bidouiller, VNC sur le 5901 si vous voulez voir l'écran, ou RPC sur le 5910. Le tout en 1179x2556, la résolution d'un iPhone 16. Pas mal pour du virtuel !

Bon, quelques conditions quand même.... il faut macOS 15 (Sequoia) minimum, désactiver SIP et AMFI via csrutil disable en mode Recovery, et surtout un Mac Apple Silicon...

Sur Mac Intel, ça ne marchera pas. Maintenant, si vous avez déjà bidouillé de la virtualisation sur Mac , ça ne devrait pas trop vous dépayser, mais comprenez bien que c'est un outil de recherche en sécurité avant tout... même si perso, tester des apps iOS sans vrai iPhone, c'est pas du luxe quand on fait mon job.

Merci à Lorenper pour le lien de vphone-cli !

Vous connaissez tous Kali Linux , Metasploit et compagnie… Mais est-ce que vous avez déjà vu une IA faire un pentest toute seule ? Genre, VRAIMENT toute seule. Shannon , c'est un framework open source qui lâche un agent IA sur votre code, et qui enchaîne recon, analyse de vulns, et exploitation, tout ça sans intervention humaine.

En gros, vous lui filez une URL cible et l'accès à votre code source (faut que le repo soit accessible, c'est la base), et l'agent se débrouille. Il commence alors par analyser le code en statique… puis lance des attaques dynamiques sur l'app en live. Pour cela, il déploie plusieurs sous-agents spécialisés qui bossent en parallèle via Temporal, un moteur de workflow.

Un agent pour la reconnaissance, un pour chercher les injections SQL, un autre pour les XSS, un pour les SSRF, un pour les problèmes d'authentification… Bref, chacun fait son taf et tout remonte dans un rapport final au format JSON.

Le truc, c'est que Shannon ne se contente pas de scanner bêtement comme un Nessus ou un Burp. L'agent COMPREND votre code. Il lit les routes, les middlewares, les requêtes SQL, et il construit ses attaques en fonction. Du coup, il trouve des trucs que les scanners classiques loupent complètement, genre une injection NoSQL planquée dans un endpoint obscur ou un bypass d'auth via un cookie mal valide. Attention par contre, si votre app utilise un framework un peu exotique ou du code obfusqué, y'a des chances que l'agent passe à côté… comme tout scanner, hein.

Pour ceux qui se demandent combien coute un test d'intrusion classique, ça va de 3 000 € à plusieurs dizaines de milliers d'euros. Shannon, c'est open source et ça tourne sur Docker, par contre, faudra compter environ 50 dollars en tokens API Anthropic par run… c'est pas gratuit mais c'est quand même 60 fois moins cher qu'un audit humain.

Cote installation, c'est Docker + Docker Compose, un fichier .env avec votre cle API Anthropic (la variable ANTHROPIC_API_KEY, classique), et hop, un docker compose up pour lancer le tout. Le workflow complet prend entre 1 h et 1 h 30 selon la taille de votre base de code. Vous pouvez suivre la progression en temps réel via l'interface web Temporal sur localhost:8233. (perso, j'aime bien voir les agents bosser en parallèle, ça a un côté satisfaisant).

Et attention, Shannon exécute de VRAIES attaques. C'est mutatif. Ça veut dire que si l'agent trouve une injection SQL, il va l'exploiter pour de vrai pour prouver que ça marche. Du coup, on le lance sur du code à soi, en local ou sur un environnement de test. Mais jamais en prod. JAMAIS !!!

Bon, sauf si vous aimez vivre dangereusement et que votre boss est en vacances… ^^

Les agents d'exploitation (Auth, SSRF, XSS, AuthZ) en parallèle sur la timeline Temporal

Pour en avoir le cœur net, je l'ai lancé sur une app Node.js/Express maison avec 27 endpoints d'API. 2 heures de scan, 287 transitions d'état, 7 agents qui ont bossé en parallèle… et une facture Anthropic qui pique un peu. Parce que oui, chaque agent consomme des tokens Claude à chaque étape d'analyse et d'exploitation, et ça s'additionne vite. Comptez une cinquantaine de dollars pour un run complet. Bref, c'est pas gratuit de se faire hacker par une IA.

Cote résultats par contre, plutôt parlant. Zero injection SQL exploitable, les 23 paramètres utilisateur ont été tracés jusqu'aux requêtes et Shannon a confirmé que tout était paramétré correctement. Bien joué. Par contre, il a détecté 6 failles SSRF liées à des contournements IPv6, des XSS stockées via innerHTML sans aucun échappement dans le frontend, et surtout… ZERO authentification sur les 27 endpoints. Genre, n'importe qui peut purger ma base ou cramer vos crédits API Claude sans se connecter. Bon après, c'est un outil que je me suis dev, qui est un proto local, donc c'est pas exposé sur internet.

Le rapport final est plutôt bien foutu, je trouve. Pour chaque vuln trouvée, vous avez la sévérité CVSS (critique, haute, moyenne), le vecteur d'attaque utilisé, une preuve d'exploitation avec les payloads, et surtout des recommandations de correction. Shannon va jusqu'à vous montrer la ligne de code fautive, expliquer pourquoi le bypass fonctionne, et proposer le fix. Si vous utilisez déjà des outils comme Sploitus pour votre veille secu, Shannon c'est le complément parfait pour passer de la théorie à la pratique sur votre propre code.

Le projet est encore jeune, c'est vrai, mais l'approche est intéressante. Plutôt que d'automatiser bêtement des scans, on a donc un agent qui raisonne sur le code et adapte sa stratégie. Ça change des outils qui balancent des milliers de requêtes à l'aveugle et qui vous noient sous les faux positifs.

Alors après, je vous vois venir, vous allez me dire : est-ce que ça vaut un vrai pentester qui connait votre infra par cœur et qui sait où chercher les trucs tordus ?

Pas vraiment, mais pour un premier audit à moindre coût, ça fait le taf.

Source

Ghidra, le framework de reverse engineering open source de la NSA, est un outil que tous les analystes sécu utilisent au quotidien pour démonter des binaires. Sauf que voilà... quand vous passez des heures à renommer des fonctions, documenter des structures et tracer des cross-references à la main, ça finit par devenir un poil répétitif.

Du coup, un développeur a eu l'idée de coller un serveur MCP (Model Context Protocol) directement sur Ghidra. "Encore un wrapper IA bidon ??"... mais non les amis car Ghidra MCP Server est un bridge Python + plugin Java qui expose pas moins de 110 outils d'analyse via le protocole MCP. Rien que ça.

Concrètement, ça veut dire que vous pouvez brancher Claude, ou n'importe quel outil compatible MCP, directement sur votre session Ghidra et lui demander de décompiler des fonctions, tracer des call graphs, renommer des variables en batch ou même créer des structures de données automatiquement.

Au niveau architecture, un plugin Java tourne dans Ghidra et expose une API REST sur localhost:8089, puis un bridge Python fait la traduction entre le protocole MCP et ces endpoints HTTP. Vous lancez Ghidra, vous activez le serveur via Tools > GhidraMCP > Start MCP Server, et hop, votre IA peut causer directement avec le décompileur.

Et c'est pas juste de la décompilation basique. Y'a de l'analyse de structures, de l'extraction de strings, du mapping mémoire complet, de la gestion de scripts Ghidra (plus de 70 scripts d'automatisation livrés avec le projet !) et même un système de documentation cross-binaire.

En gros, vous analysez un malware, vous documentez toutes les fonctions, et si vous tombez sur une variante plus tard, l'outil transfère automatiquement votre doc via un système de hash SHA-256 sur les opcodes. Plutôt chouette ! En revanche, ça marche pas si le code est fortement obfusqué... logique.

Bon, pour ceux qui connaissent déjà OGhidra (qui fait tourner des LLM en local dans Ghidra), Ghidra MCP Server c'est l'approche inverse. Au lieu d'embarquer l'IA dans Ghidra, c'est Ghidra qui s'ouvre à l'IA via un protocole standardisé. Du coup vous n'êtes pas limité à un seul modèle... Claude, GPT, Gemini, n'importe quel client MCP fait l'affaire.

Côté prérequis, faut Java 21, Maven 3.9+, Python 3.10+ et évidemment Ghidra 12.0.2. L'install se fait en quelques étapes : cloner le repo, pip install, copier les libs Ghidra dans lib/, compiler avec Maven et déployer le zip dans les extensions. Rien de bien sorcier si vous êtes déjà dans l'écosystème... sauf si vous êtes sous Windows, là faudra peut-être un peu galérer avec Maven.

Les opérations batch sont par exemple très intéressantes... Avec cette fonctionnalité, vous pouvez renommer 50 variables d'un coup, poser des commentaires sur toutes les fonctions d'un module, typer des paramètres en série.

Bref, si vous faites de l'analyse de binaires et que vous voulez arrêter de tout vous taper à la main, c'est le genre de combo reverse engineering + IA qui va vous faire gagner pas mal de temps !