LIKE-DBG

LIKE-DBG (LInux-KErnel-DeBuGger) — полностью контейнеризированная лаборатория для отладки и эксплуатации ядра Linux. Она собирает или использует готовое ядро и корневую файловую систему, загружает их под QEMU и погружает вас в интерактивную сессию GDB (pwndbg или GEF), связывая все компоненты в одном окне tmux.

Смысл в том, чтобы убрать скучную настройку, чтобы ваше время уходило на ядро, а не на инфраструктуру. Каждый шаг выполняется внутри Docker, поэтому на хосте нужно установить только Docker, tmux, Python и uv. Выберите версию ядра (или передайте CTF-задание), выполните одну команду — и окажетесь в start_kernel с полными символами.

Что она делает

Одна команда разрешает вашу конфигурацию, собирает или переиспользует ядро и rootfs, загружает гостя и подключает отладчик:

uv run ./start_kgdb

Цикл, внутри которого вы остаётесь: собрать или взять ядро и rootfs, загрузить их под QEMU (отлаживаемая сторона), подключить GDB (отладчик), затем редактировать, доставлять, запускать, вызывать крах, искать первопричину и повторять.

Есть два способа получить ядро:

• Собрать своё. Выберите версию, профиль отладки и компилятор; LIKE-DBG скачает, сконфигурирует и соберёт его один раз, а затем закэширует. Это основной инструмент для изучения ядра и разработки эксплойтов. См. docs/build-your-own-kernel.md.
• Взять CTF- или стороннее ядро. Передайте ему bzImage/Image из задания (плюс vmlinux и initramfs, если они у вас есть), и оно загрузит их как есть под GDB. См. docs/ctf-foreign-kernel.md.

Ключевые возможности

• Работает на macOS и Linux, хост определяется автоматически. Apple Silicon загружает гостей arm64 с нативным ускорением HVF; x86_64 на Mac и Linux без KVM переключаются на TCG в контейнере; Linux с KVM использует его. Хранилище, ускорение и сеть выбираются для каждого хоста и записываются для каждого запуска.
• Архитектуры: x86_64 и arm64.
• Конфигурация TOML с профилями отладки. Многоуровневый стек TOML (проектные значения по умолчанию, личные локальные переопределения, именованные сценарии, CLI) плюс именованные профили (exploit-dev, hardened, kasan, ubsan, lockdep и другие), которые разворачиваются во фрагменты конфигурации ядра и значения по умолчанию для времени выполнения. Проверка .config после сборки выявляет профиль, который не применился. Учтите, что exploit-dev (по умолчанию) только отключает KASLR; SMEP, SMAP и KPTI остаются включёнными, если вы не переключите профили или не измените их сами (см. docs/configuration.md).
• Современный отладчик. Запуски ядра по умолчанию используют pwndbg ради его набора команд для ядра (база KASLR, slab, current, обход задач и модулей, поиск символов); GEF переключается одной строкой.
• Внутренний цикл разработки эксплойтов. --run и --upload доставляют эксплойт в живой гость через 9p-раздел или SSH. Одиночный .c без флагов автоматически компилируется статически с musl под целевую архитектуру; всё остальное доставляется как есть. См. exploit/README.md.
• Пользовательские модули. Собирайте внешние модули против работающего ядра и загружайте их по команде с помощью --insmod и --rmmod; их символы автоматически подгружаются в GDB. См. modules/README.md.
• Анализ крахов. Побайтово точный приёмник последовательного консольного вывода, парсер panic/oops/KASAN/UBSAN и автоматическая остановка, которая перехватывает GDB на месте сбоя с символизированной трассировкой стека. --analyze-crash заново формирует отчёт офлайн.
• Параллельные сессии. Каждая загрузка получает собственную tmux-сессию, названную по тому, что она отлаживает, собственные порты хоста и собственный copy-on-write оверлей rootfs, так что два задания можно отлаживать бок о бок, а --run/--insmod всегда попадают в тот гость, из панели которого вы их ввели.
• Артефакты запуска. Каждая сессия записывает в artifacts/runs/<id>/ с отметкой времени разрешённые настройки, профиль хоста, записи команд, логи и расшифровки панелей.

Требования

• Docker
• tmux
• Python 3.12 или новее
• uv

Запускайте от имени пользователя без прав root в группе docker. Кросс-компиляция и работа с initramfs выполняются внутри контейнеров (инструментальная цепочка musl на zig cc), поэтому кросс-инструментарий на хосте не нужен.

Быстрый старт

# 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

Первый запуск собирает образы контейнеров и ядро, поэтому занимает некоторое время; последующие запуски используют кэш и стартуют за секунды.

Каждая загрузка переименовывает свою сессию в соответствии с тем, что она отлаживает (LIKE-DBG-pawnyable-lk01, LIKE-DBG-6_6_30-exploit-dev), поэтому сессия, которую вы оставили запущенной, никогда не блокирует следующую, и две задачи можно отлаживать параллельно. Отсоединитесь с помощью C-b d; tmux -L likedbg ls показывает, что запущено, а = ниже — это форма точного совпадения tmux (без неё может победить сессия с -2):

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

Отсюда читайте docs/build-your-own-kernel.md, чтобы узнать полный рабочий процесс, или docs/ctf-foreign-kernel.md, если вам нужно отладить какое-либо задание. Для практического знакомства со всем циклом на примере встроенного уязвимого драйвера следуйте руководству по LK01.

Документация

Документ	Что охватывает
docs/walkthrough-lk01.md	Начните здесь: пошаговый сквозной пример на основе встроенного уязвимого драйвера — от сборки до use-after-free и отчёта о падении.
docs/build-your-own-kernel.md	Соберите ядро из исходников, загрузите его, затем отлаживайте и итерируйте.
docs/ctf-foreign-kernel.md	Подключите предоставленное CTF-ядро или стороннее ядро и доставляйте к нему эксплойты.
docs/configuration.md	Стек конфигурации TOML, профили отладки и все параметры.
exploit/README.md	Цикл разработки эксплойтов: граница автокомпиляции и аварийный выход.
modules/README.md	Внешние пользовательские модули и автозагрузка символов GDB.