Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
like-dbg — Vollständig dockerisierte Linux-Kernel-Debugging-Umgebung | Kitploit
Tools/GitHubGitHub/0xricksanchez/like-dbg
ExploitationDebuggerFuzzingCTFBinary-Exploitation
GitHub0xricksanchez/like-dbg

like-dbg

Vollständig dockerisierte Linux-Kernel-Debugging-Umgebung

Repository anzeigen
77057vor 1 MonatVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

LIKE-DBG

Code style: black Build Status: flake8 Build Status: shellcheck Build Status: hadolint codecov License: MIT GitHub Release

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:

  • Bauen des Kernels
  • Erstellen eines Root-Dateisystems zur Verwendung mit dem Kernel
  • Starten des Kernels + Dateisystems als Debuggee
  • Anhängen an den Kernel als Debugger

Einschränkungen

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:

  • Annäherung an eine echte Multi-Architektur-Unterstützung über x86_64 und arm64 hinaus
  • Den Kernel-Builder erweitern, damit er nicht nur aktuelle™ Kernel erfolgreich baut
  • Android-Kernel-Support hinzufügen
  • (Integrations-)Tests hinzufügen
  • Das Debugging-Erlebnis noch weiter verbessern

Funktionen

Positiv ist, dass trotz des frühen Stadiums bereits einige nützliche Funktionen vorhanden sind:

  • Allgemein:
    • Minimale Host-Systemanforderungen dank Dockerisierung jedes Schritts
    • Eine leicht verständliche configs/user.ini-Konfiguration, die hochgradig anpassbare Sitzungen ermöglicht
      • Oder über die Befehlszeile verschiedene Konfigurationen für unterschiedliche Debugging-Setups bereitstellen!
    • Ein CTF-Runner, der speziell dafür entwickelt wurde, Linux-Kernel-Exploitation-Challenges zu bewältigen
      • ctf/misc, das einige raffinierte Skripte für CTFs beherbergt
    • Maßnahmen zur Codequalität:
      • black-Formatierer für Python-Code
      • flake8-Linter für den gesamten Python-Code
      • shellcheck-Linter für Shell-Skripte
      • hadolint-Linter für die Dockerfiles
    • Betriebssystemunabhängig, d. h. es sollte problemlos auf Folgendem laufen:
      • Debian/Ubuntu
      • Arch Linux/Manjaro
      • Fedora
  • Kernel-Builder:
    • Multi-Arch: x86_64, arm64
    • Zwischen gcc und clang wählen, um den Kernel zu bauen
    • Konfigurationsmodi:
      • generischer Modus (generic-mode),
      • Syzkaller-Modus,
      • benutzerdefinierter Modus (custom-mode) oder
      • Bereitstellen einer nutzbaren Kernel-Konfiguration
    • Feingranulare Versionsauswahl zum Bauen von:

Voraussetzungen

Um zu beginnen, musst du sicherstellen, dass die folgenden Voraussetzungen auf deinem System eingerichtet sind:

  • docker
  • tmux
  • python>=3.11
  • poetry # 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!

Optional

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.

  • musl-gcc
  • ctags
  • ropr

Einrichtung

Führe innerhalb von like-dbg poetry install aus.

Konfiguration

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.

Verwendung

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:

root@kitploit:~
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 Passwort
  • user:user

Dies ist beabsichtigt, damit du aus beiden Perspektiven sowohl entwickeln als auch Exploits schreiben kannst.

Erweiterte Verwendung

root@kitploit:~
# 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

Beispiele

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.

Showcase

img/example.png

Hacking

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.

Tool herunterladen
  • Commit-Hash
  • Release-Tag (z. B.: 5.10-rc)
  • Major-Minor-Patch (z. B.: 5.10.77)
  • Möglichkeit, Patch-Dateien automatisch anzuwenden
  • Grundlegende Möglichkeit, benutzerdefinierte Kernel-Module hinzuzufügen
  • Root-Dateisystem-Builder:
    • Basiert auf debootstrap
    • Automatische Erzeugung eines Dateisystems, das zur Architektur des Kernels passt
    • Anpassungsmöglichkeiten:
      • gewünschte Pakete im Dateisystem
      • die Debian-Release-Version, auf der alles basieren soll
  • Debuggee:
    • Basiert auf QEMU
    • Anpassung der QEMU-Laufzeitoptionen in den configs/*.ini-Dateien.
  • Debugger:
    • Basiert auf GDB (multiarch) mit entweder
      • GEF und GEF-extras oder
      • pwndbg
    • Ermöglicht es Benutzern, ein GDB-Skript in io/scripts/gdb_script anzugeben, um ein auf das Szenario zugeschnittenes Debugging-Erlebnis zu erhalten