CSAW CTF 2024

Table of Contents

Introduction #

This was an online jeopardy-style CTF held from Fri, 06 Sept. 2024 — Sun, 08 Sept. 2024.

We download the binary and examine the file type using the file command
The file is a 64-bit ELF pie executable for x86-64 architecture.
The file is dynamically linked, and is intended for use on a GNU/Linux system version 3.2.0 or later, with debugging information not stripped.
We can check the security features compiled into the binary using checksec
We have Full RElRO enabled, a stack canary found, NX bit enabled and PIE enabled meaning that the binary has the common buffer overflow protections.
Running strings on the binary, we get the following which dont provide us with much:

We decompile the main function in Ghidra, do some variable renaming and we then can start making sense of what the program does:
The program declares some variables then includes a stack canary to detect buffer overflows.
The program then outputs a message on stdout, reads user input and removes the newline character then checks if the input matches the expected flag using a check_message function as seen on line 21.
If the check_message function returns 0 it prints a failure message else it prints a success message.
The program terminates if stack corruption is detected.
Dropping into the check_message function:
We can see an interesting variable named flag on line 17
Reversing the binary statically didn’t yield much, so I jumped into dynamic analysis to see how the program behaved when supplied with input.

Executing the binary like below made the program to exit with the failure message

 python3 -c "print('A'*300)" | ./baby_rev

We load the binary into GDB.
Next, we set a breakpoint using break check_message.
We run the program and provide an input when prompted.
When we hit enter, we hit the breakpoint at check_message. When we disassemble check_message, we can see this instruction lea rax,[rip+0x2b30] #0x555555558040 <flag>.

This instruction loads the memory address rip + 0x2b30 into rax.
The computed address is 0x555555558040, which is associated with the label <flag>.

x/s 0x555555558040 in gdb will examine the memory address 0x555555558040 and display the string stored at that location
And voila! We get our flag encoded into base64

{N3v3r_pr073c7_s3ns171v3_1nf0rm4710n_us1ng_jus7_3nc0d1ng!_#3nc0d1ng_1s_n0t_3ncryp710n!}