
Vollständig dockerisierte Linux-Kernel-Debugging-Umgebung
LIKE-DBG (LInux-KErnel-DeBuGger) zielt darauf ab, die langweiligen Schritte zu automatisieren, die beim Einrichten einer Linux-Kernel-Debugging-Umgebung anfallen. Ich habe mich auf den Weg gemacht, in die Kernel-Exploitation-Forschung einzutauchen, und fand bestehende Lösungen nicht ausreichend nutzbar. Daher ist dies ein Versuch, alle notwendigen Vorbereitungsschritte, bevor man überhaupt ans Eintauchen in die Forschung denken kann, so schmerzlos und unterhaltsam wie möglich zu gestalten. Alle Schritte – vom Bauen eines Kernels über das Ausführen in einer emulierten Umgebung bis hin zum Anhängen eines Debuggers – werden transparent in Docker-Containern durchgeführt, um die Systemanforderungen minimal zu halten. Derzeit gibt es für jeden der folgenden Schritte einen eigenen Docker-Container:
Da sich dieses Projekt in einem frühen Stadium befindet, erwarte ich, dass sich Dinge schnell ändern und dabei auch inkompatible Änderungen eingeführt werden. Die wichtigsten Punkte, die es zu verbessern gilt, sind:
x86_64 und arm64 hinausPositiv ist, dass trotz des frühen Stadiums bereits einige nützliche Funktionen vorhanden sind:
configs/user.ini-Konfiguration, die hochgradig anpassbare Sitzungen ermöglicht
ctf/misc, das einige raffinierte Skripte für CTFs beherbergtx86_64, arm64gcc und clang wählen, um den Kernel zu bauenUm zu beginnen, musst du sicherstellen, dass die folgenden Voraussetzungen auf deinem System eingerichtet sind:
dockertmuxpython>=3.11poetry # https://python-poetry.org/docs/Es wird empfohlen, dies nicht als root-Benutzer auszuführen, z. B. zu Testzwecken auf einem VPS.
Es mag zwar funktionieren, aber grundsätzlich empfehle ich dringend, einen dedizierten Nicht-Root-Benutzer anzulegen und ihn in die Gruppen docker und sudo aufzunehmen!
Hinweis: Wenn du eine benutzerdefinierte TMUX-Konfiguration verwendest, stelle sicher, dass dein erster Pane bei 0 beginnt!
Dieser Abschnitt behandelt Werkzeuge, die nicht benötigt werden, um LIKE-DBG auszuführen, die aber schön zu haben sind und beim Debugging oder beim Schreiben eines Exploits sehr helfen.
Führe innerhalb von like-dbg poetry install aus.
Die Feinabstimmung des Kernel-Debugging-Erlebnisses ist eines der Ziele dieses Projekts.
Derzeit sind alle einstellbaren Optionen in den beiden Konfigurationsdateien configs/system.ini und configs/user.ini verfügbar.
Einige Felder sollten idealerweise nicht verändert werden, da sie hauptsächlich aus Entwicklungsgründen vorhanden sind.
Allerdings sollten all diejenigen, die zum Anpassen der Umgebung an deine Bedürfnisse dienen, selbsterklärend sein, da alle mit einem kurzen Kommentar versehen sind.
Hinweis: Führe bei der ersten Verwendung poetry install aus.
Sobald du mit dem Schreiben/Anpassen einer Konfiguration fertig bist, hängt die Verwendung von deinem Szenario ab.
Der einfachste Einstieg, der auf der Konfiguration configs/user.ini basiert, ist der folgende:
tmux -f .tmux.conf
poetry shell
# This checks out a kernel, builds it, creates a root file system and starts the debugger and debuggee eventually
./start_kgdb.py
Für die automatisch erstellten Dateisysteme gibt es 2 Benutzer:
root ohne Passwortuser:userDies ist beabsichtigt, damit du aus beiden Perspektiven sowohl entwickeln als auch Exploits schreiben kannst.
# If you want to try a CTF challenge where you were given a (compressed) Linux Image and a root filesystem try:
./start_kgdb.py --ctf <Image> <RootFS>
# If you want to kill the current debugging session
./start_kgdb.py -k
# If you want to provide a custom 'user.ini' for a specific debugging setup
./start_kgdb.py -c <path_to_cfg> [other_args]
# If you want to test some partial functionality of LIKE-DBG
# Stage 1: Download Kernel
# Stage 2: Stage 1 & unpack Kernel
# Stage 3: Stage 2 & build Kernel
# Stage 4: Only build a root file system
# Stage 5: Stage 3+4 & start debuggee
./start_kgdb.py -p <stage_nr>
# Update all containers
./start_kgdb.py -u
Das Unterverzeichnis examples enthält Beispiele dafür, wie LIKE_DBG dich bei bestimmten Kernel-Debugging-Aufgaben unterstützen kann.
Jedes Beispiel enthält außerdem eine eigene README.md mit den notwendigen Informationen, um die Beispiele zu reproduzieren.

Der Python-Code sollte recht lesbar sein. Zögere also nicht, das Projekt mit deinen eigenen Ideen zu erweitern. Alle PRs sind sehr willkommen :)! Ansonsten erstelle gern ein Issue mit Feature-Request oder schau auf der Diskussionsseite vorbei, um coole neue Funktionen zu brainstormen!
PS: Wenn du ein Logo beisteuern möchtest, tu das gern.
configs/*.ini-Dateien.io/scripts/gdb_script anzugeben, um ein auf das Szenario zugeschnittenes Debugging-Erlebnis zu erhalten