LIKE-DBG

LIKE-DBG (LInux-KErnel-DeBuGger) ist ein vollständig containerisiertes Labor zum Debuggen und Ausnutzen des Linux-Kernels. Es baut oder übernimmt einen Kernel und ein Root-Dateisystem, startet sie unter QEMU und versetzt dich in eine interaktive GDB-Sitzung (pwndbg oder GEF), wobei alle Komponenten in einem einzigen tmux-Fenster zusammengeführt werden.

Der Sinn besteht darin, das langweilige Setup zu beseitigen, damit deine Zeit dem Kernel und nicht dem Gerüst zugutekommt. Jeder Schritt läuft in Docker, sodass du auf dem Host nur Docker, tmux, Python und uv installieren musst. Wähle eine Kernel-Version (oder übergib ihm eine CTF-Challenge), führe einen Befehl aus und lande mit vollständigen Symbolen bei start_kernel.

Was es tut

Ein einziger Befehl löst deine Konfiguration auf, baut oder verwendet einen Kernel und ein Rootfs wieder, startet den Gast und hängt den Debugger an:

uv run ./start_kgdb

Der Lauf ist eine Schleife, in der du bleibst: Baue oder übernimm einen Kernel und ein rootfs, boote ihn unter QEMU (dem Debuggee), hänge GDB an (den Debugger), dann bearbeite, liefere aus, führe aus, stürze ab, finde die Ursache und wiederhole.

Es gibt zwei Wege, einen Kernel zu bekommen:

• Baue deinen eigenen. Wähle eine Version, ein Debug-Profil und einen Compiler; LIKE-DBG lädt ihn herunter, konfiguriert und baut ihn einmal und cached ihn dann. Dies ist der tägliche Begleiter für Kernel-Studium und Exploit-Entwicklung. Siehe docs/build-your-own-kernel.md.
• Bringe einen CTF- oder fremden Kernel mit. Übergib ihm das bzImage/Image einer Challenge (plus vmlinux und initramfs, falls du sie hast), und es bootet dieses unverändert unter GDB. Siehe docs/ctf-foreign-kernel.md.

Highlights

• Läuft auf macOS und Linux, Host automatisch erkannt. Apple Silicon bootet arm64-Gäste mit nativer HVF-Beschleunigung; x86_64 auf dem Mac und Linux ohne KVM fallen auf TCG im Container zurück; Linux mit KVM nutzt dieses. Speicher, Beschleunigung und Netzwerk werden pro Host gewählt und pro Lauf aufgezeichnet.
• Architekturen: x86_64 und arm64.
• TOML-Konfiguration mit Debug-Profilen. Ein geschichteter TOML-Stack (Projekt-Standardwerte, persönliche lokale Überschreibungen, benannte Szenarien, CLI) plus benannte Profile (exploit-dev, hardened, kasan, ubsan, lockdep und weitere), die zu Kernel-Konfigurationsfragmenten und Laufzeit-Standardwerten aufgelöst werden. Die .config-Verifikation nach dem Build erkennt ein Profil, das nicht gegriffen hat. Beachte, dass exploit-dev (der Standard) nur KASLR deaktiviert; SMEP, SMAP und KPTI bleiben aktiv, es sei denn, du wechselst das Profil oder schaltest sie selbst um (siehe docs/configuration.md).
• Moderner Debugger. Kernel-Läufe verwenden standardmäßig pwndbg wegen seines Kernel-Befehlssatzes (KASLR-Basis, Slab, current, Task- und Modul-Durchlauf, Symbolsuche); GEF ist ein Einzeiler-Wechsel.
• Exploit-Dev-Inner-Loop. --run und --upload liefern ein Exploit an den laufenden Gast über eine 9p-Freigabe oder SSH. Eine einzelne flag-lose .c-Datei wird automatisch statisch mit musl für die Zielarchitektur kompiliert; alles andere wird unverändert ausgeliefert. Siehe exploit/README.md.
• Benutzerdefinierte Module. Baue Out-of-Tree-Module gegen den laufenden Kernel und lade sie auf Befehl mit --insmod und --rmmod; ihre Symbole werden automatisch in GDB geladen. Siehe modules/README.md.
• Crash-Intelligenz. Eine byte-exakte serielle Konsolen-Senke, ein Parser für Panic/Oops/KASAN/UBSAN und ein Auto-Break, der GDB am Fehler mit einem symbolisierten Backtrace anhält. --analyze-crash erzeugt einen Bericht offline neu.
• Parallele Sitzungen. Jeder Boot erhält seine eigene tmux-Sitzung, benannt nach dem, was sie debuggt, seine eigenen Host-Ports und sein eigenes Copy-on-Write-rootfs-Overlay, sodass zwei Challenges nebeneinander debuggt werden können und --run/--insmod immer im Gast landen, aus dessen Pane du sie eingegeben hast.
• Lauf-Artefakte. Jede Sitzung schreibt ein zeitgestempeltes artifacts/runs/<id>/ mit aufgelösten Einstellungen, Host-Profil, Befehlsaufzeichnungen, Logs und Pane-Transkripten.

Voraussetzungen

• Docker
• tmux
• Python 3.12 oder neuer
• uv

Führe es als Nicht-Root-Benutzer in der Gruppe docker aus. Cross-Kompilierung und initramfs-Arbeiten finden in Containern statt (eine zig cc-musl-Toolchain), sodass keine Host-Cross-Toolchain benötigt wird.

Schnellstart

# 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

Der erste Lauf baut die Container-Images und einen Kernel, daher dauert er eine Weile; spätere Läufe verwenden den Cache und starten in Sekunden.

Jeder Boot benennt seine Sitzung nach dem, was gerade debuggt wird (LIKE-DBG-pawnyable-lk01, LIKE-DBG-6_6_30-exploit-dev), sodass eine laufende Sitzung nie die nächste blockiert und zwei Challenges nebeneinander debuggt werden können. Mit C-b d abkoppeln; tmux -L likedbg ls zeigt, was läuft, und das = unten ist tmux' Form für exakte Übereinstimmung (ohne es kann eine -2-Sitzung gewinnen):

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

Lesen Sie von hier aus docs/build-your-own-kernel.md für den vollständigen Workflow oder docs/ctf-foreign-kernel.md, wenn Sie eine Challenge zum Debuggen haben. Für eine praktische Tour durch den gesamten Ablauf anhand eines mitgelieferten verwundbaren Treibers folgen Sie der LK01-Walkthrough.

Dokumentation