Kernel Development Learning Pipeline
P2 - Capture the Flag 🏁
Solve a puzzle and uncover the secret message by demonstrating your knowledge of Linux.
Outcomes:
- Learn about the system calls commonly implemented by character devices and how they interact with the file position stored in the kernel
- Get familiar with how userspace syscalls translate in running kernel code within a driver.
- Have fun solving a custom puzzle
What to submit:
- A patch that adds a copy of the ctf driver code and makefile to your named directory.
- There will already be a folder with your name in the p2 folder.
- You should copy
ctf.c
and Makefile
from the p2 directory into to your named directory.
- Add the files to git and make your first commit.
- A patch which adds your solution program and changes the makefile to compile it.
- Write a C program that performs the right sequence of operations on
/dev/ctf
so that the messages from the driver in dmesg
match the provided output in dmesg_log
.
- Each successful operation will return one byte of the secret message. Your C program should collect those bytes and print them at the end.
- If the arguments passed to the operation are incorrect, the returned byte will be nonsense.
- If the operation would leave the device in an invalid state (i.e. f_pos outside of the range 0 through 256), the operation will return an error.
- Don’t forget your cover letter.
- Make sure to include the secret message you obtained in your cover letter.
Procedure:
- Copy the driver code and makefile into your folder.
- Examine the driver code to understand how information flows from one function to another.
- Where do the values printed to the kernel ring buffer come from?
- How can you reverse that process to determine the arguments you need to pass to the syscalls?
- Write your C program to perform the operations and gather the secret message.
- Initially, it should just open
/dev/ctf
and verify that it got a valid file descriptor then close it.
- Between those two operations, insert code that calls
read
/write
/lseek
/ioctl
on the file descriptor based on the contents of dmesg_log
.
- The buffer argument for calls to
read
and write
can be NULL
since the driver does not actually read or write data from it, the size is the only important argument.
- Submit your patches to programming2@kdlp.underground.software
Submission Guidelines