One of the most challenging aspects of kernel pwning, from my experience, is setting up an efficient debugging environment. Therefore, this project aims to streamline the kernel pwning setup and debugging process. It generates a kernel-pwning workspace that accelerates exploit development by enabling fast experimentation on various kernel exploits.
A kernel pwning workspace
- is localized: easy to remove and regenerate
- requires minimal manual setup: works with just one command in most cases (similar to
pwninit) - is robust against slight variations of file names and formats (from different CTF challenges)
- is organized and generated to accelerate exploit development: contains a subset of helpers provided by
pwntools - is as customizable as possible
This project is inspired by kernelinit.
Lots of thanks to Jacob for early testing.
git clone https://github.com/jxuanli/kpinit.git
echo "alias kpinit='python3 $PWD/kpinit/kpinit.py'" >>~/.bash_aliasesvmlinux-to-elf installation
sudo apt -y install python3-pip liblzo2-dev
pip3 install --upgrade git+https://github.com/marin-m/vmlinux-to-elfdemo.mp4
With only one command, kpinit sets up the kernel pwning workspace that you need!
cd <challenge directory>
kpinit
cd workspace/exploit
./launch.sh [--gdb] [--nokaslr] [--port <port>]Removing all generated files is as simple as:
rm -rf ./workspaceYou may optionally set the NO_KPINIT_EXPLOIT environment variable to prevent exploits from running unintentionally on your host machine.
workspace/context.json contains file paths used to extract information for static analysis and file generation. Instead of having to specify paths with command options, kpinit automatically detects needed files for creating a kernel-pwning workspace. This reduces the need for manual setup. When detection fails, the user can manually specify the paths and rerun kpinit (the changes will be applied).
Generic GDB scripts for adding symbol files (vmlinux and loadable modules) are included in workspace/challenge/debug.gdb. Offsets are automatically computed when KASLR is enabled. Extra GDB scripting can be added in workspace/exploit/extra.gdb.
kpinit parses and regenerates qemu commands for modifying the qemu command and placing the generated launch.sh in a different directory. Although it correctly parses most launch files (that contain the qemu command), it occasionally fails and generates incorrect qemu commands. In those cases, users need to manually fix launch.sh. Because the launch file format does not follow a consistent pattern, I believe this is acceptable.
See Features section for more usages.
- generates a new directory with the following structure:
challenge dir/
├── workspace/ (generated)
│ ├── context.json
│ ├── log.txt
│ ├── vmlinux (if not provided)
│ ├── challenge/
│ │ ├── debug.gdb
│ │ ├── initramfs/
│ │ └── initramfs.cpio.gz (if used)
│ └── exploit/
│ ├── util/
│ │ └── (utility files)
│ ├── launch.sh (improved run.sh)
│ ├── serve.sh
│ ├── extra.gdb
│ ├── init
│ ├── vuln.ko
│ └── exploit.c (imports files in util/)
├── bzImage (required)
├── run.sh (required)
└── ... (optional: vmlinux, ramfs, .qcow2, ...)
- supports
x86-64andaarch64 - auto-generates
./workspace/context.jsonand allows customization - generates
./workspace/challenge- decompresses
./initramfs.cpio.gzif it exists and extractsinitfrom it
- decompresses
- generates
./workspace/exploit/launch.sh(rwx)- contains the parsed
qemucommand -
--nokaslr - supports different ports
- compiles
./workspace/exploit/exploit.c- includes it in
./workspace/challenge/initramfs - recompresses
./workspace/challenge/initramfs.cpio.gz
- includes it in
- autostarts two panes (
zellijortmux) - regeneration preserves old
exploit.c
- contains the parsed
- extracts
vmlinuxif not already provided (vmlinux-to-elf) - runs checks on the kernel configuration file if it exists
- runs checks on
vmlinuxif the configuration file does not exist andvmlinuxis not stripped
- runs checks on
- extracts
vuln.koif needed - generates
debug.gdb- sources
vmlinuxat the correct offset even if KASLR is enabled - adds
vuln.kosymbols if they exist (whenvmlinuxcontainsdebug_info) - sources Linux source code
- supports custom breakpoints
- sources
- generates exploit helpers (See DOC.md for documentations)
info,warn,error,important,input,cyclic, etc (similar to those in pwntools)- retspill,
modprobe_path,core_dump - BPF helper macros and functions
- extracts files from
.qcowor.imgfiles - generates an exploit file serving script
- The localhost can then be exposed with tools such as
ngrok
- The localhost can then be exposed with tools such as
- preserves log
- optionally prevents unintended exploit runs
Only GDB is currently supported.