Compiling, Customising and booting the Kernel
Instructions for compiling the kernel with your own settings, as well as compiling kernel modules for a specific kernel version.
Last updated
Was this helpful?
Instructions for compiling the kernel with your own settings, as well as compiling kernel modules for a specific kernel version.
Last updated
Was this helpful?
Use --depth 1 to only get the last commit.
Remove the current compilation configurations, as they are quite complex for our needs
Now we can create a minimal configuration, with almost all options disabled. A .config file is generated with the least features and drivers possible.
We create a kconfig file with the options we want to enable. An example is the following:
In order to update the minimal .config with these options, we use the provided merge_config.sh script:
That takes a while, but eventually builds a kernel in arch/x86/boot/bzImage. This is the same bzImage that you get in CTF challenges.
To compile it for a different kernel, all we do is change the -C flag to point to the newly-compiled kernel rather than the system's:
The module is now compiled for the specific kernel version!
We now have a minimal kernel bzImage and a kernel module that is compiled for it. Now we need to create a minimal VM to run it in.
We also create an output folder for compiled versions.
Now compile it statically. We're going to use the menuconfig option, so we can make some choices.
Once the menu loads, hit Enter on Settings. Hit the down arrow key until you reach the option Build static binary (no shared libs). Hit Space to select it, and then Escape twice to leave. Make sure you choose to save the configuration.
Now, make it with the new options
Now we make the file system.
The last thing missing is the classic init script, which gets run on system load. A provisional one works fine for now:
Make it executable
Finally, we're going to bundle it into a cpio archive, which is understood by QEMU.
The -not -name *.cpio is there to prevent the archive from including itself
You can even compress the filesystem to a .cpio.gz file, which QEMU also recognises
If we want to extract the cpio archive (say, during a CTF) we can use this command:
Put bzImage and initramfs.cpio into the same folder. Write a short run.sh script that loads QEMU:
Once we make this executable and run it, we get loaded into a VM!
Right now, we have a minimal linux kernel we can boot, but if we try and work out who we are, it doesn't act quite as we expect it to:
This is because /etc/passwd and /etc/group don't exist, so we can just create those!
First, we copy the .ko file to the filesystem root. Then we modify the init script to load it, and also set the UID of the loaded shell to 1000 (so we are not root!).
Here I am assuming that the major number of the double_fetch module is 253.
Why am I doing that?
If we load into a shell and run cat /proc/devices, we can see that double_fetch is loaded with major number 253 every time. I can't find any way to load this in without guessing the major number, so we're sticking with this for now - please get in touch if you find one!
It takes ages to run, naturally. Once we do that, we can check out a specific version of choice:
We then continue from there.
Some tags seem to not have the correct header files for compilation. Others, weirdly, compile kernels that build, but then never load in QEMU. I'm not quite sure why, to be frank.
CONFIG_LTO_NONE - disables Link Time Optimization (LTO) for kernel compilation. This is to
, we use the following Makefile structure:
To do this, we use , an executable that contains tiny versions of most Linux executables. This allows us to have all of the required programs, in as little space as possible.
We will download and extract busybox; you can find the latest version .
The final step is, of course, the loading of the kernel module. I will be using the module from my section for this step.
If we want to compile a kernel version that is not the latest, we'll dump all the :