Skip to content

jxuanli/kpinit

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

97 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

kpinit

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.

Design philosophies

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

Acknowledgements

This project is inspired by kernelinit.

Lots of thanks to Jacob for early testing.

Installation

git clone https://github.com/jxuanli/kpinit.git
echo "alias kpinit='python3 $PWD/kpinit/kpinit.py'" >>~/.bash_aliases

vmlinux-to-elf installation

sudo apt -y install python3-pip liblzo2-dev
pip3 install --upgrade git+https://github.com/marin-m/vmlinux-to-elf

Demo

demo.mp4

Usage

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 ./workspace

You may optionally set the NO_KPINIT_EXPLOIT environment variable to prevent exploits from running unintentionally on your host machine.

File paths detection

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).

GDB scripting

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.

Known issues

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.

Features

  • 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-64 and aarch64
  • auto-generates ./workspace/context.json and allows customization
  • generates ./workspace/challenge
    • decompresses ./initramfs.cpio.gz if it exists and extracts init from it
  • generates ./workspace/exploit/launch.sh (rwx)
    • contains the parsed qemu command
    • --nokaslr
    • supports different ports
    • compiles ./workspace/exploit/exploit.c
      • includes it in ./workspace/challenge/initramfs
      • recompresses ./workspace/challenge/initramfs.cpio.gz
    • autostarts two panes (zellij or tmux)
    • regeneration preserves old exploit.c
  • extracts vmlinux if not already provided (vmlinux-to-elf)
  • runs checks on the kernel configuration file if it exists
    • runs checks on vmlinux if the configuration file does not exist and vmlinux is not stripped
  • extracts vuln.ko if needed
  • generates debug.gdb
    • sources vmlinux at the correct offset even if KASLR is enabled
    • adds vuln.ko symbols if they exist (when vmlinux contains debug_info)
    • sources Linux source code
    • supports custom breakpoints
  • 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 .qcow or .img files
  • generates an exploit file serving script
    • The localhost can then be exposed with tools such as ngrok
  • preserves log
  • optionally prevents unintended exploit runs

Only GDB is currently supported.

About

Accelerating Linux kernel exploit development.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors