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"

Pasted image 20241216213725

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.

Pasted image 20241216213901

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:

Pasted image 20241216214338

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.

Pasted image 20241216214748

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.

Pasted image 20241216220808

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.

Pasted image 20241216222008

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.

Pasted image 20241216222425

Observing the print statement while loading, you will see that it's argument is DAT_00100c71.

Pasted image 20241216222727

Observing the data that is referenced, you can see 6w00tw00t is being referenced by the printk statement.

Pasted image 20241216223329

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.

Pasted image 20241216223820

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

Pasted image 20241216224953

You can see the password inputted by adam in the log file!

Last updated