C’est fou quand même qu’en 2025, les débogueurs de base comme GDB et LLDB soient toujours aussi pénibles à utiliser qu’il y a 20 ans. Par exemple faut taper x/30gx $rsp pour examiner la pile et obtenir un bloc de nombres hexadécimaux sans contexte. C’est donc super chiant pour comprendre tout ce qui se passe dans votre programme, sans être ultra concentré (et donc ultra fatigué à la fin de la journée).

Hé bien c’est exactement ce que s’est dit Zach Riggle quand il a commencé à bosser sur pwndbg (prononcez “/paʊnˈdiˌbʌɡ/”, oui comme “pound debug”). L’idée c’était de créer un plugin qui transforme ces débogueurs préhistoriques en véritables outils modernes pour les reverse engineers et les développeurs d’exploits.

Le truc avec pwndbg, c’est qu’il ne cherche pas à réinventer la roue, non, bien au contraire, puisqu’il s’appuie sur une architecture Python modulaire afin d’ajouter une couche d’intelligence par-dessus GDB et LLDB. Concrètement, ça veut dire que vous gardez toute la puissance de ces débogueurs, mais avec une interface qui ne vous donne pas envie de jeter votre clavier par la fenêtre, avant de vous y jeter vous-même ^^.

Pour l’installer, quelques lignes suffisent et hop vous aurez un environnement de debugging qui ferait pâlir d’envie les outils commerciaux.

Si vous êtes sur Linux ou macOS, la méthode la plus simple c’est la ligne magique avec curl qui va tout faire pour vous :

curl -qsL 'https://install.pwndbg.re' | sh -s -- -t pwndbg-gdb

Les utilisateurs de Mac peuvent aussi passer par Homebrew avec un simple

brew install pwndbg/tap/pwndbg-gdb

Et pour les hipsters des gestionnaires de paquets, y’a même une option avec Nix qui vous permet de tester l’outil sans rien installer en dur sur votre système. Maintenant, si vous préférez la méthode old school avec les packages classiques, pas de souci !

Récupérez le package qui correspond à votre distro sur la page des releases et installez-le avec votre gestionnaire de paquets habituel et en deux minutes chrono, vous avez votre environnement de debug GDB boosté aux stéroïdes avec toutes les fonctionnalités de pwndbg pour analyser vos binaires comme un chef.

Ensuite, que vous fassiez du débug de kernel Linux, du reverse sur des binaires ARM ou RISC-V, ou que vous développiez des exploits pour des systèmes embarqués, pwndbg saura s’adapte. Il gère même le debugging avec QEMU pour l’émulation user-space. Par contre, petit bémol pour les utilisateurs macOS, le debugging natif de binaires Mach-O n’est pas supporté avec GDB… Pour le moment, seul le debugging distant ELF fonctionne.

Un des aspects les plus cools de pwndbg, c’est son approche “consistency first”. Que vous utilisiez GDB ou LLDB, l’expérience reste cohérente. Vous pouvez donc switcher entre les deux débogueurs sans avoir à réapprendre tous les raccourcis et commandes. Bon, le support LLDB est encore expérimental et peut contenir quelques bugs, mais ça progresse vite.

Les développeurs low-level, les hardware hackers et les chercheurs en sécurité sont les premiers à adore pwndbg parce qu’au lieu de vous noyer sous des informations inutiles, il affiche exactement ce dont vous avez besoin à savoir le contexte des registres, l’état de la pile, le code désassemblé avec coloration syntaxique, et même une vue hexdump digne de ce nom (oui, en 2025, les débogueurs de base n’ont toujours pas ça par défaut).

Le projet est sous licence MIT, donc vous pouvez l’utiliser dans n’importe quel contexte, commercial ou non et si vous voulez contribuer, comme d’hab avec la plupart des projets que je vous présente, la porte est grande ouverte.

Pour ceux qui veulent se lancer, il y a même un cheatsheet complet à imprimer et garder sous la main. Parce que bon, même avec une interface aux petits oignons, un bon aide-mémoire reste toujours utile quand on débugge des trucs complexes à 3h du matin.

Au final, pwndbg c’est la preuve qu’on n’a pas toujours besoin de réinventer complètement un outil pour le rendre génial. Parfois, il suffit juste d’ajouter la bonne couche d’abstraction au bon endroit.

Encore bravo à Zach Riggle et son équipe ont vraiment tapé dans le mille !!

