KnightCTF 2022 - Whats your name 2

This is my write up of the whats_your_name_2 challenge from KnightCTF 2022.  The files needed for this writeup can be found at https://github.com/ChrisCHumphreys/knightctf22/tree/main/whats_your_name_2.

First, by examining the executable with checksec from pwn tools we can see that we have a 64 bit binary with very few protections built in.

Running the program shows that it simply asks us to enter a username, and then the program exits.

 

Next, examining the de compilation in Ghidra, we can see that there is an fgets call that will read in a max of 200 bytes to a char buffer named input_buf.  No real problems here are there is more than enough room for 200 characters in the buffer.

 

Following this, we can see that there is a call to strcpy which will copy the string in input_buf to the local_58 buffer.  This is where the problem is.  strcpy does not check to ensure that the string being copied will fit into the buffer being copied to.  It just keeps going until it hits a null byte.  Since we are able to input up to 200 characters into the input_buf string, any character entered after the 72nd will be writing to memory in areas it should not have access to after the strcpy call.

Next, on line 16, there are two variables (local_c and local_10) whose values are checked, and if they match what is expected, the binary will output the contents of the flag.txt file.  We must need to overrun our buffer, and then set the areas in memory to theses correct values to get the flag printed.  These feel kind of like poorly implemented stack canaries, and the way to get around them is to just ensure that these sections of our payload match what the program is expecting.

Examining the stack layout in Ghidra for the main function, we can see that the local_58 section of memory is exactly 72 bytes above local_10. (0x58 - 0x10 = 0x48 = 72)  And in turn, local_10 is 4 bytes above local_c.

 

With this info we have all the we need to write our exploit, which is shown below.

 

One side note, the payload values for local_c and local_10 are reversed in our input, due to the fact that we are working on a little endian system.

When we attempt to run the exploit we can see that it does in fact work.

 

The big giveaway here is that we can see it attempted to print the contents of /home/hacker/flag.txt.  On my local system I received a "file not found" error, but when run against the CTF server, the flag printed out.