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 !

Vous connaissez le concept de clé maître ? Hé bien Rasmus Moorats, un chercheur en sécurité estonien, vient d'en trouver une qui déverrouille l'intégralité du parc de scooters électriques Äike. Et vous vous en doutez, c'est pas vraiment ce que le fabricant avait prévu.

Le bougre a décidé de reverse-engineerer son propre deux-roues connecté après que la boîte ait fait faillite en 2025. Logique, quand le cloud menace de fermer, autant comprendre comment fonctionne sa bécane. Du coup il a décompilé l'app React Native, hooké les communications Bluetooth avec Frida, et là... surprise !

L'authentification entre l'app et l'engin utilise un système de challenge-response. Le scooter envoie un défi aléatoire, l'app le concatène avec une clé secrète, hash le tout en SHA-1, et renvoie le résultat. Simple et efficace. Sauf que la clé secrète en question, c'est FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF. Vingt octets de FF.

Vous l'aurez peut-être compris, c'est la valeur par défaut du SDK fourni par le fabricant du module IoT.

Bref, les devs d'Äike n'ont jamais personnalisé cette clé. Chaque scooter sorti d'usine embarque exactement la même. Du coup avec un script Python et la lib bleak, n'importe qui peut déverrouiller n'importe quel Äike qui passe dans la rue. Hop, on scanne, on répond au challenge avec la clé universelle, et on envoie les commandes : déverrouiller, activer le mode éco, ouvrir le compartiment batterie... tout y passe.

Le plus rigolo dans l'histoire c'est que la société sœur Tuul, qui fait de la location de trottinettes, n'a pas de Bluetooth sur ses engins ! Du coup elle n'est pas touchée. Comme quoi, parfois l'absence de fonctionnalité devient une feature de sécurité.

Évidemment, Rasmus a fait les choses proprement avec une disclosure responsable en septembre dernier. Le fabricant a alors confirmé que c'était bien leur faute, et pas celle du fournisseur du module. Mais bon, maintenant que la boîte a coulé, les correctifs risquent d'attendre looongtemps.

Source

Moi je pensais qu'un lave-linge c'était juste... un lave-linge. On tourne le bouton, le bouton tout rond, et paf, ça lave... Mais aujourd'hui ces bestioles sont bourrées d'électronique et connectées à fond au cloud. Et forcément, ça a donné des idées à deux chercheurs allemands qui ont présenté leurs travaux au 39C3 (Chaos Communication Congress).

Severin von Wnuck-Lipinski et Hajo Noerenberg ont passé des mois à décortiquer les entrailles de machines Miele et BSH (Bosch, Siemens, Neff, Gaggenau) et leurs découvertes sont super intéressantes pour qui s'intéresse notamment au droit à la réparation et à la domotique (sans dépendre du cloud).

Côté Miele, Severin a découvert que la plupart des machines fabriquées après 1996 embarquent une interface de diagnostic optique. Un petit port infrarouge planqué sur la façade qui permet aux techniciens de se connecter avec un outil proprio appelé MDU (Miele Diagnostic Utility). Le protocole c'est du bon vieux UART à 2400 bauds avec parité paire. Pas de chiffrement mais juste une clé de sécurité à 16 bits.

Et c'est là que ça devient croquant à souhait car pour trouver ces clés de diagnostic, Severin a exploité une faille de timing sur le microcontrôleur 8 bits. En gros, quand vous envoyez une mauvaise clé, le microcontrolleur met un tout petit peu plus de temps à répondre que quand le premier octet est correct. En mesurant ces délais avec un oscilloscope, il a pu deviner les clés octet par octet.

Et c'est grâce à cela qu'il a créé FreeMDU , un outil open source qui permet de dialoguer avec les appareils Miele et compatibles. Diagnostics, codes erreur, compteurs de cycles... tout est accessible et y'a même une intégration Home Assistant pour les fans de domotique DIY.

Côté BSH, Hajo a attaqué le D-BUS, le bus de communication propriétaire qui relie tous les composants internes (moteur, pompe, interface utilisateur, module WiFi). C'est également du UART à 9600 bauds sur des connecteurs RAST, avec une tension de bus de 9V pour les lave-linge et 13.5V pour les lave-vaisselle.

