LIKE-DBG

LIKE-DBG (LInux-KErnel-DeBuGger) est un laboratoire entièrement conteneurisé de débogage et d'exploitation du noyau Linux. Il construit ou adopte un noyau et un système de fichiers racine, les démarre sous QEMU et vous place dans une session GDB interactive (pwndbg ou GEF), en connectant chaque élément dans une seule fenêtre tmux.

L'objectif est de supprimer la configuration fastidieuse afin que votre temps soit consacré au noyau, et non à l'échafaudage. Chaque étape s'exécute dans Docker, de sorte que les seuls éléments à installer sur l'hôte sont Docker, tmux, Python et uv. Choisissez une version du noyau (ou fournissez-lui un challenge CTF), exécutez une seule commande, et arrivez à start_kernel avec tous les symboles.

Ce qu'il fait

Une seule commande résout votre configuration, construit ou réutilise un noyau et un rootfs, démarre l'invité et attache le débogueur :

uv run ./start_kgdb

Le cycle est une boucle dans laquelle vous restez : construire ou adopter un noyau et un rootfs, le démarrer sous QEMU (le Debuggee), attacher GDB (le Debugger), puis éditer, livrer, exécuter, provoquer un crash, identifier la cause racine et recommencer.

Il existe deux façons d'obtenir un noyau :

• Construire le vôtre. Choisissez une version, un profil de débogage et un compilateur ; LIKE-DBG le télécharge, le configure et le compile une fois, puis le met en cache. C'est l'outil quotidien pour l'étude du noyau et le développement d'exploits. Voir docs/build-your-own-kernel.md.
• Apporter un noyau CTF ou étranger. Fournissez-lui le bzImage/Image d'un challenge (ainsi que vmlinux et initramfs si vous les avez) et il démarre celui-ci tel quel sous GDB. Voir docs/ctf-foreign-kernel.md.

Points forts

• Fonctionne sur macOS et Linux, hôte détecté automatiquement. Apple Silicon démarre des invités arm64 avec l'accélération native HVF ; x86_64-sur-Mac et Linux sans KVM se rabattent sur TCG en conteneur ; Linux avec KVM l'utilise. Le stockage, l'accélération et le réseau sont choisis par hôte et enregistrés par exécution.
• Architectures : x86_64 et arm64.
• Configuration TOML avec profils de débogage. Une pile TOML en couches (valeurs par défaut du projet, surcharges locales personnelles, scénarios nommés, CLI) plus des profils nommés (exploit-dev, hardened, kasan, ubsan, lockdep, et d'autres) qui se résolvent en fragments de configuration du noyau et en valeurs par défaut d'exécution. La vérification post-compilation du .config détecte un profil qui n'a pas pris effet. Notez que exploit-dev (le profil par défaut) ne désactive que KASLR ; SMEP, SMAP et KPTI restent activés sauf si vous changez de profil ou les basculez vous-même (voir docs/configuration.md).
• Débogueur moderne. Les exécutions du noyau utilisent par défaut pwndbg pour son ensemble de commandes noyau (base KASLR, slab, current, parcours des tâches et modules, recherche de symboles) ; GEF s'active en une ligne.
• Boucle interne de développement d'exploit. --run et --upload livrent un exploit à l'invité en cours d'exécution via un partage 9p ou SSH. Un unique fichier .c sans option est automatiquement compilé en static-musl pour l'architecture cible ; tout le reste est livré tel quel. Voir exploit/README.md.
• Modules personnalisés. Compilez des modules hors arborescence contre le noyau en cours d'exécution et chargez-les à la demande avec --insmod et --rmmod ; leurs symboles se chargent automatiquement dans GDB. Voir modules/README.md.
• Intelligence des crashes. Un collecteur de console série fidèle à l'octet près, un analyseur de panic/oops/KASAN/UBSAN, et un point d'arrêt automatique qui piège GDB au moment du défaut avec une pile d'appels symbolisée. --analyze-crash régénère un rapport hors ligne.
• Sessions concurrentes. Chaque démarrage obtient sa propre session tmux nommée d'après ce qu'elle débogue, ses propres ports hôtes et sa propre surcouche rootfs copy-on-write, de sorte que deux challenges peuvent être débogués côte à côte et que --run/--insmod aboutissent toujours dans l'invité depuis le panneau duquel vous les avez tapés.
• Artefacts d'exécution. Chaque session écrit un artifacts/runs/<id>/ horodaté avec les paramètres résolus, le profil de l'hôte, les enregistrements de commandes, les journaux et les transcriptions des panneaux.

Prérequis

• Docker
• tmux
• Python 3.12 ou plus récent
• uv

Exécutez en tant qu'utilisateur non-root dans le groupe docker. La compilation croisée et le travail sur l'initramfs s'effectuent à l'intérieur de conteneurs (une chaîne d'outils musl zig cc), donc aucune chaîne d'outils croisée sur l'hôte n'est nécessaire.

Démarrage rapide

# 1. Install dependencies
uv sync

# 2. Start the project tmux server (loads the shipped .tmux.conf)
tmux -L likedbg -f .tmux.conf new -s LIKE-DBG

# 3. Inside that tmux session: build-or-reuse a kernel, boot it, attach the debugger
uv run ./start_kgdb

Le premier lancement construit les images de conteneur et un noyau, ce qui prend un certain temps ; les lancements suivants réutilisent le cache et démarrent en quelques secondes.

Chaque démarrage renomme sa session d'après ce qu'elle débogue (LIKE-DBG-pawnyable-lk01, LIKE-DBG-6_6_30-exploit-dev), ainsi une session laissée en cours ne bloque jamais la suivante et deux défis peuvent être débogués côte à côte. Détachez-vous avec C-b d ; tmux -L likedbg ls affiche ce qui est en cours d'exécution, et le = ci-dessous est la forme de correspondance exacte de tmux (sans lui, une session -2 peut l'emporter) :

tmux -L likedbg attach -t =LIKE-DBG-6_6_30-exploit-dev

À partir d'ici, lisez docs/build-your-own-kernel.md pour le flux de travail complet, ou docs/ctf-foreign-kernel.md si vous avez un challenge à déboguer. Pour une visite pratique de toute la boucle sur un pilote vulnérable fourni, suivez le tutoriel LK01.

Documentation