LIKE-DBG（LInux-KErnel-DeBuGger）は、完全にコンテナ化された Linux カーネルの デバッグおよびエクスプロイト演習環境です。カーネルとルートファイルシステムをビルドまたは採用し、それらを QEMU 上で起動して、インタラクティブな GDB セッション（pwndbg または GEF）へと導きます。すべての要素は 単一の tmux ウィンドウに接続されます。
狙いは、退屈なセットアップを取り除き、時間を足場ではなくカーネルそのものに費やせるようにすることです。
すべてのステップは Docker 内で実行されるため、ホストにインストールする必要があるのは Docker、tmux、
Python、そして uv だけです。カーネルのバージョンを選ぶ（あるいは CTF
チャレンジを渡す）だけで、コマンドを 1 つ実行すれば、完全なシンボル付きで start_kernel に到達します。
1 つのコマンドで設定を解決し、カーネルと rootfs をビルドまたは再利用し、ゲストを起動して、 デバッガをアタッチします：
uv run ./start_kgdb
この実行は、あなたがその中に留まるループです。カーネルと rootfs をビルドまたは採用し、QEMU（Debuggee）の下で起動し、GDB（Debugger）をアタッチし、その後、編集、配信、実行、クラッシュ、根本原因の特定を繰り返します。
カーネルを入手する方法は 2 つあります。
bzImage/Image（および必要に応じて vmlinux と initramfs）を渡すと、それをそのまま GDB の下で起動します。docs/ctf-foreign-kernel.md を参照してください。exploit-dev、hardened、kasan、ubsan、lockdep など）を備えています。ビルド後の .config 検証により、プロファイルが適用されなかったことを検出します。exploit-dev（デフォルト）は KASLR をオフにするだけであり、プロファイルを切り替えるか自分でトグルしない限り、SMEP、SMAP、KPTI はオンのままです（docs/configuration.md を参照）。current、タスクとモジュールのウォーキング、シンボル検索）を利用できます。GEF は 1 行の切り替えで使用できます。--run と --upload は、9p 共有または SSH 経由でエクスプロイトを稼働中のゲストに配信します。フラグのない単一の .c は、ターゲットアーキテクチャ向けに static-musl で自動コンパイルされます。それ以外はそのまま配信されます。exploit/README.md を参照してください。--insmod と --rmmod でコマンドからロードできます。そのシンボルは GDB に自動でロードされます。modules/README.md を参照してください。--analyze-crash はレポートをオフラインで再生成します。--run/--insmod は常に、それらを入力したペインのゲストに届きます。artifacts/runs/<id>/ を書き出します。docker グループの非 root ユーザーとして実行してください。クロスコンパイルと initramfs の処理はコンテナ内（zig cc musl ツールチェーン）で行われるため、ホスト側のクロスツールチェーンは不要です。
# 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）ため、実行したままにしたセッションが次のセッションを妨げることはなく、2つの
チャレンジを並行してデバッグできます。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 シンボルの自動ロード。 |
modules/lk01/ には、意図的に脆弱に作られた小さなトレーニング用ドライバとクラッシュ PoC が同梱されており、ビルド、ロード、エクスプロイトのループ全体の実例として配線されています。
Python コードは src/likedbg/ にあり、読みやすくあることを意図しています。just test はテストスイートを実行し、just lint は ruff と mypy を実行し、just build-images は Dockerfile や焼き込みスクリプトの変更後にコンテナイメージを再ビルドします。バグ報告、機能リクエスト、PR は イシュートラッカー および ディスカッションページ から歓迎します。
MIT。LICENSE を参照してください。