Faire tourner un modèle de langage en local sur son PC, avec llama.cpp, ça marche très bien, mais ça demande quand même de mettre un peu les mains dans le cambouis. Il faut aller chercher le binaire, trouver le bon fichier GGUF sur Hugging Face et lancer le serveur en ligne de commande.

Heureusement, léquipe de ggml-org, celle qui développe justement llama.cpp, souhaite soulager notre peine en nous proposant pour Windows 11 une petite app baptisée Llama (Ouais, c'est original comme nom ^^) qui se loge dans la zone de notification et qui fait tout le taf à votre place.

C'est en fait un portage pour Windows de Llama for Mac , qui est lui aussi dans la barre des menus de macOS. Côté install, suffit de récupérer le fichier .msixbundle dans les Releases du dépôt, vous double-cliquez dessus, et c'est parti mon kiki. Si vous avez déjà un llama.exe sur votre machine, l'app s'en servira, sinon elle en téléchargera un toute seule. Et bien sûr, le code est sous licence MIT, avec un petit copyright au nom de Hugging Face quand même.

Une fois que c'est en place, l'icône ouvre un petit panneau de commande avec une liste de modèles recommandés à télécharger en un clic. Vous pouvez aussi chercher n'importe quel modèle GGUF du Hub directement depuis cette liste, ou coller l'identifiant d'un dépôt. L'app vérifie également au passage s'il vous reste assez de place sur le disque avant de lancer le téléchargement ! (Moi j'ai 4 To et je suis toujours PLEIN, j'en ai marre ^^)

Bref... en cliquant sur un modèle, vous choisissez sa taille de contexte, et pour chaque option, l'app vous donne une estimation de la mémoire consommée, qu'elle récupère dans l'en-tête du fichier GGUF. C'est très pratique pour savoir avant de le lancer si ça va tenir dans votre fichue machine. Et comme les modèles sont stockés dans le cache standard de Hugging Face, bah ils sont partagés avec llama.cpp et les autres outils qui l'utilisent, ce qui évite d'avoir des doublons de plusieurs gigas sur le disque.

Mais le truc le plus sympa, je crois c'est le raccourci Alt+Espace qui, peu importe ce que vous êtes en train de faire, ouvre une fenêtre avec l'interface web du chat IA près à vous répondre, un peu à la manière de Spotlight sur Mac. Et quand vous la refermez, hé bien elle se planque simplement au lieu de se fermer ce qui fait qu'elle se réaffiche instantanément avec votre conversation dès que vous en avez besoin.

Par contre, dommage, ce raccourci est codé en dur et il n'y a aucun réglage pour en changer. Donc si une autre app squatte déjà Alt+Espace, comme PowerToys Run dont c'est le raccourci par défaut, hé bien Llama vous prévient mais ça n'ira pas plus loin. A moins que vous changiez le raccourci par défaut de PowerToys Run .

Côté vie privée, Llama n'envoie aucune data de télémétrie et vos prompts restent sur votre machine. Et comme l'app pilote un serveur llama.cpp qui expose une API REST, la fiche d'un modèle vous proposera même une requête curl toute prête afin de brancher vos autres outils dessus.

Attention si Smart App Control est activé sur votre PC, il se peut que Windows bloque llama.exe, qui n'est pas signé (contrairement au paquet MSIX de l'app). Dans ce cas, le serveur ne démarrera pas et l'app ne servira à rien. Si vous êtes concerné, il faudra donc patienter ou contourner Smart App Control.

À télécharger sur GitHub pour ceux qui veulent !

REA , pour "Reverse Engineer Anything", c'est un serveur MCP qui buzze ces derniers jours et qui permet de connecter votre agent IA (Claude Code, Codex, Cursor...) sur Ghidra, Hopper ou IDA, et sur des analyseurs pour les applis Electron, .NET ou les sites web.

Vous repérez ainsi une fonction qui vous plaît dans une appli, puis l'agent la décortique sans le code source et vous en code une version toute fraiche... Tiens ça me rappelle quelque chose...

Comme je voulais voir ce que ça donnait, je me suis donc monté un petit banc d'essai à l'arrache sur mon ordi avec Claude Code en Opus 5.5, REA 6.4.0 comme seul serveur MCP et Ghidra comme moteur.

Mes tests se découpent donc en 4 exercices : un keygen, un patch, une fonction d'appli à recréer ainsi que des codes de triche. Pour les deux premiers, j'ai bien sûr compilé des programmes maison avec un faux système de licence afin de ne pas sombrer dans l'illégalité en codant un vrai keygen ou un crack (et au passage me faire delete mon compte Anthropic ^^).

rea doctor valide Ghidra 12.1.4

Mon crackme, c'est donc une fausse app nommée "PixelNote Pro" qui réclame un nom d'utilisateur et une clé d'activation, compilé pour Mac ARM.

Une fois que je lui ai dis ce que je voulais faire, l'agent a donc ouvert le binaire dans Ghidra via REA, lu le pseudo-code, l'a recoupé avec l'assembleur là où le décompilateur écrivait une rotation de bits sous une forme peu lisible, et m'a pondu un keygen en Python en 2 minutes chrono pour un coût API de Claude 50 centimes. J'ai ensuite fait tourner son générateur sur 479 noms tirés au hasard et le binaire les a tous acceptés.

