LIKE-DBG

LIKE-DBG (LInux-KErnel-DeBuGger) es un laboratorio de depuración y explotación del kernel de Linux totalmente contenedorizado. Compila o adopta un kernel y un sistema de archivos raíz, los arranca bajo QEMU y te deja en una sesión interactiva de GDB (pwndbg o GEF), conectando cada pieza en una única ventana de tmux.

El objetivo es eliminar la configuración aburrida para que tu tiempo se dedique al kernel, no al andamiaje. Cada paso se ejecuta dentro de Docker, así que lo único que instalas en el host es Docker, tmux, Python y uv. Elige una versión del kernel (o pásale un reto de CTF), ejecuta un comando y aterriza en start_kernel con todos los símbolos.

Qué hace

Un solo comando resuelve tu configuración, compila o reutiliza un kernel y un rootfs, arranca el invitado y adjunta el depurador:

uv run ./start_kgdb

El ciclo es un bucle en el que permaneces: compilar o adoptar un kernel y rootfs, arrancarlo bajo QEMU (el Debuggee), adjuntar GDB (el Debugger), y luego editar, entregar, ejecutar, provocar el fallo, analizar la causa raíz y repetir.

Hay dos formas de obtener un kernel:

• Compila el tuyo propio. Elige una versión, un perfil de depuración y un compilador; LIKE-DBG lo descarga, lo configura y lo compila una vez, y luego lo almacena en caché. Esta es la opción habitual para el estudio del kernel y el desarrollo de exploits. Consulta docs/build-your-own-kernel.md.
• Trae un kernel de CTF o externo. Pásale el bzImage/Image de un reto (además de vmlinux e initramfs si los tienes) y lo arranca tal cual bajo GDB. Consulta docs/ctf-foreign-kernel.md.

Aspectos destacados

• Funciona en macOS y Linux, con detección automática del host. Apple Silicon arranca invitados arm64 con aceleración nativa HVF; x86_64 en Mac y Linux sin KVM recurren a TCG en contenedor; Linux con KVM lo utiliza. El almacenamiento, la aceleración y la red se eligen según el host y se registran por ejecución.
• Arquitecturas: x86_64 y arm64.
• Configuración TOML con perfiles de depuración. Una pila TOML por capas (valores predeterminados del proyecto, anulaciones locales personales, escenarios con nombre, CLI) más perfiles con nombre (exploit-dev, hardened, kasan, ubsan, lockdep y más) que se resuelven en fragmentos de configuración del kernel y valores predeterminados en tiempo de ejecución. La verificación posterior a la compilación del .config detecta un perfil que no se aplicó. Ten en cuenta que exploit-dev (el predeterminado) solo desactiva KASLR; SMEP, SMAP y KPTI permanecen activos a menos que cambies de perfil o los alternes tú mismo (consulta docs/configuration.md).
• Depurador moderno. Las ejecuciones del kernel usan pwndbg por defecto por su conjunto de comandos para kernel (base de KASLR, slab, current, recorrido de tareas y módulos, búsqueda de símbolos); GEF es un cambio de una línea.
• Bucle interno de desarrollo de exploits. --run y --upload entregan un exploit al invitado en vivo mediante un recurso compartido 9p o SSH. Un único .c sin flags se compila automáticamente de forma estática con musl para la arquitectura de destino; cualquier otra cosa se entrega tal cual. Consulta exploit/README.md.
• Módulos personalizados. Compila módulos fuera del árbol contra el kernel en ejecución y cárgalos bajo demanda con --insmod y --rmmod; sus símbolos se cargan automáticamente en GDB. Consulta modules/README.md.
• Inteligencia de fallos. Un receptor de consola serie exacto byte a byte, un analizador de panic/oops/KASAN/UBSAN, y una parada automática que detiene GDB en el fallo con una traza de pila simbolizada. --analyze-crash regenera un informe sin conexión.
• Sesiones concurrentes. Cada arranque obtiene su propia sesión de tmux nombrada según lo que depura, sus propios puertos del host y su propia capa de superposición de rootfs copy-on-write, de modo que dos retos pueden depurarse en paralelo y --run/--insmod siempre llegan al invitado desde cuyo panel los escribiste.
• Artefactos de ejecución. Cada sesión escribe un artifacts/runs/<id>/ con marca de tiempo con la configuración resuelta, el perfil del host, los registros de comandos, los logs y las transcripciones de los paneles.

Requisitos

• Docker
• tmux
• Python 3.12 o superior
• uv

Ejecútalo como un usuario no root en el grupo docker. La compilación cruzada y el trabajo con initramfs se realizan dentro de contenedores (una cadena de herramientas musl de zig cc), por lo que no se necesita una cadena de herramientas cruzadas en el host.

Inicio rápido

# 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 primera ejecución construye las imágenes del contenedor y un kernel, por lo que tarda un tiempo; las ejecuciones posteriores reutilizan la caché y arrancan en segundos.

Cada arranque renombra su sesión según lo que está depurando (LIKE-DBG-pawnyable-lk01, LIKE-DBG-6_6_30-exploit-dev), de modo que una sesión que dejaste en ejecución nunca bloquea la siguiente y dos retos pueden depurarse en paralelo. Sepárate con C-b d; tmux -L likedbg ls muestra lo que está en ejecución, y el = de abajo es la forma de coincidencia exacta de tmux (sin él, una sesión -2 puede ganar):

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

A partir de aquí, lee docs/build-your-own-kernel.md para el flujo de trabajo completo, o docs/ctf-foreign-kernel.md si tienes un reto que depurar. Para un recorrido práctico de todo el ciclo contra un controlador vulnerable incluido, sigue el recorrido LK01.

Documentación