Reversing Linux Modules
Hack The Box University CTF 2024: Binary Badlands Reversing - ColossalBreach
Files
Our first step in this walkthrough is to examine what files we downloaded from the CTF.
You can observe that there is a file named "brainstorm.ko" and a file named "logs"
The next step is to look into what the ".ko" extension signifies. ".ko" files are used to "extend" the kernel of a Linux Distribution. From my understanding, this means they are binary files, probably coded in C.
When examining the logs file, it appears to be gibberish. It is probably necessary to decode this to get our flag.
Ghidra
Now that you have a basic understanding of the files, its time to open the "brainstorm.ko" file, and start to dig into what is happening.
The first thing you will notice are these functions that have been created:
While observing "keys_read", I assumed that they are installing some type of keylogger. We will save that for later.
Who is the author?
A good thing to know in Ghidra is the search tool. There are many different ways you can search for references to things, but a good starting point is All Fields.
There are 2 results, they both link to this line that says "author=0xEr3n".
What is the name of the function used to register keyboard events?
Right here is when it is critical to examine the file thoroughly. If uoi look in our "spy_init" function, you can see that after a directory and file is made, a function named register_keyboard_notifier is being called.
What is the name of the function that converts keycodes to strings?
This one is simple. In the functions you will remember a function called keycode_to_string . This is the correct function.
What file does the module create to store logs? Provide the full path.
This is defined in the spy_init function that is shown above. You can observe that a function called debugfs
is being executed to create a directory named spyyy
. Looking into debugfs, its mentioned that its typically mounted to /sys/kernel/debug
. The next thing you may notice is that debugfs is creating some type of file. It mentions DAT_00100c6c
as one of the arguments. If you look into the data more, you can observe that DAT_00100c6c
references characters.
The full path to the logs is /sys/kernel/debug/spyyy/keys
What Message does the module print when imported?
A good starting point is searching for print in the program. You can see that printk
is being executed by the program as spy
is loaded and unloaded.
Observing the print statement while loading, you will see that it's argument is DAT_00100c71
.
Observing the data that is referenced, you can see 6w00tw00t
is being referenced by the printk
statement.
Looking into printk, 6 is actually a log level that denotes an informational message. The message being displayed is actually w00tw00t
.
What is the XOR key used to obfuscate the keys? (e.g. 0x01, 0x32)
This question is more difficult. The function to focus on is spy_cb
, as this is what is doing the obfuscation. In the function, there appears to be a lot of math, but the do{}
statement is where all the heavy lifting is done.
the XOR operation in C is ^
, and you can see that the first line of the do
statement is executing the shift. It is shifting by 0x19.
What is the password entered for adam?
This is where you should look at the log file. Now that you know that the obfuscation is done by XORing by 0x19 bites, you can reverse the obfuscation in the log file. Reversing XOR is as simple as just performing the XOR again. You could look up the ASCII character codes and do this by hand, but a Python script is the fastest way (I have an example in this GitHub Repo).
You can see the password inputted by adam in the log file!
Last updated