
Ambiente de depuração do kernel Linux totalmente dockerizado para Linux e MacOS
LIKE-DBG (LInux-KErnel-DeBuGger) é um laboratório de depuração e exploração do kernel Linux totalmente conteinerizado. Ele compila ou adota um kernel e um sistema de arquivos raiz, inicializa-os no QEMU e coloca você em uma sessão interativa do GDB (pwndbg ou GEF), conectando cada peça em uma única janela do tmux.
O objetivo é eliminar a configuração entediante para que seu tempo seja dedicado ao kernel, e não à infraestrutura. Cada etapa é executada dentro do Docker, então as únicas coisas que você instala no host são Docker, tmux, Python e uv. Escolha uma versão do kernel (ou forneça um desafio de CTF), execute um comando e chegue ao start_kernel com todos os símbolos disponíveis.
Um único comando resolve sua configuração, compila ou reutiliza um kernel e um rootfs, inicializa o convidado e anexa o depurador:
uv run ./start_kgdb
O ciclo é um loop no qual você permanece: compilar ou adotar um kernel e rootfs, inicializá-lo sob QEMU (o Debuggee), anexar o GDB (o Debugger) e então editar, entregar, executar, provocar o crash, encontrar a causa raiz e repetir.
Há duas formas de obter um kernel:
bzImage/Image de um desafio (mais vmlinux
e initramfs, se você os tiver) e ele inicializa exatamente esse kernel sob o GDB. Consulte
docs/ctf-foreign-kernel.md.exploit-dev, hardened, kasan,
ubsan, lockdep e outros) que se resolvem em fragmentos de configuração do kernel e padrões de execução.
A verificação pós-compilação do .config detecta um perfil que não foi aplicado. Observe que exploit-dev
(o padrão) apenas desativa o KASLR; SMEP, SMAP e KPTI permanecem ativos, a menos que você troque de perfil ou
os alterne manualmente (consulte docs/configuration.md).current, percurso de tarefas e módulos, busca de símbolos); GEF é uma troca de uma linha.--run e --upload entregam um exploit ao convidado em execução por meio de um
compartilhamento 9p ou SSH. Um único .c sem flags é compilado automaticamente como static-musl para a arquitetura de destino;
qualquer outra coisa é entregue como está. Consulte exploit/README.md.--insmod e --rmmod; seus símbolos são carregados automaticamente no GDB. Consulte
modules/README.md.--analyze-crash
regenera um relatório offline.--run/--insmod sempre chegam ao convidado de cujo painel você os digitou.artifacts/runs/<id>/ com carimbo de data/hora contendo configurações resolvidas,
perfil do host, registros de comandos, logs e transcrições de painéis.Execute como um usuário não-root no grupo docker. A compilação cruzada e o trabalho com initramfs acontecem dentro de
contêineres (uma toolchain musl zig cc), portanto nenhuma toolchain cruzada de host é necessária.
# 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
A primeira execução compila as imagens do container e um kernel, por isso demora um pouco; as execuções seguintes reutilizam a cache e arrancam em segundos.
Cada arranque renomeia a sua sessão de acordo com o que está a depurar (LIKE-DBG-pawnyable-lk01,
LIKE-DBG-6_6_30-exploit-dev), para que uma sessão que deixou a correr nunca bloqueie a seguinte e dois
desafios possam ser depurados lado a lado. Desanexe com C-b d; tmux -L likedbg ls mostra o que está
a correr, e o = abaixo é a forma de correspondência exata do tmux (sem ele, uma sessão -2 pode ganhar):
tmux -L likedbg attach -t =LIKE-DBG-6_6_30-exploit-dev
A partir daqui, leia docs/build-your-own-kernel.md para o fluxo de trabalho completo, ou docs/ctf-foreign-kernel.md se você tiver um desafio para depurar. Para um tour prático de todo o ciclo com um driver vulnerável incluído, siga o passo a passo do LK01.