Le crackme ouvert à la main dans Ghidra : la fonction entry et son pseudo-code

La boucle de calcul de la clé, dans le pseudo-code que REA sert à l'agent

Le patch, c'est le plus bluffant j'ai trouvé. Le petit utilitaire que je me suis fait a pour mission de compter les lignes et les mots d'un fichier texte. C'est très basique. Et j'ai donc voulu faire un patch pour qu'il affiche aussi les caractères. Comme REA, avec Ghidra, ne touche pas aux octets de l'exécutable, l'agent a donc dû faire le reste à la main... il a logé ses instructions dans une zone remplie de zéros de la partie exécutable, détourné trois instructions d'origine vers elles, puis re-signé le binaire pour que macOS le lance :

Le compteur d'origine, sa version patchée par l'agent, puis le keygen du crackme accepté par le binaire

Pour mon 3ème exercice, je me suis dit que j'allais cloner la fonction d' Amphetamine qui garde mon Mac éveillé tant qu'une appli donnée est ouverte. Via Ghidra, malheureusement REA a refusé le binaire universel Intel et ARM d'Amphetamine, alors l'agent en a extrait lui-même la partie ARM. Il a alors trouvé qu'Amphetamine posait une assertion d'énergie du système et surveillait la liste des applis lancées. Et magie de l'IA, il a ensuite codé en Swift un petit outil qui fait tout pareil. J'ai testé avec la Calculatrice, ça marche, à condition de lui donner le nom de l'appli dans la langue du système, ou son identifiant.

pmset ne montre l'assertion d'éveil que pendant que la Calculatrice est ouverte

Et le dernier, c'est Wolfenstein 3D (j'ai pris la version shareware 1.4) dont l'exécutable DOS est compressé. L'agent a donc écrit son propre décompresseur, puis retrouvé dans le code le raccourci clavier pour tricher (c'est M+L+I qui met santé à 100, munitions, clés, mitrailleuse... et score remis à zéro), le paramètre goobers qui, avec Maj gauche + Alt + Retour arrière, débloque les touches de debug comme le mode Dieu, et même un juke-box caché. Tout correspond au code source publié depuis par id Software.

Par contre, ses logs montrent qu'il cherchait ces codes par leur nom avant de les avoir vus. Je me suis donc fait avoir puisque le modèle les connaissait déjà. Par contre, il les a bien retrouvé dans le binaire.

Début de partie du shareware 1.4 dans DOSBox, lancé avec le paramètre goobers

Les trois occurrences de goobers dans l'exécutable décompressé

Alors, REA est-il indispensable ?

Hé bien pour le savoir, j'ai relancé les quatre exercices avec le même modèle, les mêmes fichiers et les mêmes consignes, mais avec REA en moins... juste Claude Code qui pilote Ghidra. Hé bien Claude tout nu a tout réussi lui aussi, mais en écrivant quand il en avait besoin ses propres scripts Ghidra en Java, là où REA lui servait le pseudo-code et l'assembleur sur un plateau.

Bref, ce que je peux vous dire avec mes tests, c'est que REA ne fait pas mieux qu'un Claude à qui on demande d'installer Ghidra et de l'utiliser. Par contre, REA a été plus rapide sur le keygen (2 minutes 22 contre 2 minutes 48 pour Claude), sur Amphetamine (9 minutes contre 16 minutes pour Claude) et sur Wolfenstein (10 contre 14 pour Claude), mais plus lent sur le patch (7 minutes et demie contre un peu plus de 2 pour Claude).

A voir ce que ça donnerait avec un modèle local genre Qwen (débloqué avec Heretic , alleeeez)...

REA est sous licence MIT et l'analyse tourne en local (même si ses résultats partent quand même chez le fournisseur de votre modèle, donc évitez d'y passer un binaire confidentiel), et Hopper comme IDA restent des outils commerciaux dont REA ne fournit aucune licence.

Notez aussi que son créateur exclut le contournement de licences et la fabrication de patchs pour les jeux, d'où encore une fois mon crackme fait maison et les codes qu'id a lui-même mis dans Wolfenstein ^^.

Autre précaution à prendre si vous vous lancez et qui touche cette fois à la fiabilité de ce que l'agent IA peut vous raconter : Des chercheurs ont publié fin mai un préprint montrant qu'un binaire piégé peut donner ses propres ordres à l'IA qui l'analyse . Pour cela, il suffit d'y glisser des chaînes de texte sans effet à l'exécution, qui se retrouvent ensuite dans le code décompilé et soufflent de fausses instructions au modèle, pour lui faire mal interpréter le programme. Je n'ai pas testé REA là-dessus, mais le principe vaut a priori pour tout agent branché sur Ghidra, donc faites bien attention avant de donner un échantillon suspect à votre agent IA préféré.

Et si seul Ghidra vous intéresse, sachez que le ce MCP dont je vous ai parlé en février permet aussi de faire le pont agent IA <> Ghidra.

Voilà, pour installer REA, un petit :

npx rea-agents setup

Et c'est parti !