Le plus beau c'est qu'en fouillant le firmware du module timeline (celui qui gère l'affichage du temps restant), Hajo a trouvé des easter eggs planqués par les développeurs dans les graphiques. Comme quoi même les ingénieurs Bosch ont le sens de l'humour ^^.

Suite à ça, Hajo a développé bsh-home-appliances , un projet open source avec une extension ESPHome pour intégrer les appareils BSH dans Home Assistant. Vous pouvez donc suivre votre cycle de lavage, recevoir des notifications, et même accéder aux diagnostics sans passer par l'app proprio.

Et le final de la présentation était épique puisque les deux chercheurs ont connecté un lave-linge Miele à l'application BSH Home Connect via une couche de compatibilité maison qu'ils ont baptisée AMBCL (Advanced Miele BSH Compatibility Layer). Un Miele qui parle le Bosch, ça c'est fait !

Bref, si vous avez un appareil Miele ou BSH qui traîne et que vous voulez reprendre le contrôle sans dépendre du cloud du fabricant, les outils sont maintenant disponibles. C'est ça aussi le droit à la réparation : pouvoir diagnostiquer soi-même sa machine sans appeler un technicien à 150 euros de l'heure.

Par contre, bidouillez vos propres appareils uniquement parce que faire ça sur le lave-linge de votre meilleur pote, c'est pas cool et c'est illégal, alors fézez pas les cons !

Source

Les vieux de la vieille connaissent forcement Cheat Engine puisque c'est LE logiciel culte pour tripatouiller la mémoire des jeux , trouver l'adresse où est stockée votre santé, votre or, vos munitions, et la modifier à la volée. Sauf que manuellement, c'est un travail de fourmi... Trouver un pointeur stable qui ne change pas à chaque redémarrage du jeu, ça peut prendre des jours, voire des semaines de bidouillage.

Hé bien quelqu'un a eu l'idée un peu folle de brancher Claude directement sur Cheat Engine et visiblement le résultat est au rendez-vous.

Le projet s'appelle cheatengine-mcp-bridge et c'est un pont entre les IA compatibles MCP (Claude, Cursor, Copilot) et Cheat Engine. Concrètement, ça veut dire que vous pouvez maintenant demander à Claude de faire le boulot de reverse engineering à votre place, en langage naturel.

Dans cet outil, y'a trois couches qui communiquent ensemble : l'IA qui reçoit vos questions en langage humain, un serveur Python qui traduit tout ça en commandes techniques, et un script Lua côté Cheat Engine qui exécute les opérations sur le processus ciblé.

Et les possibilités sont dingues puisque l'outil expose pas moins de 39 "tools" MCP différents. Vous pouvez lire la mémoire (entiers, floats, strings, pointeurs), suivre des chaînes de pointeurs complexes du genre [[base+0x10]+0x20]+0x8, scanner des valeurs, analyser du code désassemblé, identifier des objets C++ via les infos RTTI, et même poser des breakpoints hardware. Il y a même le support du DBVM, le mode hyperviseur de Cheat Engine qui permet un traçage niveau Ring -1 , beaucoup plus difficile à détecter pour les protections anti-cheat classiques.

Avec ce MCP, vous lancez un jeu, vous demandez à Claude "Scanne l'or, j'en ai 15000". L'IA trouve alors 47 résultats. Vous dépensez un peu d'or dans le jeu, vous dites "Maintenant j'en ai 14900". Claude filtre et garde 3 adresses. Ensuite vous demandez "C'est quoi qui écrit sur la première adresse ?", et hop, breakpoint hardware posé automatiquement. Ensuite, un petit "Désassemble moi cette fonction", et vous avez tout le code de la fonction AddGold devant les yeux.

Tout ce processus qui prenait des heures de tatonnement se fait maintenant en mode conversation.

SpaghettiKart est sorti en juin dernier et c’est le portage sur PC / Switch de Mario Kart 64, signé HarbourMasters. Si ce nom vous dit quelque chose, c’est normal, car ce sont les mêmes qui ont porté Zelda Ocarina of Time avec Ship of Harkinian, Zelda Majora’s Mask avec 2Ship2Harkinian, et Star Fox 64 avec Starship . Quatre jeux N64 majeurs portés avec la même méthode, ce n’est plus du bricolage. Ils ont industrialisé le portage N64, je pense !

Et la clé, c’est libultraship . Il s’agit d’une lib qui permet d’éviter le gros du boulot technique pour porter des jeux N64 vers des plateformes modernes. Grâce à ça, chaque nouveau portage devient un projet de quelques mois au lieu de plusieurs années. Ship of Harkinian a défriché le terrain et maintenant, le pipeline est bien rodé.

Le fonctionnement de SpaghettiKart est simple. Vous lui fournissez votre ROM Mario Kart 64 US légale, vous générez un fichier O2R avec l’outil fourni, et vous lancez le jeu ! SpaghettiKart tourne sur Windows, Linux, macOS (pas de binaire dispo encore) et même Nintendo Switch. Comme les backends graphiques supportent DirectX11, OpenGL et Metal, c’est multiplateforme dès le départ.

Et les fonctionnalités sont celles que Nintendo devrait proposer, mais ne propose pas comme le support ultrawide et 4K, une fréquence d’images élevées, de l’antialiasing, un niveau de détails poussé au max et des contrôles personnalisables. Y’a même la possibilité de mettre vos assets customs et d’éditer des circuits donc autant dire que les moddeurs vont se régaler…etc. Bref, tout ce que Mario Kart 64 aurait dû devenir si Nintendo y avait mis 1 % de l’énergie qu’ils mettent à envoyer des DMCA .

Voici l’histoire de Pixelmelt, un développeur qui voulait simplement sauvegarder en local un ebook acheté sur Amazon pour le lire avec une autre app parce que l’app Kindle d’Android a crashé une fois de trop à son goût.

Mais c’est impossible. Pas de bouton download, pas d’export, que dalle… Même si vous avez acheté le livre, c’est Amazon qui décide de comment et de quand vous pouvez le lire.

Bref, frustré, il se tourne alors vers le Kindle Cloud Reader, la version web de l’app. Et là, il découvre un truc incroyable ! Amazon a créé un système d’obfuscation tellement complexe qu’il ressemble aux techniques de cryptographie des manuscrits anciens. Mais siii, vous savez, ces textes enluminés que seuls les moines pouvaient déchiffrer au Moyen-Âge. Amazon a réinventé le concept en version numérique.

Pour fonctionner, le Kindle Cloud Reader utilise un endpoint de rendu qui nécessite plusieurs tokens d’authentification. Déjà c’est pas simple. Mais ça se corse un peu plus quand on regarde le texte qui s’affiche car ce ne sont pas des lettres ! Ce sont des glyphes, essentiellement des séries de coordonnées qui dessinent une lettre. Ainsi, au lieu de stocker le caractère ‘T’, Amazon stocke “glyphe 24” qui correspond à une forme dessinée via des commandes SVG. Et ces glyphes changent de mapping toutes les 5 pages, un peu comme un codex (coucou Dan Brown ^^) où l’alphabet se transforme à tous les chapitres.

Du coup, pour son livre de 920 pages, il a fallu faire 184 requêtes API distinctes. Chaque requête récupère un nouveau jeu de glyphes soit au total 361 glyphes uniques découverts, et 1 051 745 glyphes à décoder. Oui, ça fait plus d’un million de symboles à traduire pour lire un seul livre.

Amazon a même ajouté des pièges comme des micro-opérations MoveTo complètement inutiles dans les SVG qui s’affichent parfaitement dans le navigateur mais cassent toute tentative de parsing automatique. C’est de l’anti-scraping placé là volontairement, comme des fausses pistes dans des cryptogrammes médiévaux destinées à tromper les copistes non autorisés.

Face à ce délire, notre développeur est alors devenu malgré lui un crypto-archéologue. Sa méthode a donc été de comparer pixel par pixel chaque caractères, valider chaque hypothèse, pour tout reconstruire patiemment. Je vous passe les détails techniques mais il a sorti chaque glyphe SVG sous la forme d’une image, puis a comparé ces images pour trouver leur correspondance avec les vraies lettres en utilisant un outil (SSIM) qui simule la perception humaine pour évaluer la similarité entre deux images.

Résultat, 100% des glyphes matchés ont un score quasi-parfait ce qui lui a permis de reconstruire un fichier EPUB complet avec le formatage, les styles, les liens internes…etc. Tout y est, c’est trop fort !

Bref, Pixelmelt 1 - Amazon 0 ! Et ça, ça fait plaisir ! Maintenant si vous voulez connaitre tous les détails de ça et refaire la même chez vous (pour rigoler hein, ne vous lancez pas dans dans une opération de piratage massif sinon vous finirez en taule comme Sarko ^^)

Tous les mardis soir, c’est la même chose dans le petit monde de la cybersécurité : Microsoft balance ses patches, et dès le mercredi matin, c’est la ruée vers l’or pour les experts sécu. Bienvenue dans l’univers déjanté de l’Exploit Wednesday, où des chercheurs du monde entier se transforment en cyber-archéologues pour y déterrer les vulnérabilités avant que les méchants ne s’en emparent afin de coder des exploits.

Et un nouvel outil vient de débarquer pour pimenter cette course folle : Diffrays .

Imaginez… il est 3h du matin, on est mercredi et pendant que vous dormez tranquillement, des milliers de chercheurs en sécurité sont déjà en train de comparer frénétiquement les binaires de Windows fraîchement patchés avec leurs versions vulnérables.

Pourquoi est-ce qu’ils font ça ? Hé bien c’est parce que chaque seconde compte. L’IA a réduit de 40% le temps nécessaire pour identifier une vulnérabilité à partir d’un patch et ce qui prenait des jours prend maintenant des heures, notamment aux cybercriminels, du coup, la course s’est transformée en sprint.

Et c’est là que Diffrays entre en scène. Cet outil, conçu par pwnfuzz, fait ce qu’on appelle du “patch diffing”. Pour les non-initiés, le patch diffing, c’est l’art de comparer deux versions d’un programme pour trouver ce qui a changé. Un peu comme comparer deux photos pour jouer au jeu des 7 différences, sauf que là, on cherche des bugs qui valent potentiellement des millions.

Pour cela, Diffrays utilise IDA Pro et sa nouvelle IDA Domain API pour extraire le pseudocode des fonctions et les comparer de manière structurée. Et ce n’est un vulgaire comparateur de texte…non… Diffrays génère en fait une base de données SQLite complète avec toutes les différences trouvées, et lance même un serveur web local pour naviguer dans les résultats. Vous tapez diffrays diff old.exe new.exe, puis diffrays server --db-path results.sqlite, et hop, vous avez une jolie interface web sur http://localhost:5555 pour explorer ces changements.

Grâce à cet outil, chacun peut savoir exactement comment Microsoft corrige ses bugs. Prenez par exemple l’analyse du driver Clfs.sys montrée dans la documentation de Diffrays . Les chercheurs ont téléchargé deux versions du driver. La première vulnérable (10.0.22621.5037) et la seconde patchée (10.0.22621.5189) puis ont laissé Diffrays faire son travail… Et en quelques minutes, l’outil a identifié exactement quelles fonctions avaient été modifiées et comment.

Évidemment, Diffrays n’est pas seul sur ce marché juteux. Google a son BinDiff , il y a aussi Diaphora, et maintenant même des outils boostés à l’IA comme DeepDiff qui convertissent le code en “embeddings” (des représentations mathématiques) pour trouver des similarités. Mais Diffrays a un avantage, il est open source, gratuit, et surtout, il est conçu spécifiquement pour la recherche. Pas de conneries marketing, juste du code qui fait le taf.

D’ici 2026 , les experts prédisent que le patch diffing assisté par IA sera la norme dans toutes les red teams et programmes de bug bounty. On parle même de plateformes de diffing en temps réel avec des bases de données de vulnérabilités crowdsourcées.

Voilà, donc si vous voulez vous lancer dans ce genre d’analyses comparatives de binaires, sachez que Diffrays est sur GitHub , et qu’il est prêt à transformer vos mercredis matins en séances de fouilles intensives. Et n’oubliez pas… avec un grand pouvoir vient une grande responsabilité ! Sinon, c’est la zonzon, comme pour Sarko !

Microsoft vient de lever le voile sur un truc assez cool : Project IRE !

C’est un agent IA qui analyse et détecte les malwares en parfait autonomie. Plus besoin d’un expert humain pour décortiquer chaque fichier suspect, c’est l’IA qui s’en charge et elle le fait plutôt bien avec 98% de précision et seulement 2% de faux positifs sur un dataset de drivers Windows.

C’est du lourd car au lieu de se contenter d’une simple analyse par signatures comme les antivirus classiques, Project IRE fait de la vraie reverse engineering. L’agent décompile le code, reconstruit le graphe de flux de contrôle (control flow graph pour les intimes), analyse chaque fonction et génère un rapport détaillé expliquant pourquoi le fichier est malveillant ou non.

Pour faire tout ça, Microsoft s’appuie sur Azure AI Foundry et des outils de reverse engineering bien connus comme angr et Ghidra. Le processus commence ainsi par un triage automatique pour identifier le type de fichier et sa structure. Ensuite, l’IA reconstruit comment le programme s’exécute, analyse chaque fonction avec des modèles de langage spécialisés et compile tout dans une “chaîne de preuves” (chain of evidence).

Cette transparence est cruciale car elle permet aux équipes de sécurité de vérifier le raisonnement de l’IA et comprendre comment elle est arrivée à ses conclusions. Et surtout, les tests en conditions réelles sont prometteurs car sur 4000 fichiers que les systèmes automatisés de Microsoft n’arrivaient pas à classifier, Project IRE a correctement identifié 89% des fichiers malveillants avec seulement 4% de faux positifs.

Le seul bémol c’est le taux de détection global qui n’est que de 26%, ce qui signifie que l’IA rate encore pas mal de malwares. Mais comme le soulignent les chercheurs, cette combinaison de haute précision et faible taux d’erreur montre un vrai potentiel pour un déploiement futur.

Mike Walker, Research Manager chez Microsoft, raconte que dans plusieurs cas où l’IA et l’humain n’étaient pas d’accord, c’est l’IA qui avait raison. Ça montre bien que les forces complémentaires de l’humain et de l’IA peuvent vraiment améliorer la protection. Pour valider ses trouvailles, Project IRE utilise un outil de validation qui vérifie les affirmations du rapport contre la chaîne de preuves.

Cet outil s’appuie sur des déclarations d’experts en reverse engineering de l’équipe Project IRE et en combinant ces preuves et son modèle interne, le système produit un rapport final et classe le fichier comme malveillant ou bénin. L’objectif à terme est ambitieux puisqu’il s’agit de détecter automatiquement de nouveaux malwares directement en mémoire, à grande échelle.

Ce serait vraiment cool d’identifier des menaces avancées (APT) sans qu’un humain ait besoin d’intervenir. D’ailleurs, Project IRE a déjà réussi à créer le premier cas de conviction pour un malware APT chez Microsoft, sans aide humaine.

Pour l’instant, ça reste un prototype qui sera intégré plus tard dans Microsoft Defender comme outil d’analyse binaire mais les implications sont déjà énormes car les malwares deviennent de plus en plus sophistiqués et nombreux, et avoir une IA capable de les analyser automatiquement pourrait changer pas mal la lutte contre ces saloperies.

Alors oui, on n’est pas encore au point où l’IA remplace complètement les experts en sécurité mais on s’en rapproche et vu la pénurie de talents en cybersécurité et l’explosion du nombre de menaces, c’est plutôt une bonne nouvelle.

Source

Vous connaissez Rust, ce langage de programmation dont tout le monde dit le plus grand bien ? Mais si, c’est celui qui est censé révolutionner la sécurité informatique grâce à sa gestion ultra-safe de la mémoire ?

Bah figurez-vous que les pirates informatiques l’ont aussi compris, et ils s’en servent maintenant pour créer des malwares encore plus vicieux…

Quand Mozilla a pondu Rust y’a quelques années, l’idée était géniale : créer un langage qui éliminerait enfin tous ces bugs de corruption mémoire qui pourrissent la vie des développeurs depuis des décennies. Fini les buffer overflows, les use-after-free et autres joyeusetés qui permettent aux pirates de prendre le contrôle de nos systèmes. En théorie, c’était parfait…

Si vous vous intéressez au reverse engineering comme moi, permettez-moi de vous présenter FLARE-VM de Mandiant ! C’est un outil très pratique pour vous monter rapidement un petit labo d’analyse de malwares sans vous prendre la tête.

Concrètement, FLARE-VM est une jolie brochette de scripts d’installation pour Windows, basés sur deux technos bien badass : Chocolatey (un gestionnaire de paquets) et Boxstarter (un outil pour scripter des installs et configurer des environnements reproductibles). Bref, ça mâche le boulot et ça permet d’installer tout un tas d’outils et les configurer proprement en quelques minutes.

Bon, avant de se lancer, faut quand même checker deux-trois prérequis. Déjà, n’oubliez pas que FLARE-VM est prévu pour tourner sur une VM, donc préparez-en une bien propre (Windows 10+ de préférence) sur VMWare ou Virtualbox par exemple. Ensuite, vérifiez que vous avez bien au moins 60 Go d’espace disque et 2 Go de RAM. Et pensez à désactiver les mises à jour Windows et l’antivirus, sinon ça risque de faire des misères.

Ouvrez ensuite une invite PowerShell en tant qu’administrateur et téléchargez le script d’installation installer.ps1 sur votre bureau à l’aide de la commande suivante :

(New-Object net.webclient).DownloadFile('https://raw.githubusercontent.com/mandiant/flare-vm/main/install.ps1',"$([Environment]::GetFolderPath("Desktop"))\install.ps1")

Débloquez le script d’installation :

Unblock-File .\install.ps1

Puis activez son exécution :

Set-ExecutionPolicy Unrestricted -Force

Si vous recevez un message d’erreur indiquant que la stratégie d’exécution est remplacée par une stratégie définie à une portée plus spécifique, vous devrez peut-être passer une portée via Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force. Pour afficher les stratégies d’exécution pour toutes les portées, exécutez Get-ExecutionPolicy -List.

Enfin, exécutez le script d’installation comme ceci :

.\install.ps1

Pour passer votre mot de passe en argument :

.\install.ps1 -password <mot_de_passe>

Pour utiliser le mode CLI uniquement avec un minimum d’interaction utilisateur :

.\install.ps1 -password <mot_de_passe> -noWait -noGui

Pour utiliser le mode CLI uniquement avec un minimum d’interaction utilisateur et un fichier de configuration personnalisé :

.\install.ps1 -customConfig <config.xml> -password <mot_de_passe> -noWait -noGui

Une fois lancée, l’installation va télécharger et installer tous les outils sélectionnés, configurer les variables d’environnement, épingler des raccourcis sur la barre des tâches, etc. Bref, en quelques clics, vous obtiendrez un environnement de reverse engineering aux petits oignons, prêt à l’emploi pour désosser du malware !

Après l’installation, il est recommandé de passer en mode de réseau host-only et de prendre un instantané de la machine virtuelle. Vous pouvez ensuite personnaliser votre environnement FLARE VM en fonction de vos besoins spécifiques :

• Mettez à jour les outils et les logiciels installés pour vous assurer que vous disposez des dernières versions.
• Configurez les paramètres réseau selon vos préférences, par exemple en passant en mode NAT ou en mode pont si nécessaire.
• Installez des outils ou des utilitaires supplémentaires qui pourraient être utiles pour votre flux de travail d’analyse.
• Personnalisez les paramètres de l’interface utilisateur et les préférences selon vos goûts.

Et c’est parti mon kiki !

Après, si vous voulez aller plus loin et contribuer à l’amélioration de FLARE-VM, jetez un œil aux repos GitHub du projet :

• Le script d’installation et la configuration
• Le dépôt des packages d’outils

Happy reverse à tous ! 🚀

ReverserAI est un projet de recherche assez avant-gardiste qui vise à automatiser et améliorer les tâches de reverse engineering grâce à l’utilisation de modèles de langage locaux (LLM).

Fonctionnant entièrement hors ligne, cette première version se distingue par sa capacité à suggérer automatiquement des noms de fonctions de haut niveau et sémantiquement significatifs à partir de la sortie du décompilateur. ReverserAI se présente également comme un plugin pour Binary Ninja, mais son architecture modulaire est conçue pour être étendue à d’autres plateformes comme IDA ou encore Ghidra.

Et bien que les LLM locaux n’égalent pas encore les performances de leurs concurrents basés sur le cloud comme ChatGPT4 ou Claude3, ils représentent une avancée majeure avec un bon équilibre entre les performances et la confidentialité.

Parmi les fonctionnalités clés de cet outil, on retrouve :

• Un fonctionnement totalement hors ligne, ce qui garantit la confidentialité et la sécurité des données
• La suggestion automatique de noms de fonctions sémantiquement significatifs à partir de la sortie du décompilateur
• Une intégration transparente avec Binary Ninja via un plugin dédié
• Une architecture modulaire permettant une extension facile vers d’autres outils d’ingénierie inverse
• Une compatibilité avec le matériel grand public, y compris les architectures Apple Silicon

Cependant, une configuration matérielle avec plusieurs cœurs CPU ou un GPU puissant est recommandée, car sur un système avec au moins 16 Go de RAM et de 12 cœurs CPU, les requêtes prennent environ 20 à 30 secondes. Grâce aux optimisations GPU, en particulier sur les appareils Apple Silicon, ce temps peut être réduit à 2 à 5 secondes par requête.

Ça s’installe à l’aide du gestionnaire de plugins de Binary Ninja et une fois lancé, l’outil téléchargera automatiquement le modèle de langage nécessaire (~5 Go). Les paramètres de configuration permettent également d’optimiser les performances en fonction de votre configuration matérielle, en répartissant la charge entre le CPU et le GPU.

Cet outil encore un peu jeune, est un excellent proof of concept qui illustre bien le potentiel des LLM locaux pour tout ce qui est reverse engineering. On verra évidemment ce que ça deviendra d’ici quelques années.

Le code source est disponible sur GitHub à l’adresse suivante alors n’hésitez pas à suggérer des améliorations.

Happy hacking à tous !

Vous avez déjà entendu parler de Choplifter ? Non, c’est PÔ PÔSSIBLE puisque c’est l’un des jeux vidéo les plus mythiques de l’Apple II ! Sorti en 1982, année glorifiée par ma naissance, ce classique de Dan Gorlin a marqué toute une génération de gamers avec un gameplay novateur et son scrolling horizontal révolutionnaire pour l’époque.

Pour mieux comprendre l’importance de Choplifter, il faut connaître un peu l’histoire de l’Apple II. Cette série d’ordinateurs, commercialisée de 1977 à 1993, a vu la création de centaines de milliers de logiciels, dont des dizaines de milliers de jeux. Parmi tous ceux là, seuls quelques-uns sont alors vraiment marquants, et Choplifter figure assurément en tête de liste aux côtés d’autres classiques comme Lode Runner. Ce qui est particulièrement impressionnant avec ce jeu, c’est sa longévité puisqu’il est resté l’un des meilleurs jeux sur Apple II pendant seize ans, malgré la sortie de jeux étonnants comme Knights of Legend et Space Rogue vers la fin de la vie de cette machine.

Mais comment cet œuvre a-t-elle été codée ?

C’est la question que s’est posée Quinn Dunki, développeuse et hackeuse de talent qui armée de ses outils et de sa curiosité, elle s’est lancée dans une rétro-ingénierie complète de Choplifter, pour en décortiquer les mécanismes internes et percer tous ses secrets ! Elle a donc passé 8 semaines intenses à désassembler, analyser et commenter le code source de ce jeu culte.

La première chose qui saute aux yeux, c’est avant tout l’incroyable prouesse technique réalisée par Dan Gorlin à l’époque. Rappelons qu’on est en 1982, l’Apple II est encore jeune, les outils de développement sont rudimentaires et malgré tout cela, ce génie a réussi à tirer le maximum de la machine en exploitant astucieusement ses capacités graphiques et sonores. Choplifter intègre des innovations folles pour l’époque : des sprites animés pixel par pixel, de la rotation et de l’inclinaison des hélicos en temps réel, un scrolling horizontal fluide et des collisions parfaitement gérées. Tout cela avec un processeur 8 bits cadencé à 1 MHz et 48 Ko de RAM, vous vous rendez compte ?

Une autre prouesse du jeu est la qualité de son game design. Dan Gorlin a passé un temps fou à peaufiner le gameplay, à équilibrer la difficulté et à rendre le pilotage fun et accessible. Les mécanismes sous le capot sont d’une finesse incroyable et Quinn a pu retracer les choix et les astuces du développeur, tel que son système de vecteurs pour passer les paramètres aux fonctions et ses algorithmes de tri des entités pour gérer le rendu dans le bon ordre.

Parmi les découvertes les plus étonnantes, on trouve un moteur 3D maison que Dan avait commencé à coder pour gérer la rotation des sprites. Oui, de la 3D sur Apple II en 1982 ! Bien que cette fonctionnalité n’ait pas été utilisée dans la version finale, elle témoigne de l’avant-gardisme du dev.

En plus de décortiquer le code, Quinn a également réussi l’exploit de recompiler le jeu pour obtenir un binaire à l’octet près identique à l’original. Elle a même découvert un petit bug dans les listes chaînées que Dan cherchait probablement à l’époque!

Pour les passionnés de technologie et de culture geek que vous êtes, je vous invite à découvrir les coulisses d’un monument du jeu vidéo et à vous familiariser avec le développement 6502 old-school en allant lire l’autopsie de Choplifter sur le blog de Quinn Dunki. C’est un voyage fascinant dans l’univers de la programmation des années 80.

Le code source complet de Choplifter est également sur GitHub.