Il y a des moments où on tombe sur une approche si simple et efficace qu’on se demande pourquoi on n’y avait pas pensé avant. C’est exactement ce que j’ai ressenti en découvrant la technique d’Armin Ronacher pour donner à Claude Code le contrôle total d’une session de debugging.

Le principe c’est de combiner GNU Screen, ce vieux multiplexeur de terminal que certains considèrent comme dépassé, avec LLDB, le debugger de LLVM, pour créer un environnement où Claude peut littéralement piloter votre terminal comme s’il était assis devant votre clavier.

Comme ça, au lieu d’implémenter des serveurs MCP complexes ou des intégrations cheloues, Ronacher s’appuie sur des outils qui existent depuis des décennies. GNU Screen permet de multiplexer un terminal physique entre plusieurs processus, créant des sessions persistantes qui survivent aux déconnexions SSH. C’est cette persistance qui devient la clé de voûte du système.

Dans sa démonstration vidéo, Ronacher montre donc comment il configure Claude Code pour automatiser complètement une session de debugging. Le secret tient dans quelques lignes ajoutées au fichier CLAUDE.md : “définir un nom de session Screen spécifique pour le debugging, utiliser la syntaxe “dollar string” pour envoyer des commandes, et fermer proprement la session une fois terminé”.

Claude peut alors créer la session, lancer LLDB, identifier un bug de type segfault, le corriger, recompiler le code et vérifier que tout fonctionne. Le tout sans intervention humaine.

Comme le souligne Ronacher dans ses recommandations, Claude Code excelle quand on lui donne accès à des outils bien documentés qu’il connaît déjà. Screen et LLDB font partie de ces outils sur lesquels il existe une montagne de documentation et d’exemples donc Claude peut les manipuler avec aisance. En tout cas, beaucoup plus que moi, c’est certain !

Mais au-delà du debugging, cette technique ouvre des perspectives fascinantes pour l’automatisation. On pourrait imaginer un Claude gérant vos sessions tmux pour orchestrer des déploiements multi-serveurs, surveillant des logs en temps réel via Screen pour détecter des anomalies, ou même maintenant des connexions SSH persistantes vers des serveurs pour des interventions d’urgence. J’avoue c’est toujours prendre un risque donc à éviter sur de la prod, mais c’est très cool quand même.

Surtout que les sessions Screen continuent de fonctionner même quand la fenêtre n’est pas visible. C’est ça qui permet à Claude de maintenir des processus longs sans monopoliser votre terminal.

Si vous faites du DevOps, vous pourriez configurer Claude pour qu’il lance automatiquement des sessions Screen lors de debugging de containers Docker, maintienne des tunnels SSH persistants pour du debugging à distance de Kubernetes, ou même gère des sessions de monitoring avec des dashboards textuels comme htop ou glances. La combinaison de la persistance de Screen et de l’intelligence de Claude crée un assistant capable de gérer des workflows complexes de manière autonome.

C’est vrai que Screen est souvent considéré comme obsolète face à tmux, mais dans ce cas précis, sa simplicité devient un avantage car Claude a probablement plus de données d’entraînement sur Screen, qui existe depuis 1987, que sur des alternatives plus modernes. Donc c’est smooooth pour lui…

Un autre cas d’usage intéressant serait la gestion de sessions de développement complexes durant lesquelles Claude pourrait maintenir plusieurs fenêtres Screen avec différents environnements : une pour les tests, une pour le serveur de développement, une pour les logs, et naviguer entre elles selon les besoins. Vous pourriez ainsi demander à Claude de lancer les tests et de vous montrer les logs en cas d’échec, et il orchestrerait tout via Screen.

Pour les équipes, cette technique pourrait vraiment renforcer le pair programming à distance…. Vous partagez une session Screen avec Claude et un collègue simultanément et Claude pourrait vous assister en temps réel, suggérer des corrections, exécuter des commandes de diagnostic, pendant que vous discutez de l’architecture avec votre collègue avec un petit kawa. C’est comme avoir un 3e collègue expert toujours dispo.

Pas besoin d’API, de webhooks, ou de services cloud… Juste des outils Unix standard que tout développeur a déjà sur sa machine et un bon prompt et hop ça fait des chocapics (ou plus de bugs…^^) !

Bref, parfois les solutions les plus belles sont aussi les plus simples. Pas besoin de réinventer la roue…