SANS National CTF Tournament 2021 - Binary Hard 2

SANS National CTF Tournament 2021 - Binary Hard #2

November 11, 2021

I want to share with you my solution regarding the CTF Binary Hard #2.


A binary named "program" is provided. It requests a password to provide you the flag. You can download this binary here and have fun to reproduce this CTF if you want on your computer.
I recommand using a Linux distribution for this CTF, preferably Kali as I've worked with it to solve this CTF.

Let's start!

First thing first, a small look at this binary properties. It cannot hurt to know a little bit more about our challenger: 

								
user@kali:~/Documents/SANS CTF/BH02$ file program
program: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=16e26b9493c4785afd758485e6c448e7cd5d2df6, not stripped

OK very good! It's pretty straightforward, it's a 64-bit ELF binary, is dynamically linked, and it's NOT stripped of debugging symbols.
I'm curious to see what this binary does so let's execute it to see what's happening: 

								
user@kali:~/Documents/SANS CTF/BH02$ ./program 
密码是什么？
> blah
不正确的.
I was not expecting chinese, that's for sure.
Deepl Translator I need you !

Let's see how the program react with a classical attempt at buffer overflow. 

								
user@kali:~/Documents/SANS CTF/BH02$ ./program 
密码是什么？
> OVERFLOWOVERFLOWOVERFLOWOVERFLOWOVERFLOWOVERFLOWOVERFLOWOVERFLOW...OVERFLOW
不正确的.

Well, that's not a big success. To me it sounds like it's not the way to go...
Maybe a strings can give us something? 

								
user@kali:~/Documents/SANS CTF/BH02$ strings program
/lib64/ld-linux-x86-64.so.2
libc.so.6
puts
__stack_chk_fail
stdin
printf
fgets
__cxa_finalize
strcmp
__libc_start_main
[...]
.bss
.comment

No flag or password but a valuable information. The program is using string compare strcmp. Most probably to compare user input with the password!

No choice. The CTF designer wants us to do some binary diving. Let's go for it. Challenge accepted!
We've found a strcmp function and we know that strcmp function works this way:

Function strcmp() in C language:
int strcmp(const char *str1, const char *str2)
Compares str1 and str2.
Returns an integer; 0 if string are equals otherwise a non-zero value.

Assuming that the strcmp function is used for the password comparison, what I will attempt to do is:

  1. Run the program in debug mode
  2. Locate the strcmp function and set an execution breakpoint
  3. Read the memory registry that contains the strings to compare

Looks like a pretty straight forward plan to me...
I like to use GDB as a debugger.
For those who are not familiar with GDB, here is a great cheat sheet.
Let's set it up to give us a nice view with following options: 

								
user@kali:~/Documents/SANS CTF/BH02$ gdb program

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set disassembly-flavor intel
(gdb) layout asm

Now that we are setup.
We need to gather more information on the functions that are used in this binary.
We barely know nothing yet.
For this matter we will simply use info functions. 

								
(gdb) info functions
All defined functions:

Non-debugging symbols:
0x0000000000000630  _init
0x0000000000000660  puts@plt
0x0000000000000670  __stack_chk_fail@plt
0x0000000000000680  printf@plt
0x0000000000000690  fgets@plt
0x00000000000006a0  strcmp@plt
0x00000000000006b0  __cxa_finalize@plt
0x00000000000006c0  _start
0x00000000000006f0  deregister_tm_clones
0x0000000000000730  register_tm_clones
0x0000000000000780  __do_global_dtors_aux
0x00000000000007c0  frame_dummy
0x00000000000007ca  main
0x0000000000000950  __libc_csu_init
0x00000000000009c0  __libc_csu_fini
0x00000000000009c4  _fini

Excellent news! The binary does not conains lot's of function. We can clearly identify strcmp function.
It really looks like the CTF creator wants us to follow this direction.
We can set a breakpoint on the strcmp function using command: b(reak) strcmp@plt
Then type r(un) to launch the program.

								
(gdb) b strcmp@plt
Breakpoint 1 at 0x6a0
(gdb) r
							
Starting program: /home/user/Documents/SANS CTF/BH02/program
密码是什么？
> blah

Breakpoint 1, 0x00005555555546a0 in strcmp@plt ()
(gdb)

Perfect, our breakpoint is working. Now it should be piece of cake. We need to inspect the registry.
To do so, our best friend command is info registers

							
ds             0x0                 0
es             0x0 strcmp@plt
rax            0x5555555549d8      93824992233944
rbx            0x0                 0
rcx            0x5555557566b5      93824994338485
rdx            0x7fffffffdf50      140737488346960
rsi            0x7fffffffdf50      140737488346960
rdi            0x5555555549d8      93824992233944
rbp            0x7fffffffdfa0      0x7fffffffdfa0
rsp            0x7fffffffdf18      0x7fffffffdf18
r8             0x7fffffffdf50      140737488346960
r9             0x7ffff7fa9c00      140737353784320
r10            0x5d                93
r11            0x246               582
r12            0x5555555546c0      93824992233152
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0

From the assembly, we can see the registries involved in the strcmp. You can identify rax, rcx, rdx, rsi, rdi, rbp, rsp ...
It means that the password we've entered and the password we are looking for are in these registries.
Let's check what's in each of them using e(x)amine command: x/s $rax and x/s $rdx.

							
(gdb) x/s $rax
0x5555555549d8: "龙123\n"
(gdb) x/s $rdx
0x7fffffffdf50: "blah\n"

Bingo!
We can find in the register rdx the password we've entered and the rax register contains the password we are looking for.
The password is: 龙123 (=Dragon123)
Run the program and provide this password to see what happens. 

							
user@kali:~/Documents/SANS CTF/BH02$ ./program
密码是什么？
> 龙123
正确!

旗: gHn3*jXvs&H!@jGs

The password is correct! (正确!) The program returns us the flag (旗): gHn3*jXvs&H!@jGs

Lot's of fun!