- Ol_basic_overflow_l
Step A.1
Before diving in, let’s ensure that our project environment is appropriately configured.
1 This project utilizes the same virtual machine (VM) that is used for other projects within CS6035.
If you’ve already got it configured, great! If not, see the respective “Course VM Download Thread” post in Ed Discussion for instructions.
2 Please follow the instructions in Canvas (navigate to “Assignments” > “Binary Exploitation”) for
login credentials to the VM as well as the requisite commands for fetching the project files.
3 Navigate to /home/binexp open the user.txt file (this file will be empty initially) and enter your nine-digit GTID. If you do not know your GTID, you should be able to discover this through https://gtid.gatech.edu. Note: if you fail to set this, no responses you submit to Gradescope will be accepted as correct.
Below is a brief summary of the project’s contents:
- json: This is the one (and only) file you will submit to Gradescope to have your work be evaluated. See the Submission tab along the left-hand side of this page for additional guidance concerning project submission guidelines.
- project\*: This is the directory and subdirectories that make up the project. Each subdirectory reflects an individual challenge within the project and contains all of the files necessary for solving that particular challenge. We have included a project\tutorial\ subdirectory that has amplifying guidance material to help get you oriented to the projects’ techniques. The contents
|
|
2/9/26, 12:07AM Stage A – SetupNalidation — (1 flags) I CS 6035
of project\tutorial\ are not mandatory or graded – you should not include any practice work results you perform there in your project_binexp.json file.
- project\*\flag: For most of the challenges, this is the compiled binary you’re attempting to If it isn’t, the student instructions for that particular challenge will say so.
- project\*\flag.c : This is the source code for the flag binary, above. This is intended to be a useful reference to aid in identifying and crafting your exploits of flag .
- project\*\e.py : This is a python3 script with some templated skeleton exploit code. You are welcome to use/ignore this as you see fit.
- project\*\e.py.bak: This is just a copy of the initial state of py in case you accidentally delete it or wish to revert back to start. Simply copy from this file to get a clean-slate e.py.
In all of the projects’ binaries, your goal is to have the binary read from /proc/flag! Most of the time, this is via a system() call like:
system(“cat /proc/flag”);
However, sometimes it’s not that simple – carefully analyze your source code within each challenge to figure out how the binary is meant to read from /proc/flag .
Step A.2
Otbasic_overflow_l [0 pts]
INSTRUCTIONS
Now, let’s take a look at our first introductory challenge to ease us into the exploit development process at a high-level: Ol_basic_overflow:l. We’re going to walk you through this one just to give you a sense of what’s to come.
In this task, we’re looking at a simple buffer overflow. A buffer overflow occurs when input exceeds the expected bounds it’s intended to write to, thereby spilling outside those bounds and overwriting other areas of memory. Generally speaking, this kind of incident leads the running process to crash. However, a crafty (and determined) malicious actor may be able to get the process to do something else altogether!
If we were to review the source code for our binary (flag.c), we could start by tracing the code execution flow starting at main() , which is the starting point for all C program code.
cat –/project/Ol_basic_overflow_l/flag.c
1 The main() function starts by initializing the variable make_me_not_zero to 0.
2 It then declares an int buffer of size 300.
3 There’s a printf() call, which would write some instructions to the user to stdout .
4 The process then blocks for user input with scanf() , writing the input to buffer.
5 There’s then a if-conditional check to see if make_me_not_zero is still 0. If it is, the process
terminates; if it isn’t, we arrive at our desired destination in the binary which reads our flag out for us.
Intuitively, we can start to build our attack chain in reverse:
- We want to get to the function call that reads out our flag.
- To get to the above, we need to have make_me_not_zero not be zero by the time the if-conditional
- Since the program does not otherwise allow for us to set make_me_not_zero, we need to either overwrite it in memory or otherwise disrupt the control flow of the process.
- Our only input to the process is along the scanf() call, so we’ll investigate what exploit opportunities exist around here.
Now many of you may not necessarily be professional exploit developers already (in fact, some of you may not have exercised secure coding practices in C more generally); understandably, the vulnerability may not immediately be apparent. But if we look into references for scanf(), we can see that it reads in from stdin with the “s” specifier standing for…
Any number of non-whitespace characters, stopping at the first whitespace character found…
“Any number of non-whitespace characters”?! But buffer only allocates for 300 int (300 * 4 bytes)! This adds affirmation to our above-described attack-chain that a buffer overflow may be possible.
OPTIONAL: TRY USING E.PY!
Let’s test our assumptions! Open e.py and take a minute to look it over. When you’re ready, uncomment the following line:
payload = b’A’ * 1209
…and then run it from the Ol_basic_overflowi directory with our dbg option:
python3 e.py dbg
Assuming you’re running this in the VM, you should see another terminal open running GDB with the pwndbg extension. Don’t worry too much about understanding what’s happening here for now; we have several exercises coming up in other stages that dive into all of this. In brief, you’ve launched a debugger and hooked it onto the flag process; that process has ran and is now paused at the start of the main() function. For now, enter “c” or “continue” and let the process resume running.
GDB will likely halt again, throwing a SIGSEGV segmentation fault. Examining the BACKTRACE log panel will show that our main() function successfully made the subsequent function calls necessary to read out the flag; there will also be error messaging informing you of your test’s success – though specifying you need to run your exploit outside of GDB. For us to do that, we’d want to re-run e.py without the ‘dbg’ option like so:
python3 e.py
Make sure you’ve uncommented the payload line, or it won’t work!
Again, don’t worry too much right now about understanding all of the information that GDB is showing you. We’ll go more in-depth with that in the section(s) to follow. For now, go ahead and close the GDB window (or type in “q” or “quit”).
Step A.3
Having developed our attack chain as a thought exercise and (optionally) affirmed our assumptions through GDB, we can now move on to exploiting the binary for our flag.
Using either e.py or the command line, run flag and pass at least 1209 characters to the program and receive your flag. Note if you run your exploit multiple times, you will get a different value each time. This is expected behavior and nothing to worry about.
Now enter that hash into your project_binexp.json file and submit it to Gradescope to confirm you’ve correctly walked-through the initial setup! Again, if you’re uncertain about the format for what
project_binexp.json should look like, see the Submission tab to the left.
