LIKE-DBG

LIKE-DBG (LInux-KErnel-DeBuGger) è un laboratorio completamente containerizzato per il debug e lo sfruttamento del kernel Linux. Compila o adotta un kernel e un root filesystem, li avvia sotto QEMU e ti porta in una sessione GDB interattiva (pwndbg o GEF), collegando ogni componente in un'unica finestra tmux.

L'obiettivo è eliminare la noiosa fase di configurazione, così il tuo tempo va al kernel, non all'impalcatura. Ogni passaggio viene eseguito all'interno di Docker, quindi le uniche cose da installare sull'host sono Docker, tmux, Python e uv. Scegli una versione del kernel (oppure passagli una challenge CTF), esegui un solo comando e arrivi a start_kernel con tutti i simboli disponibili.

Cosa fa

Un solo comando risolve la tua configurazione, compila o riutilizza un kernel e un rootfs, avvia il guest e collega il debugger:

uv run ./start_kgdb

Il ciclo di lavoro è un loop in cui rimani: compili o adotti un kernel e una rootfs, lo avvii sotto QEMU (il Debuggee), colleghi GDB (il Debugger), poi modifichi, consegni, esegui, provochi il crash, individui la causa e ripeti.

Ci sono due modi per ottenere un kernel:

• Compilare il proprio. Scegli una versione, un profilo di debug e un compilatore; LIKE-DBG lo scarica, lo configura e lo compila una volta, poi lo mette in cache. È lo strumento quotidiano per lo studio del kernel e lo sviluppo di exploit. Vedi docs/build-your-own-kernel.md.
• Portare un kernel CTF o esterno. Gli passi il bzImage/Image di una challenge (più vmlinux e initramfs se li hai) e lo avvia così com'è sotto GDB. Vedi docs/ctf-foreign-kernel.md.

Punti salienti

• Funziona su macOS e Linux, con rilevamento automatico dell'host. Apple Silicon avvia guest arm64 con accelerazione HVF nativa; x86_64 su Mac e Linux senza KVM ricadono su TCG in container; Linux con KVM lo utilizza. Storage, accelerazione e networking vengono scelti per host e registrati per ogni esecuzione.
• Architetture: x86_64 e arm64.
• Configurazione TOML con profili di debug. Uno stack TOML a livelli (default di progetto, override locali personali, scenari con nome, CLI) più profili con nome (exploit-dev, hardened, kasan, ubsan, lockdep e altri) che si risolvono in frammenti di configurazione del kernel e default di runtime. La verifica post-build del .config intercetta un profilo che non è stato applicato. Nota che exploit-dev (il default) disattiva solo KASLR; SMEP, SMAP e KPTI restano attivi a meno che tu non cambi profilo o li disattivi manualmente (vedi docs/configuration.md).
• Debugger moderno. Le esecuzioni del kernel usano pwndbg per impostazione predefinita per il suo set di comandi kernel (base KASLR, slab, current, task e module walking, symbol lookup); GEF è un cambio da una riga.
• Ciclo interno exploit-dev. --run e --upload consegnano un exploit al guest live tramite una condivisione 9p o SSH. Un singolo .c senza flag viene compilato automaticamente static-musl per l'architettura target; qualsiasi altra cosa viene consegnata così com'è. Vedi exploit/README.md.
• Moduli personalizzati. Compila moduli out-of-tree rispetto al kernel in esecuzione e caricali su comando con --insmod e --rmmod; i loro simboli si caricano automaticamente in GDB. Vedi modules/README.md.
• Crash intelligence. Un sink della console seriale byte-exact, un parser per panic/oops/KASAN/UBSAN e un auto-break che blocca GDB al fault con un backtrace simbolizzato. --analyze-crash rigenera un report offline.
• Sessioni concorrenti. Ogni avvio ottiene la propria sessione tmux nominata in base a ciò che esegue il debug, le proprie porte host e il proprio overlay rootfs copy-on-write, così due challenge possono essere debuggate fianco a fianco e --run/--insmod finiscono sempre nel guest dal cui pannello li hai digitati.
• Artefatti di esecuzione. Ogni sessione scrive un artifacts/runs/<id>/ con timestamp contenente impostazioni risolte, profilo host, record dei comandi, log e trascrizioni dei pannelli.

Requisiti

• Docker
• tmux
• Python 3.12 o superiore
• uv

Esegui come utente non-root nel gruppo docker. La cross-compilazione e il lavoro sull'initramfs avvengono all'interno dei container (una toolchain musl zig cc), quindi non serve alcuna cross-toolchain sull'host.

Avvio rapido

# 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

La prima esecuzione compila le immagini del container e un kernel, quindi richiede tempo; le esecuzioni successive riutilizzano la cache e partono in pochi secondi.

Ogni avvio rinomina la propria sessione in base a ciò che sta debuggando (LIKE-DBG-pawnyable-lk01, LIKE-DBG-6_6_30-exploit-dev), così una sessione lasciata in esecuzione non blocca mai la successiva e due challenge possono essere debuggate affiancate. Scollegati con C-b d; tmux -L likedbg ls mostra cosa è in esecuzione, e il = qui sotto è la forma di corrispondenza esatta di tmux (senza di essa, una sessione -2 può avere la meglio):

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

Da qui, leggi docs/build-your-own-kernel.md per il flusso di lavoro completo, oppure docs/ctf-foreign-kernel.md se hai una challenge da debuggare. Per un tour pratico dell'intero ciclo su un driver vulnerabile incluso, segui la LK01 walkthrough.

Documentazione