Solve a puzzle and uncover the secret message by demonstrating your knowledge of Linux.
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
A patch that adds a copy of the ctf driver code and makefile to your directory
The latest commit to the ILKD_submissions repo contains a directory named username/P2
Copy P2/ctf.c
and P2/Makefile
into username/P2
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 all returned bytes and print them at the end
When you solve the puzzle, printing these bytes will reveal your secret message
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 a cover letter
All email code patches are expected to pass checkpatch.pl
as described in the policies and procedures
Submit your patches to programming2@COURSE_DOMAIN
Copy the driver code and makefile into your folder.
Examine the driver code to understand how information flows from one function to another
How are the values printed to the kernel ring buffer generated?
How can you reverse-engineer that process?
Write your C program to perform the operations and gather the secret message
Initially, the program should just open /dev/ctf
, verify that it gets a valid file descriptor, and then close the file
Between those two operations, insert code that calls read(2)
, write(2)
, lseek(2)
, and ioctl(2)
with correct arguments to decrypt the message
Compare the dmesg
output from running your program to dmesg_log
to see if you are on the right track
This driver breaks a number of conventions to simplify this exercise
The buffer argument for calls to read(2)
and write(2)
can be NULL
since the driver does not actually read or write data to userspace
The non-error return values from the system calls will not obey the rules specified in their manpages
msg = (silence)
whoami = None
singularity v0.5 https://github.com/underground-software/singularity